フロントエンドとバックエンドのアーキテクチャは明確に分かれつつあるし、多分この1〜２年で完全に分かれてしまうだろう。もし分かれてなかったら技術負債と呼んでもよい状況になるだろう。
フロントエンドはReact, Vue.jsの登場で一変した。文法が全く変わってしまったと言っていい。状態変化に従って必要なHTML要素を書き換える手続き的な記述ではなく、状態に応じたHTMLを吐き出す・イベントで状態を変化させるといった宣言的な記述になったからだ。そして、サーバーサイドレンダリングによって新しいフロントエンドの文法でHTMLが生成できるようになった。この状況でバックエンドは古い文法でHTMLを吐き出す必要があるのだろうか？
過去フロントエンドは、３層レイヤー（プレゼンテーションレイヤー、ドメインレイヤー、データソースレイヤー）のひとつでしかなかった。プレゼンテーションレイヤーがそんなに複雑ではなかったし、ドメインレイヤーから渡す先がひとつしかなかったからだ。しかし現在は、モバイルアプリやウェアラブルデバイス、IoTなどのドメインレイヤーへのアクセス先が複数あるのに加え、豊かなUXを提供するためにプレゼンテーション層が複雑になってしまったのだ。システム全体のアーキテクチャとしてフロントエンドとバックエンドを分けるのは自然な流れと言える。
フロントエンドを分けることによってどうなったか。バックエンドの付属品でなくなった結果、フロントエンドが自身のバックエンドを選ぶことができるようになった。BFFの先がRailsのようなフルスタックフレームワークである必要はなく、FirebaseのようなBaaSを選ぶこともできるし、AWS lambdaのようなサーバーレスフレームワークを選ぶこともできる。選択の自由が生まれたのだ。
バックエンドもHTMLを吐き出す必要性がなくなった結果、フロントエンドのバンドルやアセットの管理をする必要がなくなった。必要なのはOpenAPIやGraphQLに従って、フロントエンドとの通信を担保するだけだ。それさえ守ることで、バックエンドはドメインの堅牢性やパフォーマンスなどの本来の責務に集中できるようになったのだ。そう、もうwebpackerを使うのか、素のwebpackで頑張るのか考える必要はないのだ。
次の10年を生き残るために分割を始めよう。٩( ‘ω’ )و
