ハクソク

世界を動かす技術を、日本語で。

Rails、Laravel、Next.jsよりも「Elixir Phoenix」を選んだ理由

221日前原文(akarshc.com)

概要

  • コーディングの主な目的は 最適な問題解決
  • 開発速度 と アプリケーション速度 を重視した選択
  • Phoenix LiveView が一体型ソリューションとして最適
  • バックグラウンドジョブやリアルタイム通信の 容易な実装
  • 学び続ける姿勢 の重要性を強調

なぜコーディングするのか、そしてPhoenix LiveViewの選択理由

  • コーディングの本質は 最適な方法で問題を解決すること
  • 最も重視するのは アプリの速度 と 開発スピード
  • ReactやNext.js＋Laravel、Inertia.js＋Laravelの場合、 フロントエンドとバックエンドの両方を管理 する必要
  • ソロ開発者として 状態管理の二重化 に割ける時間の不足
  • 一体型で全てを処理できる堅実なモノリシック構成 を求めた経緯
  • Laravel LivewireやRails Hotwireも検討。 JavaScript依存を減らしてフロントエンド開発を簡素化 できるツール
  • Next.jsによる フルJavaScript構成 も検討したが、 バックエンドでのJS利用に抵抗感
  • Rails Hotwireは MVP開発の速さ が魅力
  • しかし バックグラウンドジョブ や リアルタイム更新、 双方向通信 の実装には追加作業が必要

ElixirとPhoenixの魅力

  • ElixirとPhoenixは Ruby on Railsの優雅さ と 圧倒的なパフォーマンス を両立
  • Obanによるバックグラウンドジョブ が標準搭載
  • 分かりやすくクリーンな構文
  • LiveView は従来のサーバーレンダリングとフロントエンド重視型フレームワークの 絶妙なバランス
  • LiveViewは WebSocket通信 でリアルタイム双方向更新を実現
  • 必要に応じて Alpine.jsなどのJavaScriptライブラリも活用可能
  • Phoenixは Obanによるジョブ管理 が容易。失敗しても 自動再起動 でアプリの安定性維持
  • Elixirは Erlangベースのコンパイル言語。WhatsAppやDiscordのような 高い同時接続性 を実現

Phoenix LiveViewを選んだ決め手

  • 高速な開発 が可能
  • 高い同時接続性 への対応力
  • ほぼ一つの言語で全て完結
  • クリーンで読みやすいコード の実現
  • コンパイラが本番前にバグを検出
  • フォールトトレラントな設計 でダウンしにくいアプリ

他フレームワークとの比較と結論

  • Phoenixが Laravel、Rails、Next.jsより優れている とは断言しない
  • いずれも 優秀なフレームワーク であり、実際にアプリ構築経験あり
  • 自分のユースケースにはPhoenixが最適解
  • プロジェクト： Hyperzoned.com

新しい選択肢を探ることの重要性

  • 既知の技術だけに頼らず、新たな選択肢を探求 する姿勢
  • より効率的な問題解決法 の発見につながる可能性
  • 学び続けることの大切さ を強調

連絡先

  • Xまたは Hyperzoned.com で連絡可能

Hackerたちの意見

でも、バックグラウンドジョブやリアルタイム更新、双方向通信が必要だったんだ。そういうのはRailsやLaravelでも可能だけど、設定にはちょっと手間がかかる。Railsでは全くそうじゃないってのは確かじゃないと思うよ。デフォルトでSolid Queue（ジョブ）とSolid Cable（リアルタイムメッセージング）が使えるからね。

└

そうだね、確かに変だよ。最近Railsに移行したばかりだけど、SolidQueueはめっちゃ簡単で、デフォルトで設定できるよ。https://github.com/akodkod/solid-queue-dashboardと組み合わせると、いい感じの概要が見れるし。

└

Railsでも全てのことが可能だよ。素晴らしいフレームワークだけど、Phoenixの方がずっと使いやすい。ぜひ試してみて！

└

両方のシステムを実際に使ってる人から言わせてもらうと、全然違うよ。ObanはSolid Queueよりもずっと使いやすいし、わかりやすい。Solid Queueは成功したジョブを再実行するのが簡単じゃないけど、Obanならちょっとテーブルのカラムを更新するだけでOK。Obanのスーパーバイザーがそれを見つけて動いてくれるから。Solid Queueはデータベースのテーブルがたくさんあるけど、Obanはoban_jobsとoban_peersだけ。Obanは同じアプリで簡単に動く。Solid Queueでもできるけど、たくさんの難解なブログを読んで設定を変えないといけない。まともなデフォルトがないしね。全体的にErlangとElixirのプリミティブのおかげで、Obanは本当にシンプルでわかりやすい方法で作られてるから、使うのが楽しい。Solid QueueはRailsから必要なものを得るために我慢してる感じ。

Elixirの力を体験したい人は、Saša JurićのElixirに関する全ての動画を観るべきだよ。

└

確か、彼は「Elixir in Action」を書いたんだよね。めっちゃ良い本だよ。

この記事は、選んだフレームワークが他のフレームワークの機能や能力を無視しているように読めるのが好きだな。RailsにはPhoenixの利点として挙げているものが全部あるし。彼は、Railsがフロントエンドと通信するのにWebSocketを使ってないかのように暗に示してるけど、それは間違いだし、最近3年間にRailsアプリを作った人には明らかに間違ってることだよ。PhoenixとLiveViewが素晴らしいツールじゃないってわけじゃないけど、Railsの世界に留まっている理由はHotwire Nativeなんだ。モバイルとウェブアプリを素早く作る一人軍のような気分だよ。

└

問題はWebSocketの実装（前回テストしたとき）はひどかったことだね。今も、非トリビアルなWebSocketを使うなら、NodeやGolangの実装を使わなきゃいけないと思う。

└

うん。Rails 7のデモでは2021年12月にWebSocketが紹介されてたよ: https://www.youtube.com/watch?v=mpWFrUwAN88&t=25m46s

└

Rubyは数回しか使ったことがないから、俺のコメントは無知かもしれない。でも、コミュニティ以外で、RubyとRoRがElixirとPhoenixよりも優れている点って何だろう？後者は、ソフトリアルタイムシステムに関しては比べ物にならないくらい進んでると思う。フォールトトレランス、NIF、アクターモデル、同時に何百万ものプロセスを安く実行できるし、簡単に理解できる並行処理、FPでコードが簡潔になると思うし、OTP、BeamのGCは世界を止めないし。要するに、PhoenixはBeamプラットフォームのおかげで優れてると思う。ただ、好きなものを使えばいいし、Hotwire Nativeは面白そうだから試してみるつもり。ブログの著者はもう少し深く掘り下げるべきだったと思う。

└

それは妥当な意見だね。Hotwireを使ったRailsは本当に強力だし、特にHotwire Nativeはね。でも、この記事はPhoenixが優れていると主張するものじゃなくて、LiveViewのモデル（サーバー駆動の状態、プロセスの分離、軽量チャネル）が特定のユースケースにどうフィットするかについてなんだ。両方のエコシステムは似たような問題を異なる方法で解決していて、Railsは慣習とプログレッシブエンハンスメントに依存している一方で、PhoenixはBeamからの並行性とフォールトトレランスに依存している。結局のところ、どちらが優れているかではなく、何を作るかによってどのワークフローが合うかが大事だと思う。

└

彼はRailsがフロントエンドと通信するのにWebソケットを使っていないとも暗に言ってるけど、それは間違いだし、ここ3年でRailsアプリを作った人には明らかに間違ってることだと思う。実際、私はRailsの開発者だけど、大量の永続的なソケットが必要なアプリならPhoenixを選ぶかな（例えば、高トラフィックのMCPサーバーとか）。これは主に、ホスティングの話がPhoenix（Gigalixir）の方がRails（Herokuやリクエストルーターの背後で動く類似サービス）よりも良いから言ってる。もちろん、自分でインフラを持ちたいならこの議論は当てはまらないけど、$100のGigalixirボックスで簡単に10万の永続接続を処理できるし、Herokuでは数千の永続接続すら難しいからね。

└

ちょっと脱線するけど、Hotwire Nativeの話を前に聞いたことがあって、その後は静かだったね。あなたがそれを使って作ってるモバイルアプリに関する体験やサポート/ドキュメント/機能について教えてもらえる？

CKEditorの統合をRails、Livewire、Phoenix、Reactに実装したんだけど、開発者体験が一番良かったのはPhoenixだったな。どのステップでも、フレームワークがどれだけ考え抜かれているか、統合がどれだけ簡単にできるかに驚かされたよ。Railsや、特にひどいNext.jsについては同じことは言えないね。興味がある人はここを見てね: https://github.com/Mati365/ckeditor5-phoenix。Livewireについては、Phoenixの簡略版って感じ。個人的には、あまり進んでないし直感的でもないと思う。例えば、Livewireのコンポーネントはスロットをサポートしてないけど、Phoenixのコンポーネントは問題なく扱える。スロットはクリーンなコンポーネント構成には重要で、ないとごちゃごちゃしたテンプレートや無駄なロジックがコンポーネント内に増えちゃう。Next.jsに関しては、ルーターの変更や疑わしい決定が日常になってる。毎週書き直されるものと統合する意味はないし、安定しているとは信頼できないよ。

└

これら両方を試してみたいな、特に君がReact+Next.jsがひどいって言うなら。TS-TSはちゃんと考えられてると思ったけど。

└

PHP（Laravel）+ jQueryは2025年でもまだ使えるけど、Livewireは絶対に使わない。Node.jsを使うと生産性が落ちるけど、必要ならもっとパワフルだよね。非同期処理やsocket.ioが必要になるかもしれないし、TypeScriptも使える。Next.jsは、すべて（良いSEO + 高度なインタラクティブ性）が必要な場合には便利だけど、正直、どれだけのウェブサイトが良いSEOとWebSocketを必要としてる？LinkedInくらいかな。

└

Railsの経験について興味があるんだけど、具体的に何が問題だったの？

└

Railsのどこが難しかったのか気になるな。

└

例えば、Livewireコンポーネントはスロットをサポートしてないと思うけど、Livewire 4ではスロットがサポートされる予定だけど…リリースまでまだ数週間かかるみたい。LW4にはパフォーマンスやQOLの改善がいくつかあるみたいだね。

└

今日、ReactとNext.jsを同じ文で言えないのが悲しい。Reactは、一般的なクライアントの観点からUIを合理的に作るリーダーだったのに。Java Swing、Android、Swift UI、カスタムゲーム開発のUIをやってきたけど、Reactは何かを掴んでた… SSRの流行が来るまではね。今や、Next.jsに隠れた状態になっちゃった。

長い間Railsをプロとして使ってきたけど、今はPhoenix/Elixirがデフォルトのスタックになってる。Railsがまだ一番得意なのは、すぐに使い捨てのCRUDアプリを生成できるところだね。そこは今でもほぼ完璧だと思う。でも、成熟して複雑さが増すと、Phoenix/Elixirの方が全体的に優れたツールだよ。

└

LLMがそのギャップをかなり埋めてくれたと思う。すぐに使い捨てのものは数分で生成できる。でも、Phoenixは気に入った場合にすべてのコントロールを取り戻してくれるんだ。

└

なんで？どっちが使いやすいと思う？

Elixirに+1。Erlangのエコシステム全体が素晴らしいし、ElixirはErlangを学ぶ時間がない開発者にも活用できる。スタートアップが最初からスケーラブルなソフトウェアを設計したいなら、最高の言語の一つだよ。

まず最初に、なんでコードを書くのか？問題を最適な方法で解決するためだよね。熱意には感心するけど、私は問題を十分に解決するためだけにコードを書く人間だから、Railsに留まるべきかなと思ってる。

└

Railsって最高だよね！

└

その文を読んで思わず笑っちゃった。マジで？俺は生活費を稼ぐためにコード書いてるし、時々は楽しみでやってるだけなんだ。「最適な方法で全てをやろうとする」なんて、実際に物事を進めるのを邪魔するだけだよ。「なんでコードを書くの？全てを早まって最適化するためさ」。

悲しいことに、うちの「企業」顧客はElixirのことを聞きたがらないんだ。彼らにとっては、JS、Python、C#、Javaしか存在しないみたい。他のスタックは「受け入れられない」「持続不可能」「すごく高い」か「管理が難しい」って感じ。7年間Elixirを使ってきたけど、企業プロジェクトには全然導入できなかった。趣味や個人、インディーのプロジェクトでしか使えなかったよ。

└

もっと上手く売り込む必要があるみたいだね ;p

└

企業の世界では、プログラマーのエコシステムと流動性が最優先なんだ。Elixirがそこで traction を得る唯一の方法は、Elixirを使っている企業が文字通りFortune 500サイズに成長して、その言語やエコシステムがその規模で viable であることを示すことだと思う。でも、それでもElixirの利点がその手の企業にとって重要になるとは思えない。規模を拡大すると、99%は人やチーム、コミュニケーションの問題だから、コードやオペレーションの優雅さや効率はあまり重要じゃなくなるんだ。

└

C#にはいつも興味があるんだけど、速いし、機能も豊富で、あまり膨れすぎてない感じがするよね。自分はElixirの開発者/ファンだけど、C#の何が悪いの？ElixirはC#と比べてどう光るのかな？

└

初めてErlangの本を買ってからほぼ20年経ったけど、ErlangやElixirを勧めるのは、自分でコーディングが好きで何か新しいことを試したいシニア開発者だけだね。このプールにはほとんど人がいない。俺は遊んでみたかったタイプだから。時間の投資に対して得られる能力が見合わないって感じたよ。ビルドシステムだけで、ほとんどの人は投げ出しちゃうだろうね。

Phoenix、特にElixirとOTPを使うのは、2010年にDotNetからRubyに移行したときと同じくらい楽しい経験だったよ。まだ少し粗いところもあるし、仕事市場はちょっと厳しいかもしれないけど、今のところElixirに関するものは質の高いフィルターを提供していると感じる。仕事の機会やチーム、一般的なプロダクト開発の経験においてもね。

└

Elixirには結構満足してるよ。文法には慣れが必要だけど、その優雅さにはいつも感心してる。Phoenixについてはちょっと複雑で、「うまくいく」部分もあるけど、意見が強いフレームワークだから、自分のやり方でやろうとするとその意見にぶつかることが多い。通常は逃げ道があるけど、ElixirとPhoenixの両方が初めてだから、うまくいかないときにどうすればいいのか分からないこともあるんだ。

著者がクレジットカードなしでトライアルを提供しなかったのは残念だね。これについては何度も議論したけど、潜在的にサブスクするかもしれない人としては、その選択に驚いてる。クレカ情報を提供する気がないなら、サブスクするつもりがないって言えるかもしれないけど、そういうわけじゃないんだ。新しいサービスにサブスクする前に、しっかり理解して感情的な関係を持ちたいんだ。「クレカを出すか、立ち去れ」って言われると、試す気もなくなっちゃう。