フロントエンドとバックエンドは明確に分かれつつある

フロントエンドとバックエンドのアーキテクチャは明確に分かれつつあるし、多分この 1〜２年で完全に分かれてしまうだろう。もし分かれてなかったら技術負債と呼んでもよい状況になるだろう。

フロントエンドは React, Vue.js の登場で一変した。文法が全く変わってしまったと言っていい。状態変化に従って必要な HTML 要素を書き換える手続き的な記述ではなく、状態に応じた HTML を吐き出す・イベントで状態を変化させるといった宣言的な記述になったからだ。そして、サーバーサイドレンダリングによって新しいフロントエンドの文法で HTML が生成できるようになった。この状況でバックエンドは古い文法で HTML を吐き出す必要があるのだろうか？

過去フロントエンドは、３層レイヤー（プレゼンテーションレイヤー、ドメインレイヤー、データソースレイヤー）のひとつでしかなかった。プレゼンテーションレイヤーがそんなに複雑ではなかったし、ドメインレイヤーから渡す先がひとつしかなかったからだ。しかし現在は、モバイルアプリやウェアラブルデバイス、IoT などのドメインレイヤーへのアクセス先が複数あるのに加え、豊かな UX を提供するためにプレゼンテーション層が複雑になってしまったのだ。システム全体のアーキテクチャとしてフロントエンドとバックエンドを分けるのは自然な流れと言える。

フロントエンドを分けることによってどうなったか。バックエンドの付属品でなくなった結果、フロントエンドが自身のバックエンドを選ぶことができるようになった。BFF の先が Rails のようなフルスタックフレームワークである必要はなく、Firebase のような BaaS を選ぶこともできるし、AWS lambda のようなサーバーレスフレームワークを選ぶこともできる。選択の自由が生まれたのだ。

バックエンドも HTML を吐き出す必要性がなくなった結果、フロントエンドのバンドルやアセットの管理をする必要がなくなった。必要なのは OpenAPI や GraphQL に従って、フロントエンドとの通信を担保するだけだ。それさえ守ることで、バックエンドはドメインの堅牢性やパフォーマンスなどの本来の責務に集中できるようになったのだ。そう、もう webpacker を使うのか、素の webpack で頑張るのか考える必要はないのだ。

次の 10 年を生き残るために分割を始めよう。٩( ‘ω’ )و