ハクソク

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

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

2025年10月16日原文(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では数千の永続接続すら難しいからね。

Hacker Newsで議論の続きを見る