この記事では僕の以下の疑問について書き出して、思索し、議論を喚起するものであり、何らかの答えが書かれているものではありません。
Webフロントエンドエンジニアに向けたバックエンドサーバーを構築する仕組みは様々提案されているものの、その逆であるバックエンドエンジニアに向けたフロントエンドを構築する仕組みがあまり提案されていない
この記事を書くきっかけ
以下の記事を読んで、フロントエンドの技術スタック内でサーバサイドアプリケーションの一部の責務を負うような動きがどんどん加速している現状であるが、我々バックエンドエンジニアはどういう動きをすればいいか考えている。
筆者の立場
- 自社開発のWebサービスのバックエンドアプリケーション開発を担当している
- 現代フロントエンドに関しては、社内ツール程度はNuxt.jsを用いて書いたことがある。2C向けのプロダクションコードではデバッグ目的でTypeScriptを読む程度
- 関心があるのは効率かつユーザのニーズを満たせる永続的データ構造とそれをうまく扱えるバックエンドアプリケーションの設計
なぜBackends for Frontendsと分かれているのか。
日本のほとんどのWeb開発現場においてはフロントエンドエンジニアとバックエンドエンジニアという2つの職能が並立して存在していると、僕の観測範囲では思う。しかし割り当てられたロールのラベルがそうなっているだけで、用いる技術はかぶっているケースもある。
現代の一般的なWebアプリケーションの構成は以下のようになっていると想定している。
これはかなり簡略化した形であり、例えばほとんどのサーバサイドWebアプリケーションにはログ集計解析基盤もあるし、フロントエンドスタックにSentryなどを用いたエラー監視スタックが含まれていることもあると思う。また、僕はフロントエンドエンジニアの仕事をすることはあまりないので、どうしても解像度に偏りが出てしまう。あくまでも、同僚がやっていることを外から観測するとこういう形で触っていることが分かれているようだ。さらにいうと僕が関わっているWebサービスはSPAとサーバサイドテンプレートレンダリングを併用しているものの、フロントエンドスタックでのSSRは採用していない。
そして職能ごとの責務はこのように分かれている。
ブラウザからこっちと、ブラウザがネットワークを通して向こう側に分かれている。ただし、フロントエンドスタックのビルドを通してキャッシュ制御を行っている領域もあるし、HTMLテンプレートはUIにも関わってくるため、フロントエンドエンジニアが担当している。というわけで赤字にしておいた。
つまるところ、「あなたはここまで」「わたしたちはここからここまでやる」と壁ができている。そのほうが専門性が深まり、効率が高くなるからだ。でももっと細かく分けることも出来る。実際、我々のチームは社内の他のプロジェクトではSREチームと呼ばれる部署が担当している部分もサーバサイドエンジニアが行っている。インフラ構築であったり、監視の部分だ。でもこれは切り出す事例が世の中にはたくさんある。更にいうと、データベースの管理はDBAという職能の方が専門的にやっているケースも世の中にはある。やろうと思えば無限に分割できるし、やろうと思えば全部やれる。全部やっている例が、世間ではフルスタックエンジニアと呼ばれること僕は理解している。
また、昨今ではこれらの一部をSaaSやPaaSに任せる例もある。僕のWebサービスはAWS上に構築され、メインのDBはAmazon Auroraを用いていることから、DBAおよびSREの一部の役割をAWSにやってもらっていると考えられる。アプリケーションによっては、FirebaseやVercelなどを用いると、CDNから先の向こうをほぼ全てサービス側にやってもらうことも可能である。
フロントエンド技術がバックエンドへ揺り戻しされる対する考察
じゃあなぜ全部やらないのか。それはそれぞれの技術スタックが複雑になり難易度が上がってきたからだ。僕の記憶では2010年以前のWeb開発においてはフロントエンドエンジニアと呼ばれず、マークアップと言う仕事として、現在のサーバサイドエンジニアが片手間にHTMLとCSSを書いたり、現在のデザイナーがこれらを書いていたと思う。しかし、Webが単なるページから動的なアプリケーションに進化し、HTMLがドキュメントを表現するための記法から、UIを記述するための基盤として利用されるようになった。そのため、より多くの技術の理解が求められて、マークアップ周辺の仕事はフロントエンドエンジニアという職能に切り出されてきた。同じ現象は、サーバサイドエンジニアからSREという職能が切り出されたのにも似ている。
一人で担当できないぐらい、技術が発展したから複数人で切り分けて担当するようになった。では、なぜフロントエンドエンジニアがわざわざ現状切り分けられているバックエンドの領域に足を踏み入れようとしているのか。それは2つの理由があると思っている
フロントエンドエンジニアが達成したい目的がフロントエンドのスタック内では収まりきらなくなった
Server Side Renderingという技術は、ブラウザサイドでのJavaScriptの実行では実現できなかったことをサーバサイドで実行することで解消する。アクセス一発目のレンダリングスピードを高めるためにサーバサイドリソースを使ったり、CDNキャッシュを利かして解決する。また、JavaScriptを解釈しないクローラに対しても有効に働く。しかし、本来はブラウザ向けに書かれたコードをサーバで実行するには制限が多い。フロントエンド感覚でサーバサイドで動くコードを書くのは未だに難しい。
そこで、React Server ComponentはSSRが抱えていた、SPAのアクセス一発目のみにフロントエンドのコードをサーバサイドで実行するのではなく、SPAのコンポーネントを局所的に常にサーバサイドで実行したものを透過的にクライアントが取得する点で違いがあると考えている。境界を再設定することで、よりフロントエンドが主でバックエンドが従である関係を強調し、扱いやすくしている。
フロントエンドでの実行に比べて、サーバサイドでの実行はいくつかのメリットがある。ユーザのブラウザに依存しないコントローラブルな実行環境、実行内容やコードの秘匿性などだ。このへんをどう実現するかは、様々なアイディアが出てくると思われる。しかし、どうやって運用するかどうか、うまく運用するかという点についてはもう少し事例がほしいと感じる。
この辺の議論はこちらの記事にもまとめられている。
◯◯エンジニアの〇〇には関心領域が込められている
じゃあみんなフロントエンジニアがフルスタックエンジニアになればいいじゃん、それが幸せと思うが、僕はそうはならないと現実的には思う。一人の人間が関心を寄せられる領域というのは思ったよりも狭い。UIを構築するためのマークアップは専門的な知識が必要だし、ビルドパイプラインにも、HTTP通信についてもそうだ。既にフロントエンドエンジニアが抱えている技術の領域は広く、そして深化していっている。
エンジニアというのはくっきりしているか、ぼんやりしているかの過多はあるものの、その仕事をするときのある程度の軸が存在すると僕は考えている。これを関心と呼ぶ。関心の周辺の領域というのは、効率よく学習でき、モチベーションもあるが、関心から遠いと効率が悪くなる。仕事上のWebサービスというのはユーザに見たり使ってもらったりして、その結果直接的・もしくは間接的にお金をもらうことを目的としているが、それはどのエンジニアであっても共通している目的だ。しかし、関心がそれぞれ違うし、それによって目的に対する手段が変わってくる。それがフロントエンドエンジニア・バックエンドエンジニアとラベリングされている物の本質である。一般的には責任の範囲とも言われるが、僕の仕事場ではあまりそれが当てはまらない。得意不得意はあるものすべての技術領域には物理的にはチーム内の人間は手を出せるので、責任範囲より関心の違いといったほうがしっくりくる。
どうしても、普段触ってる関心領域より遠い技術領域は学習の効率が悪くなってしまう。フロントエンドエンジニアで、普段はUI周りを触っているエンジニアほどバックエンド方向の技術領域は精度良く進めるのは難しい。これは世の中の情報についてもそうで、「フロントエンドエンジニア向け」「バックエンドエンジニア向け」とわかりやすいように情報が分かれている。BFFに必要とされる技術は、これまでのバックエンドの知見をかなり含んでいる。しかし、情報収集の際にフロントエンドエンジニア向けばかりの情報を読むと、理解が遠回りになってしまう可能性があるのではないか。
こういったラベリングは、主に求人上のマーケティングワードや、働く人のコンフォートゾーンとしても機能していたが、それが実態を表さなくなってくると思われる。実態が先か、言葉が変わったり、新しい言葉が生まれるのが先か、それちょっと予想がつかない。
バックエンド側からのアプローチがもっとあってもよいのではないか
Backends for Frontendsがフロントエンドの人が使いやすいように、バックエンドの仕組みをフロントエンドの技術スタックで構築したり、理解しやすいように抽象化するという目的もBFFにはあると思われる。では、バックエンドの技術スタックでフロントエンドを構成するアプローチは考えられるのか。
RailsのHotwireやPhenixのLiveView等が挙げられる。これらはSPAをトラディショナルなテンプレートレンダリングを行うフレームワークで作ることに対する回答だと見ている。また、vuguという、Goのフロントエンドライブラリがある。GoでVueライクなコンポーネントを書いて、wasmで実行するものである。本来、ブラウザ向けの技術スタックがNode.jsを介して動いてBFFを構成するように、バックエンド向けの技術スタックがフロントエンドで動く一例だと思う。
また、そもそもバックエンドだけ書いて、フロントエンドの記述を最小限に抑えるアプローチもあるのではないか。バックエンドアプリケーションの記述を最小限にするために、BaaSやサーバレス環境を用いる手法に対するアプローチである。これが僕が捉える、Frontends for Backendsであると感じる。実際この記事でいいたいのはここだけです。
僕は仕事では、GraphQLをしゃべるサーバを書いている。ここで思うのは、GraphQLさえ吐いて、あとは汎用的なコンポーネントを配置すればWebアプリケーションが作れたらいいのになと思う。例えば、管理画面のような独自のデザインやブランディングが必要ない場面ではbootstrapのようなコンポーネントとGraphQLのクエリを紐付けることさえすれば、そういったSPAが構成できるのではないか。React Adminがかなりこれに近いが、それにしてもReactやJavaScriptツールチェインの知識が多少必要である。
管理画面向けで言うと、Vironがある。VironはSwaggerを元にしたAPIサーバを書けばUI側を自動構成できるフレームワークである。こういったものをフロントエンドエンジニアの人はどう考えているかを知りたい。
しかし、一定の管理画面ではこれらは成立するだろうけれども、現代はSPAは、独特のコンポーネントのライフサイクルが存在する。これを、自動生成のツールだけで実現できるかは僕はわかっていない。また、多くの人が使うWebアプリケーションだと、出来合いのコンポーネントでは実現できないようなUIやインタラクションも存在すると思う。そういうのを人手を介さずに生成するには難しい。そこまで来るとノーコード, ローコードの領域に入ってくる。
というか僕がここまで言っているのは、得意なこと/力を入れたいこと以外はノーコード, ローコードで解決したいという話に近くなってくる。SaaSを活用してWebサービスを作ることもそうだし、サーバレスも、実際はサーバ運用レスであることもその証左だと思う。
僕は、バックエンドが得意だ。だからフロントエンドは楽して書きたい。そもそもフロントエンドがないとCLIのアプリケーションしか作れないからだ。
まとめ: とはいえ結局全部やることになる
もともとは一つの職能であった、Webエンジニアが技術の発展に伴って複雑化し、分業化されていったことを話した。しかし、それがBackends for Frontendsに代表されるような、それぞれ分割統治されていた技術領域だけで解決できなくなり、他方の領域の一部を担当するような現象が起こっていることを話した。
最終的には、全部やる人と、一部を深くやる人に分かれていくのではと予想している。実際にはクラウドコンピューティングという領域ではそれが起こったのだ。かつて、インフラエンジニアというデータセンターのサーバラックを管理したり、調達するような職能の人は会社内にいたり、委託されてそれをやる専門業者がいた。そういう仕事のやり方もまだ残って入るものの、AWSに代表されるクラウド事業者を用いてサービスを構成する際には、インフラエンジニアはクラウド事業者内で深く作る人と、クラウド事業者が提供するサービスを構成して組み合わせて使う人に分かれた。それでより高度に、より堅牢なサービスを作れるようになった。
フロントエンド・バックエンドにもそういう変化が起き、あるコンポーネントを深く作る人と、それを組み合わせる人に分かれていく。そうすることで、必要な知識を分担することが出来、さらに高度なWebサービスが作れるようになる。ただ、それどういう職業であると求人市場で言うか、どういった給与体系/雇用体系、サービス体系なのか。まだ僕にはわかっていない。
