約1年半前に、企業発表用の内部ツールを作成しました。 最初は、バックエンドにPhoenixを、フロントエンドにReactを使用しました。 したがって、ブラウザに更新をリアルタイムで配信する際にReduxおよびPhoenixチャンネルの利点を得ることができました。
これにより、優れたライブインターフェースを取得できましたが、開発速度が低下し、プロセスに関与する少数の開発者が発生しました。 約3か月前、Reactを破棄してサーバーレンダリングに戻ることにしました。
Reactを置き換えることにした理由
リアルタイム更新により、アプリケーションの操作に没頭することができますが、同時に追加のコストがかかります。
開発費
新しい機能を1か所に追加する代わりに、APIパーツとUIパーツの両方で対処する必要がありました。 また、プロジェクトに自分の貢献を追加したいすべての開発者は、ReactとPhoenixの両方を知っている必要があり、参加しようとすることを思いとどまらせました。
テスト中
Reactコードを使用する際のもう1つの問題はテストでした。 アプリケーションとクライアントが分離されているため、テストサーバーシミュレーションの回答が常に最新であることを確認する必要がありました。 実際には、これは深刻な問題ではありませんでしたが、ホイールにスティックを数回貼り付けたままにして、テストに対する自信を減らしました。
プロジェクトへの貢献
最後に、より多くの人々がプロジェクトに参加できるようにしたかった。 機能を2か所に実装することは、1か所で作業するよりもはるかに労働集約的であることがわかりました。 そして、バックエンド開発者とフロントエンド開発者を調整しようとするのはかなり退屈です。 このアプリケーションの作業は「開発の時間」に行われるため、これは特に重要です。
交換プロセス
既に使用可能なAPIが用意されているという事実により、Reactの既存のフロントエンドに影響を与えることなく、Phoenixでページを書き換えて本番環境にデプロイすることができました。 アプリケーションはほとんどの部分がCRUDであるため、ほとんどのページは単に1対1でコピーされ、 className
をclass
、ブロック{}
を<%= %>
置き換えるだけです。
JavaScriptが必要な場所では、「散在する」断片の打たれたトラックに行きました。 このアプローチの最良の例は、ライブのコメント更新です。 バックエンドでコメントが作成されるたびに、すべてのユーザーにそれをブロードキャストします。 JSONを送信する代わりに、 live-html
チャンネルを作成し、それを通して更新をHTMLの形式でユーザーに送信します。 以下は、アプリケーションから直接のJavaScriptコードです。
import socket from './socket' const channel = socket.channel('live-html', {}) channel.join() .receive('ok', function(resp) { console.log('Joined successfully', resp) }) .receive('error', function(resp) { console.log('Unable to join', resp) }) channel.on('new-comment', payload => { $(`[data-announcement-id='${payload.announcement_id}'] .comments-list`) .append(payload.comment_html) })
この驚くほど少量のJavaScriptコードは、アプリケーションに膨大な機能を提供します。 サーバーでHTMLを生成してクライアントにブロードキャストするこのような戦略は、同じ機能を備えた本格的なフロントエンドアプリケーションを記述するよりもはるかに簡単です。
また、ここにTurbolinksを追加しました。これにより、ページの更新が非常にスムーズになり、SPAの感覚を得ることができました。
結果
完全な移行は比較的簡単でした。 私たちは、Reactでフロントエンドを使用していた年全体よりも数か月でプロジェクトに参加した人が多いという結論に達しました。 テストの記述がはるかに簡単になり、同時に信頼性も大幅に向上しました。 結局、サーバーのテスト応答が実際の応答と異なることを恐れる必要はありません。
会社の多くの従業員が進行中の移行について知っていたという事実にもかかわらず、生産の変更が注がれたことを誰にも伝え始めませんでした。 顕著な違いについて言及した人は一人もいなかった。 また、アプリケーションがReactに基づいていないことを誰も理解していませんでした。 ページレンダリング時間が大幅に短縮されたフェニックスの速度と、Reactのフロントエンドアプリケーションから大量のデータをロードできないことのおかげです。
学んだ教訓
作業の最後に、サーバーレンダリングを使用してPhoenixでアプリケーションを作成できることを認識し、証明しました。これは、別のフレームワークのSPAアプリケーションと同様に機能します。 完成した製品が同じくらいクールであるだけでなく、新しい機能をより迅速に追加し始め、テストに自信を持ち、開発者をプロジェクトに参加させやすくしました。 一般的に、私はそれが大きな勝利だったと思います。
最近、フロントエンドフレームワークを放棄しましたか？
Wunschからの結論
友達！ 次の記事は、1週間でフェニックスに関するブログを作成することに関するものです。 本日、このフレームワークに関連する別の興味深いトピックを議論することにしました。
私たちは、あなたがHabréでElixirについてのクールな記事を公開する必要がある勝利のためのクールな賞品を使ったコンペティションを開催していることを思い出します。 また、ニュースレターを積極的に購読することをお勧めします。 週に2回、新しい記事をメールで送信しますが、この記事はまだサイトで公開されていません。 私たちと一緒にいるすべての人に感謝！