フェニックスはいつRailsを殺しましたか？

通常のプログラミング言語では問題を解決できない場合があります。 大量のトラフィックを伴うリアルタイムメッセージングを実現するタスクに直面しているとします。 最適な方法 明らかな理由から、Rubyはこれに最適なオプションではないため、代替の検索を開始する必要があります。 多くの方法がありますが、ルビーに関しては、Elixirを使用するのが最善の選択です。

Elixirは、Erlang仮想マシンで実行されるRuby構文を備えた関数型プログラミング言語です。 したがって、Rubyの世界の人にとっては、この言語に精通することは非常に簡単です。 完全に理解するためには、ドキュメントをもう一度読み直してみてください。

タイトルからの質問への回答と、すぐ下にあるエリクシールに関する多くの興味深いこと。

絶対に！ PhoenixはキラーRailsではなく、パートナーです

両方のプラットフォームのWebアプリケーションの構造は非常に似ています。 これは驚くべきことではありません。Phoenixコミュニティの最も重要なメンバーの1人は、Railsのコアチームの元メンバーであり、フレームワークの開発に携わる人々のほとんどはルビーです。 まだいくつかの違いがあります。

• アプリケーションを構築するためのla "Clean Architecture"アプローチの実装。 最も重要な変更は、Phoenix 1.3の最新バージョンで行われました。 詳細については、 この記事をご覧ください 。 Phoenixの部分をアプリケーションの部分から分離し、ビジネスロジックをコンテキストに制限し、リポジトリを使用してデータベースを操作します。これらはすべてRailsの世界では一般的ではありません。
• Umbrellaアプリケーション（ Umbrellaアプリ）-マイクロサービスの早すぎる使用を放棄し、膨大なビジネスロジックを1つの大きなアプリケーション内のパーツに分割するというアイデア。 このElixir機能の詳細については、 この記事を参照してください 。
• フェニックスの表現はテンプレートと呼ばれ、デコレーターに似ていますが、理論的にはこれは特別な困難を引き起こすことはありませんが、相互作用の概念を変え、 現在人気のある花見のようになります 。
• Phoenixのもう1つの機能-チャンネル。 チャネルに接続するたびに、新しいプロセスが作成されます。その後、エラーが発生しても、他の接続には影響しません。 さらに詳細にこのトピックを検討します。 さらに、Phoenixは、非構造化Webソケットへの接続のための優れた抽象化を備えたフロントエンドライブラリを提供します。
• エリクサー言語のすべての楽しみ。これについては後で説明します。

フロントエンドで作業するための組み込みツールから、Railsとは異なるアイデアや哲学に至るまで、さまざまな小さな違いもあります。

Erlang仮想マシンとそれが食べるもの

Rubyはオブジェクト指向プログラミング言語です。 これは、生産性とシンプルさを期待して松本幸弘が作成したインタプリタ言語です。 一方、エリクサーは、Jose Valimによって作成され、 BEAM



と呼ばれるErlang仮想マシンで実行される関数型言語です。 プログラムはBEAM



バイトコードにコンパイルされます。これはオペレーティングシステムの単一プロセスのように見えますが、実際には宇宙全体を運んでいます。

BEAM



はサーバー上で継続的に実行されます。 Ruby（およびRails）プロセスは、サーバーがリクエストの処理を開始したときにのみ開始されます。 したがって、たとえば、1時間ごとに何らかのアクションを実行する必要がある場合、Rails環境でCronJob



を使用する必要がありますが、フェニックスでは、 BEAM



内の小さなElixirプログラムがこれを処理します。

 defmodule Stack do use GenServer # Callbacks def handle_call(:pop, _from, [h | t]) do {:reply, h, t} end def handle_cast({:push, item}, state) do {:noreply, [item | state]} end end # Start the server {:ok, pid} = GenServer.start_link(Stack, [:hello]) # This is the client GenServer.call(pid, :pop) #=> :hello GenServer.cast(pid, {:push, :world}) #=> :ok GenServer.call(pid, :pop) #=> :world
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Elixirでタスクを実行するには、新しいプロセス（Erlangの魔法の世界ではスレッドのように動作しますが、実際にはどちらでもありません）を作成できます。一方、Rubyでは、バックグラウンドタスクを別のキューに配置する必要があります（たとえば、 、 Sidekiq



を介して）、Webアプリケーションとは独立してスケーリングできるようにします。

プロセスが分離され、メッセージの交換中にデータの新しいコピーが作成されるため、システムの反対側でデータの破損や変更を心配する必要がなくなります。 プロセス内の操作は同期的であるため、その実行順序は同じノードよりもはるかに適切です。 別の利点は、効率的なガベージコレクターです。 プロセスが「独自に動作」するとすぐに、OSのメモリが解放されます。

Rubyストリーム（ JRuby



、 Rubinius



）には、他のストリームからのデータとやり取りする機能があります。これは、その後デバッグするのに非常に問題があります。 このような場合、競合状態はかなり急速に進行します。

Webソケットを操作する

リアルタイムアプリケーション（チャットなど）は、データ交換チャネル（Webソケットなど）を使用します。 Phoenixでこれらを作成するのは簡単です。 Railsではこれも可能ですが、Webソケット接続を提供するActionCable



コンポーネントは、最初の1000の同時接続に対処する可能性は低いです。 フェニックスの観点から見ると、サーバーからクライアントにメッセージを送信するためのActionCable



アルゴリズムは、 ActionCable



単純で、信頼性が低く、拡張性が不十分です。 この場合、ElixirとPhoenixを使用するほうがどれだけ有利であるかを理解できます。アプリケーションは、1つのサーバーから数十万の同時接続を簡単に処理できます。

公平に言うと、実行中のアプリケーションでRailsケーブルに問題が発生した場合は、実装の1つがErlangでのみ行わ AnyCable



こと AnyCable



お勧めします。 これにより、 BEAM



on Railアプリケーションの利点が得られます。

膨大なWebアプリケーションをBEAM



実行することBEAM



特に楽しいです。複数のサーバーにまたがるスケーリングは非常に簡単です。 フェニックスでプロジェクトを作成すると、一般的にスケーリングの問題を忘れることができます。 そういえば... WhatsApp



サーバーもBEAM



実行されることを知っていますか？

~~~

多くの人が率直に言って、アプリケーションをスケーラブルにするためには、Elixirを使用する必要があると主張します。RubyとRailsはこれに対応していないからです。

これは非常に近視眼的なヒントであり、著者がスケーリングの概念に完全に精通していないことを示しています。 Rubyは最も賢いプログラミング言語ではありませんが、多くの労力をかけずに典型的なRailsアプリケーションをスケールアウトできます。 このようなアプリケーションは通常、リソースを共有しないアーキテクチャに基づいており、ほとんどの場合、サーバーを追加するだけで1秒あたりの処理済みリクエストの総数を増やすことができます。

鉄の面で最も安価なオプションではないかもしれませんが、正確にスケーラブルです！

~~~

関数型プログラミングとOOP

エリクサーはRubyに少し似ていることがあります。 rubyはオブジェクト指向プログラミングの世界に属し、Elixirは機能の原則に基づいて構築されているため、これは非常に紛らわしいです。 これらは2つの平行した宇宙です！ あなたとRubyが「あなた」に長い間切り替えた場合、Elixirを理解するにはまだ時間がかかります。

PhoenixはElixirで書かれた軽快なRailsだけではありません

次のモジュールを使用して、Elixirでメッセージを送信するプロセスを構成するものを見てみましょう。

 defmodule Example do def start_link do spawn(fn() -> loop() end) end def loop do receive do {:hello, pid} -> IO.inspect("Got hello from #{inspect pid}") end loop() end end
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

それではIEx



開いてみましょう：

 iex(1)> pid = Example.start_link() #PID<0.120.0> iex(2)> send pid, {:hello, self()} "Got hello from "#PID<0.118.0>" "#PID<0.118.0>" {:hello, #PID<0.118.0>}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

OOPのようですね。 Erlang / Elixirコミュニティは、ユーモアがあっても、これらの2つの言語は、他の一般的なプログラミング言語よりもOOPの概念と一貫性があると指摘しています。 それで、Elixirはオブジェクト指向言語ですか？ 種類はありません。 しかし、それについては後で。

メッセージングの利点は、送信者が事前にわかっており、プロセスの相互作用を制御できることです。 視覚化とデバッグのプロセスは、ロックやミューテックスなどの並列フローを制御するための従来の方法で起こることと比較して、はるかに簡単です。

オブジェクトRubyとは異なり、機能的なElixirのコードはモジュールで構成され、各モジュールには通常、特定の種類の問題を解決することを目的とした一連の関数が含まれています。 Elixirの大きな利点は、特定のアクションの結果が予測可能であることです。

各関数の引数は事前に記述されているため、開発者は、インスタンス変数などで発生するさらなる困難から解放されます。 また、システムの一部が意図していないデータと対話する場合、上記の問題を回避するのにも役立ちます。

競争力

Rubyについては、競争が不十分であると言えます。 はい、Rubyストリーミングの一部のバージョンでは競争力がサポートされていますが、 GIL



ストリームを同期する組み込みのMRI



（元のRuby、Cで記述）メソッドは、タスクの競争的な実行を防ぎます。 Rubyはまだ競争力のあるI / Oを許可していることに注意してください。

エリキシルはこのために作成されただけです。 文字通りの意味で。 その中での競争は、いわゆる「アクターのモデル」に基づいて実装されます。この用語は、この用語がリリースされる前からErlang仮想マシンによって実装されていた概念です。

アイデアは、メッセージングを通じて相互に作用し、相互の状態に影響を与えない分離プロセスを作成できるということです。 前のサブセクションでそのようなモデルの例を見てきました。

エリクサーは、Ruby自身がかつて気に入っていたのと同じように、通常、ルビストに好まれることに注意してください。 ここでの問題は、ある言語から別の言語に切り替えることです。 それぞれが独自の方法で優れており魅力的ですが、2つの言語で同時に書くことは不可能です。 あなたは選択をしなければなりません。

データベースを操作する

RubyとElixirで最も一般的なデータベースツールであるActiveRecord



とEcto



それぞれ比較しましょう。 どちらもリクエストを作成して検証を使用できますが、それでもまったく異なる方法で機能します。 ハッカーにとってActiveRecord



はシンプルで直感的に使用でき、さらにSQL



知識は必要ありません。 Ecto



のストーリーは正反対です。理解するのがより難しく、さらに基本的なSQL



知識が必要です。

 defmodule Sample.App do import Ecto.Query alias Sample.Weather alias Sample.Repo def keyword_query do query = from w in Weather, where: w.prcp > 0 or is_nil(w.prcp), select: w Repo.all(query) end def pipe_query do Weather |> where(city: "Kraków") |> order_by(:temp_lo) |> limit(10) |> Repo.all end end
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ActiveRecord



はRailsの秘密の武器であると言えます（ そこから誰もが鼻を向け始めたのです）。 Ecto



についてもEcto



ことは言えません。 Ecto



は優れていますが、Phoenixはそれがなければ素晴らしいのですが、 ActiveRecord



ないRailsはそれ自体ではありません。

宝石とパッケージ

gemは、別の開発者が作成したコードで、アプリケーションに簡単に統合できます。 本質的に普通のライブラリ。 プロジェクトのほとんどのルビストは、常に同じ宝石を使用しています。 gemを使用しないコードは、塩を使用しない食品に似ていると言えます。 gemエコシステムの全機能を評価するには、 こちらをご覧ください 。

Elixirの世界では、サードパーティの開発者が提供するこのようなソフトウェアはパッケージと呼ばれます。 パッケージのエコシステムは、まだヘムのエコシステムの規模まで成長していません（詳細はリンクを参照 ）。 PhoenixとEcto



での動作から判断すると、パッケージは将来のアップデートで問題を引き起こすことはないはずです。 しかし、確実に言うのは数年後にのみ可能です。

スピード

私たちは自信を持って言うことができます：フェニックスは高速です。 Railsよりもはるかに高速です。

ネットワークの広大さでは、さまざまなパフォーマンステストに関する多くの情報を見つけることができますが、詳細ではありません。 おもしろいですが、Elixirでテストをロードしてサーバーを「再起動」しようとすると、優れた電源インジケーターにもかかわらず、テストマシンはほとんどの場合失敗します。

また、RubyとElixir（およびRailsとPhoenix）での開発速度はほぼ同じです。 もちろん、あるフレームワークから別のフレームワークに初めて移動する場合、時間の損失は避けられないことを理解する必要があります。

ダウンタイムのない高速展開

ほとんどのWebアプリケーションでは、ソフトウェア更新中の短いダウンタイムは問題を引き起こしません。 多くの企業は、1〜2分のダウンタイムを排除しようとしていますが、お金を捨てていることに気付くことすらありません。 場合によっては、ダウンタイムなしの展開が本当に必要です。

Rubyの環境でこの問題を解決するには汗をかかなければなりません。Elixirはすぐに対処しますBEAM



特にこの機能が組み込まれています。これはホットコードの置き換えです。 多くの人にとって、それは奇跡になります。 Dockerを放棄しなければならない可能性が高いです。 要するに、いくつかのプラス。

ただし、急いで喜ばないでください。更新にデータベースの移行が含まれている場合、両方のテクノロジーのダウンタイムを達成するのはそれほど簡単ではありません。

ユキヒロvsホセ デビッドvsクリス

松本幸宏とホセ・ヴァリムは本当に重要な人物であり、それぞれが自分の言語とコミュニティ全体で多くのことをしてきました。 しかし、各言語の原動力の作成者について詳しく話しましょう。 RailsやPhoenixなどのオープンソースプロジェクトには通常、大規模な開発チームがいます。 そのようなチームでは、通常、製品クリエーターが重要な役割を果たします。 開発の方向性を決定し、公共活動を実施します。

Railsの開発者であるデビッドハインマイヤーヘンソン（ 別名 DHH）は、発案の最初の日からプレゼンテーションを行っています。 彼は素晴らしいスピーカーです。 以前、RailsConfカンファレンスでの彼のプレゼンテーションは、常に多くのことに目を向けていました。 今、彼は少し地面を失いましたが、彼の貢献はまだ巨大です。

デビッドは、乾燥した例を説明する方法を知っています。 プログラミングに加えて、彼は写真とモータースポーツに従事しています。 しかし、それでも、ソフトウェア製品または本を「復活させる」彼の能力（そう、彼は作家でもあります ）と競うことは困難です。

デビッドは慢に見えるかもしれませんが、理解できます。 RailsコミュニティはPhoenixコミュニティよりもはるかに大きく、DavidはChrisが行うように、会議で全員と物理的に通信することができませんでした。

そのお金は成功の指標ではありませんでしたが、Davidはbasecamp companyのおかげで大富豪になりました。これはRubyとRailsスタックで動作します。

フェニックスのクリエーターであるクリス・マッコードも、最初から人前で話していました。 クリスはRailsコミュニティのメンバーでしたが、いくつかの問題の解決策が見つからなかったため、エリクサーに切り替えました。 ダビデがかつてやったように、彼は自分の創造に情熱を傾けていると感じています。 会議では、クリスは新参者により忠実です。 彼のレポートは、訓練されていないリスナーにより適しています。

ChrisはDockYardで働いています。DockYardのリーダーは印象的なエリキシルのチームを集めました。 会社にはクールなブログもあり、多くの記事をサイトの翻訳に使っています 。

両方のフレームワークの主な問題

最も難しいのは、優れた開発者を見つけることです。これは、PhoenixとRailsの両方に関連しています。 フェニックスにとって、このタスクははるかに深刻です。 そして、これは大きな問題です。 誰も作業しないのに、なぜ完璧なフレームワークが必要なのでしょうか？ おそらく、Phoenixは一流のPHP開発者と友達になるべきでしょうか？

今日、誰もがどこでもエリクシールについて話している。 勉強を始めましょう-今すぐ

テクノロジーの原動力は私たちですので、エリクサーの開発にできるだけ早く参加してください！

また、どのフレームワークを選択しますか？

要約すると、Phoenixはわずかに強力なテクノロジーを提供していると言えますが、これはプロジェクトの成功を示すものではありません。 本当に重要なのは、作業するフレームワークに精通している開発者の存在です。

Railsで長い間プロジェクトを実行している場合、Phoenixに移動するときは非常に注意してください。 奇妙な庭では、草は常に緑です。 実際には、転送は成功しますが、ほとんどの場合、彼らの技術のマスターがそれらに対処しました。

何か新しいことに挑戦したい優秀なRails開発者のチームが既にある場合は、Phoenixでサイドプロジェクトを編成し、その結果を観察し、ゲームがろうそくに値するかどうかを判断する価値があります。

ElixirとPhoenixは、通常のCRUDアプリケーションを作成するためにも使用できます。何らかの理由で、機能プログラミング、1つのサーバーのみの存在、言語の新規性など、企業がこれを必要とする場合

ダウンタイムなしの速度と展開がプロジェクトに不可欠である場合、Phoenixを使用すればすぐに対応できます。

そして、あなたが選択したものは何でも、間違ったオプションがないことを知っています。

おわりに

この記事は、次の3つの資料を編集したものです。

• フェニックスは優れていますが、Railsはより人気があります / Stefan Wintermeyer
• なぜエリクサーとフェニックスなのか？ /ダイニス・ラピンズ
• Elixir / PhoenixがRuby / Railsよりも有利なユースケースは何ですか？ /ヘンドリックマン

翻訳はNadezhda / tresstenselによって行われました 。

材料の適合は、 ヤロスラフ / ヤロスラフによって行われました 。

PS興味のある人は全員、10月19日19:00 にRamblerで開催されるElixirミーティングに招待されます。 他の都市や国の居住者向けに、オンラインブロードキャストが開催されます。

PPS TelegramのElixirに関する質問への回答。