エッジはフロントエンドなのか？バックエンドなのか？について考えてみる
aiji42このスクラップは、フロントエンド北海道2024のプロポーザル「エッジはフロントエンドなのか？バックエンドなのか？について考えてみる」の資料作成用のスクラップです。
aiji42従来のエッジコンピューティング
従来は、IoTデバイスの情報をデバイスと中央の集約サーバとの間で処理することで、低遅延やネットワーク負荷の軽減を果たすことが目的。
過去を遡れば、多店舗展開やFC系の店舗での在庫売上情報を一時的に店舗・倉庫内に蓄積し、一次処理してから本部に集約することで、高速化やネットワークやシステムトラブルへの耐障害性を上げる目的があった。
aiji42昨今のWebエンジニア界隈で言われるエッジコンピューティングの文脈
世界中のデータセンターで機能する、起動が早くて、短命で、小規模なコンピューティング。
以降「エッジコンピューティング」と書くものは基本的にCloudflare Workersを指す。
aiji42エッジコンピューティングをフロントエンド寄りに考えてみる
考え方①: オリジンとクライアント(ブラウザ)との間にある Shared な Service Worker
- Cache
- Shered
- Network Intercept
- Proxy
- Rewrite Response / Redirect
考え方②: クライアントコードのためのセキュアな実行環境
- Execute 3rd Partyscript
- Zaraz
- Partytown on Edge
(Cloudflare Workersであれば)V8エンジンの上でWeb標準なAPIが動く。
ブラウザの技術と変わらないのであれば、「これはフロントエンドだ」といっても問題はなさそう。
「エッジはフロントエンドだ」論に1票 🗳️
aiji42エッジコンピューティングをバックエンド寄りに考えてみる
- TCP Direct connect
- Node.js compat
- Statefull Serverless
- as Origin (Origin less)
- API server, GraphQL server
- SSR
Node.js互換なBufferとかCryptoとかStreamsとかが動く。
TCPの接続ができるのでデータベースとのコネクションも直接張ることができる。
となってくると、「オリジンサーバーをエッジで動かしてしまおう」「物理的にクライアントに近くて起動が早ければ、高速にレスポンスできるね」というムーブメントが活発になりつつある。
数年前までエッジで動かなかったライブラリもエッジランタイムのサポートをし始めたり、エッジから利用することを前提としたSaaSなども多く生まれている。
バンドルサイズの制限の問題などハードルはあれど、オリジン(Webサーバー)の役割を果たすなら、それはもはやバックエンドなのでは？
「エッジはバックエンドだ」論に1票 🗳️
が、ここで定義の問題が出てくる。origin = backend なのか？
- Next.js の getServerSideProps や Server Actions はバックエンドなのか？
- Remixの loader と action はバックエンドなのか？
- BFFを構築するのはバックエンドエンジニアの役割か？
- Java・PHP・Ruby・Go・Node.jsなどで書かれていたらバックエンドとよべるか？
aiji42フロントエンドとバックエンドの境界って...？
「フロントエンド寄り」「バックエンド側寄り」はあるが、「ここからがフロントエンド」「ここからがバックエンド」という明確な境界線はない。
そもそも、バックエンド・フロントエンドで領域を区切り始めたのは2000年代以降の話。
実際の業務の場で交わされるようになったのは2010年代入ってからであるように記憶している。
- Ajaxなどの技術の登場によるクライアントの表現力の向上
- HTTP/1.1の普及
- MVCなWebフレームワークの発達
- アプリ対応・モバイル対応の必要性
- アーキテクチャと組織の関係論・開発組織運営のプラクティスの成熟
これらがあいまって、分業や領域分けが進んでいった。
しかし、昨今の環境を見ると、フロントエンドエンジニアに対して「バックエンド寄り」な技術・知識が求められるようになってきている。
- SSR (w/ data loader)
- キャッシュコントロール
- パフォーマンス(N+1問題とか)
フロントエンドフレームワークはフルスタックになり、より境界の曖昧さが際立ってきている。
これは俗に言う技術の「より戻し」ではない。「歩み寄り」なのである。
aiji42我々Webエンジニアは境界をどう捉えて、乗りこなすべきか
重要なのはクロスオーバーとリスペクト。
「フロントエンドエンジニア」と「バックエンドエンジニア」はそれぞれ、「XXXエンド側が得意なエンジニア」「XXXエンド側に重心をおいているエンジニア」であって不可侵ではない。リスペクトをもって積極的な領域越境をすべき。
「フロントエンド」「バックエンド」の領域分割がない頃から(あるいはそういう環境で)エンジニアをしている人からすれば、至極当然のように思えるだろう。しかし、現在はキャリアのスタート時点で「フロントエンド」「バックエンド」のどちらかを選択してキャリアを始めている人も多くなってきている。
どの開発現場・組織にいっても、いろいろな意味でバランス感覚が良い人は重宝される。
ところでエッジに話しを戻すと...
Web標準なAPIが動く仮想的なブラウザと呼べるランタイムと、Node.jsのAPIが動いてTCPコネクションまでできてしまう、オリジンサーバ用のランタイムとなる可能性の両面性を持っている。
「フロントエンド」「バックエンド」を分かつものではなく、その架け橋になるものである。
「バックエンドに苦手意識がある」とか「クライアントコードしか普段書かない」という人は、ぜひエッジコンピューティングに触れてみほしい。きっと、「領域の歩み寄り」を感じ取れるだろう。
エッジコンピューティングは限りなくクライアントに近いオリジンであり、ユーザにとってのもう一つのクライアントでもある
フロントエンドの技術を使ったバックエンドである
aiji42「エッジはフロントエンドなのか？バックエンドなのか？について考えてみる」
もとい
「エッジはフロントエンドなのか？バックエンドなのか？について考えはじめたら、Webエンジニアの立ち振舞について考えることになった話」