vite_ruby全体的にはとてもよい。けどちょっと注意も必要かも。

を見かけたので Vite 1 beta の頃に独自に Helper 書いて導入したものをリプレイスして v2 にしちゃおう作戦。

Home | Vite Ruby

前提

  • Vite を独自に導入済み。Webpack → Vite の migration で感動した!みたいな話はなし
  • Vite 1 beta を vite_ruby x Vite 2 に migrate.
  • Vite 1 beta を Ruby から利用してた際は Helper を独自実装していた

導入したのは vite_ruby 1.2.11

Vite 1 beta 利用時の課題

  • Vite の dev は Ruby 側の development で使う分にはいいが Ruby 側の test で使うと初回のいろいろな解決が走って重い、build を使ったら使ったで実際に build が走ってやはり重い
  • entry point が複数になる場合に vite.config.js を複数用意する必要があり、非常にダルい、というか現実のアプリだと entry point は複数になるでしょ

導入して良い点

  • vite_ruby の導入は Vite の抱えていた entry point 周りの課題をきれいに解決してくれて助かる
    • vite.config.js からの rollup の設定へどんどん深みにハマっていく必要がない
  • autoBuild を利用すると上記の重さはかなり改善される

導入するなら考えた方が良い点

  • Webpacker 同様 Helper を通して Ruby 側で asset 周りの reverse proxy を実現しているが、このおかげでもう WEBrick での開発は現実的でなくなる
    • ES Modules は Webpack と違ってブラウザ上で直接 import が動いて HTTP connection が爆発する
  • 同じく asset へのアクセスが大量に発生するので logger に工夫が必要かも
  • Webpacker 同様 Helper に新しい名前空間を用意し、そっちの利用を強制してくるのでちゃんと従おう

特に HTTP connection が増えて WEBrick では耐えられなくなる点は大きくて、恐らく Puma を使うのが素直な解決策1だが、Rails のようにライブラリが充実している環境でない、例えば Sinatra や Hanami を利用する場合、 Puma を development 環境で使うのはちょっと扱いにくいので注意が必要。

余談:Ruby外のasset bundlerとRubyを組み合わせる方法と注意点と自分の考えていること

ここからは完全に脱線なので、一つの考え方として参考になるかも。ならないかも。

個人的には Ruby バックエンドや静的サイトジェネレータと Webpack などの asset bundler の組み合わせはそこそこ試してて、

  1. Ruby 側の Asset Helper の実装
  2. Ruby で reverse proxy の実装
  3. Node.js で reverse proxy の実装

を何通りかやっている。2

そのうえで上で書いた Vite 1 beta 利用時の独自 Helper ではあえて reverse proxy を使わない Helper を書いていた3んだけど、vite_ruby は Webpacker を模倣してしまったので Ruby 側の負荷が爆発する形になってしまっている。

Webpack は bundle 済みの asset を serve するので reverse proxy が Ruby 側にあってもよいかもしれないけど、ES Modules は bundle せずに HTTP に丸投げになるので、かなり動作が違う。ここは真似する必要なかったのではないか。

まぁ reverse proxy を Ruby 側に持たせることが一概に悪いこととは言えないんだけど、シンプルな、「Rails を使うほどではないよなぁという開発」の場合に Rails のエコシステムを前提にした「なんでも揃ってる感覚」でやるといろいろハマりが多いので、できればそれほど Ruby の得意なわけではない大量の HTTP の処理が Ruby に回ってくる設計にはしない方がいいんじゃないかと個人的には考えている。

もちろん「デキアイのツールをただ組み合わせて実現できる」ものでやる方がいろいろ端折れて早いのも事実なので、鉄板構成を見つけて鉄板構成だけで押すという姿勢も大事なんだけど、それぞれの得意なこと不得意なことは知っておくといいよ、とも思った。

  1. thread ベースとか event ベースであればなんでもよい 

  2. 結局やるのは Node.js のサーバの URI の解決と manifest.json の解決だけなので、一度やってしまえば別に難しい課題じゃない。面倒なだけ。 

  3. HTML は Ruby へ、Asset は Vite Server へそれぞれ request する形 

More

Categories

Tool 日々 Web Biz Net Apple MS ことば News Unix howto Food PHP Movie Edu Community Book Security Text TV Perl Ruby Music Pdoc 生き方 RDoc ViewCVS CVS Rsync Disk Mail FreeBSD Cygwin PDF Photo Zebedee Debian OSX Comic Cron Sysadmin Font Analog iCal Sunbird DNS Linux Wiki Emacs Thunderbird Sitecopy Terminal Drawing tDiary AppleScript Life Money Omni PukiWiki Xen XREA Zsh Screen CASL Firefox Fink zsh haXe Ecmascript PATH_INFO SQLite PEAR Lighttpd FastCGI Subversion au prototype.js jsUnit Apache Trac Template Java Rhino Mochikit Feed Bloglines CSS del.icio.us SBS qwikWeb gettext Ajax JSDoc Rails HTML CHM EPWING NDTP EB IE CLI ck ThinkPad Toy WSH RFC readline rlwrap ImageMagick epeg Frenzy sysprep Ubuntu MeCab DTP ERD DBMS eclipse Eclipse Awk RD Diigo XAMPP RubyGems PHPDoc iCab DOM YAML Camino Geekmonkey w3m Scheme Gauche Lisp JSAN Google VMware DSL SLAX Safari Markdown Textile IRC Jabber Fastladder MacPorts LLSpirit CPAN Mozilla Twitter OpenFL Rswatch ITS NTP GUI Pragger Yapra XML Mobile Git Study JSON VirtualBox Samba Pear Growl Mercurial Rack Capistrano Rake Win RSS Mechanize Sitemaps Android JavaScript Python RTM OOo iPod Yahoo Unicode Github iTunes God SBM friendfeed Friendfeed HokuUn Sinatra TDD Test Project Evernote iPad Geohash Location Map Search Simplenote Image WebKit RSpec Phone CSV WiMAX USB Chrome RubyKaigi RubyKaigi2011 Space CoffeeScript Nokogiri Hpricot Rubygems jQuery Node GTD CI UX Design VCS Kanazawa.rb Kindle Amazon Agile Vagrant Chef Windows Composer Dotenv PaaS Itamae SaaS Docker Swagger Grape WebAPI Microservices OmniAuth HTTP 分析基盤 CDN Terraform IaaS HCL Webpack Vue.js BigQuery Middleman CMS AWS PNG Laravel Selenium OAuth OpenAPI GitHub UML GCP TypeScript SQL Hanami