“Web フロントエンド”の悲しみと明るい未来という記事を読みました。
これについては全く同感です。
next.js が vercel を提供して CDNからサーバーサイドでの処理までをワンストップに提供しているとか、 firebase がクライアントサイドでの SDK と Cloud Functions をなるべく一貫した体験で提供しようとしていることとか、あるいは今話題の React Server Component とかについて、フロントエンドの最前線がいったいどのような苦しみにあるか、理解できる人は実はあまり多くないのではないか、と僕は思っている。
それは何かといえば、絶望的なまでのサーバーサイド/バックエンドへの忌避感だ。https://anond.hatelabo.jp/20210105164149
というのも、これは私達がvte.cxを提供してからずっと感じていた課題だったからです。
vte.cxを公開したときの反応は以下のようなものでした。
私が最初に提案したのは、フロントエンドエンジニアでした。
あるフロントエンドエンジニアに訊いたところ、「APIは存在することが前提だし、サーバサイドエンジニアは他にいるから」という意見が返ってきました。ほとんどの方が同じことをいいます。
このように、フロントエンドエンジニアはサーバサイドのことを避ける傾向にあります。APIから先はサーバサイドの範疇ということで自分で線を引いてタッチしようとしません。・・プラットフォームの導線を考え直す
フロントエンドエンジニアがサーバサイドを書けるようになるには覚悟が必要なようです。サーバサイドへの苦手意識や先入観を持っている方ならば特に。
next.js/vercelやReact Server Componentsの普及の鍵は、フロントエンドエンジニアのサーバサイドへの苦手意識の解消になるとは思います。しかし、そもそもReact Server Componentsなどでサーバサイドに求められているのはフロントエンドの一部であるという点は強調しておきたいと思います。以下、それについて詳しく説明します。
サーバーサイドへの先祖返りではなくBFFの進化と捉える
今のフロントエンドで起きている進化は一言でいえばサーバサイドへの回帰です。しかし、ただのサーバーサイドへの先祖返りというわけではありません。
まず、フロントエンドの境界についてよく誤解されます。例えば、
ただ、最近のFFBやSSRの流れを見てインフラを境界にするのは合ってないなと思い 「フロントエンドはプレゼンテーション、バックエンドはビジネスロジック」 と認識を改めてたところ。・・https://zenn.dev/koduki/articles/3f5215f2a79843
「インフラを境界にするのは合ってない」というのはそのとおりなのですが、「バックエンドはビジネスロジック」というのは短絡的だと思います。それは、サーバサイドに存在するビジネスロジックはBFF(Backends for Frontends)というフロントエンド機能かもしれないからです。これはバックエンドではありません。
BFFはクライアントサイドを補助する目的であるため、下図のように、サーバサイドに存在しながらもフロントエンドの範疇に入ります。
つまり、実行される場所が異なるだけで、クライアントサイドで実行される機能と同等であるというわけです。ビジネスロジックという点では、クライアントサイドとサーバサイドの両方に入りますので境界にはなりえません。
Isomorphic JavaScriptとReact Server Component
先日、React Server ComponentをSpring/JSFの再来というようなツイートを見かけましたが、残念ながらJavaがフロントエンドに付け入る隙は１mmもありません。それは、Web技術がJavaScriptで成り立っているからです。Reactが登場したときもPHPっぽいJavaScriptとかいわれましたが、その後のフロントエンドにおける地位は言わずもがなです。
逆に、Web技術においてJavaScriptを避けられない以上、JavaScriptで統一(Isomorphic JavaScript)する方が効率がいいのは当然で、BFFにおけるビジネスロジックもJavaScriptで書けるようにすべきです。（注：バックエンドもJavaScriptにすべきとは言っておりません。実はvte.cxのバックエンドはJavaです。しかし、フレームワークやDBはあるもののビジネスロジックは存在しておらず、フロントエンドの開発者がJavaを意識することはありません）
vte.cxにおけるサーバサイドJavaScriptでは、ビジネスロジックの他、VtecxAPIを使ってサーバリソースに直接アクセスしたり、PDF生成、メール送信といったバックエンド機能を利用できます。またN+1問題の回避や通信量削減のためクライアントが必要とする最低限のデータだけ返すことができます。BigQueryへの検索や集計などもBFFでやるといいでしょう。
React Server ComponentではさらにReactのコンポーネント単位でサーバサイドに置けるようにしたものですが、誤解を恐れずにいうと、React Server Componentも同様にフロントエンドの範疇で進化したBFFの一種と考えることができると思います。BFFはフロントエンドの範疇なのだから、Isomorphicで、クライアントとサーバの境界を意識しないで書けた方がいいわけです。
こうなってくると、これまで当たり前に考えていたクライアント/サーバ間のAPIの設計にも影響してきます。つまり、クライアント/サーバ間に境界を持って設計していたこと自体に意味がなくなり、GraphQLのような技術はおそらく不要になってくるでしょう。
冒頭でフロントエンドエンジニアがサーバサイドへの忌避感について触れましたが、実は社内の開発者はサーバサイドへの苦手意識もなく書けています。逆に、クライアントサイドもサーバサイドも境界なく自分ひとりで書くことで効率的な開発ができるようです。また、API設計は厳格にやるより柔軟にした方がよいということは大きな気づきでした。(APIを設計するのにswaggerはいらないを参照)
何事も実際にやってみることが大事なんですね。
ところで、こういった進化はフロントエンド、特にReact界隈を中心に進んでいます。残念なことに、Spring/JSFの再来だと真顔でいっている人は進化そのものに気づいていないようです。私がJavaやRailsなどよりJavaScript/Reactに軸足を置くべきだと主張しているのはこういった理由からです。
Isomorphic JavaScriptにおける権限の管理について
フロントエンドにおけるクライアント/サーバ間に境界がなくなる一方で、先程の図を見てもわかるように、フロントエンドとバックエンドの境界は明確です。繰り返しですが、React Server Componentはフロントエンドの範疇であり、決してバックエンドを侵食するものではありません。
こういう整理ができていないと、「Isomorphic JavaScriptではクライアントとサーバの権限が曖昧になって危険になる」といった誤解が生じてしまいます。あるいは、「クライアントから直接DBを操作するようなもの」といった危惧をもっている方もいらっしゃるようです。
権限を管理するのは、フロントエンドとバックエンドの境界においてであり、クライアントとサーバという観点ではありません。(vte.cxではBFFを実行する権限としてはリソースの参照権限を設定できますが詳細は割愛します。）
こういう自分も実はクライアント/サーバとフロントエンド/バックエンドの整理がついていなくて、７年前はこんなことをいっていました。
Isomorphicとは、サーバーとクライアントのコードを同時に記述するパラダイムのことだ。つまり、フロントエンド・バックエンドを曖昧にするようなアーキテクチャである。私は、IsomorphicはWebのアーキテクチャーに合っていないと思っていて、やはりAPIファーストで設計し、フロントエンド・バックエンドをきちんと分けるべきだと考えている。・・IsomorphicとAPIファーストについて
今読み返すと恥ずかしいですね。
それではまた。
