はじめに
最近だとFirebaseでプロトタイピング等もありますが、今回それは比較には入れません。
モノリシック vs Frontend with BFF
モノリシックなアプリケーションは事業要件に合うフレームワークを正しく選択できた場合、アプリケーションの構築がもの凄く高速にできます。
プロトタイピング、仮説検証の段階だと特に力を発揮するでしょう。
基本的に管理画面も用意されてますしね。
ではなぜモノリシックなアプリケーションをBFFにリファクタリングし、FrontendをVueやReact等でモダンな構成にする必要があるのでしょうか？
実はそんな必要はない？
今回はモノリシックなアプリケーションとFrontend with BFFで比較しようと思います。
モノリシック
MVCで作られたモノリシックなアプリケーションはUIに1つ機能追加、削除する度にそのページを表示するコントローラーにコードを追加し、恐らくこのスタイルとhtmlを変更すればよいのだろうと当たりをつけて開発します。
なので、UIのメンテナンスをするだけで最小でそのページのhtml, css。
データをいじる場合はページ単位。
場合によってはアプリケーション全体に影響範囲があります。
アプリケーションの機能の種類や種類、その関連度合によってはアプリケーションのメンテナンスにかかる時間がどんどん上がっていきます。
Frontend with BFF
BFFをGraphQL等柔軟性のあるよくできたスタックで構築されているのを前提とします。
完全に切り離されたこちらの構成だと、画面に出すデータを追加・変更・削除したい場合に影響があるのはフロントエンドだけで、リリースもフロントエンドだけです。完全に切り離されてますね。
また、何かしらのデータをサーバーに保存するとか、何かを実行する必要がある機能の追加の場合だとサーバーにも新たにapiを追加する必要があります。しかし、スタイルだけ変更するとか、既に作られているapiを新たな所で叩く場合はサーバーへの影響はありません。
なので、UIのメンテナンスをするにあたって、サーバーへの影響がモノリシックなアプリケーションと比べ大分少ないです。
なので、モノリシックなアプリケーションではバックエンド全体がどうしてもUIに引きずられがちでしたが、GraphQLで構築されたBFFとFrontendに分けた場合、バックエンドは機能の追加、メンテナンスに集中でき、フロントエンドはUI/UX要件を満たし続けるのに集中でき、結果バックエンドを資産化できるのではないでしょうか。
デザイン、フロントエンドのスタックにそこまで左右されないバックエンドを持つ事は単に分業ができるだけでなく、開発を加速させ、結果事業全体を加速する事ができ、マーケットでの勝利の鍵になるのではないかと思います。