Zenn
🌊

これからのWebアプリ開発はサーバーとフロントの間が鍵になる

2021/01/09に公開
ポエム
App Engine
CDN
#
bff
idea

ポエムです。
未来はこうなるだろうなという妄想の話です。
あと、これを書いているのはGoogleのPageSpeed Insightsが90点ないと気が済まない人です。

概要

まず、サーバーとフロントの間に色々挟むようになったよなという話をします。
そこから、今後どうなるのかについての話をします。

きっかけ

最近ZennでNext.jsの話を見ることが多いです。
僕もNext.jsを気に入ったのでよく触っています。
ところで、最近サーバーサイドとフロントエンドという分け方自体が時代にそぐわなくなってきたと感じています。
結局大事な仕事はそれを跨ったところにあるからです。
Next.jsをきっかけに僕はその『跨った仕事』についていろいろ考えるようになりました。
その結果、Webアプリ開発が大きく変わるなという結論に達しました。

インターネットとサーバーサイドアプリケーションの間に色々挟むようになった

Akamaiは昔からありました。
それに、アプリケーションサーバーの前にリバースプロキシを挟むのは一般的でした。
しかし、外部業者のサービスを今ほど当たり前に挟むようになったのは最近になってのことだと思います。

思い返せば、草分けはGAEかもしれません。
GAEは『Googleがインフラを管理するので、プログラマーはコードを書くだけでアプリケーションを公開できる』という画期的なサービスでした。
当初はインフラの管理がいらないことが素晴らしいとされていた覚えがあります。
しかし、今思えば『アプリのコードと生のインターネットの間を分離してくれる』という世界観が一番凄かったかもしれません。
分離したうえで、その間でいろいろお世話をしてくれるのです。
GAEには、この点で便利な機能がいくつもありました。
まず、JSやCSSなどの静的ファイルはGoogleのCDNから配信されました。
さらに、gzipなどもGAE任せでした。
なにより、app.yamlにlogin: trueと一行書くだけでGmailログインを導入できました。
このあたりから、サーバー側のアプリの前に外部業者のシステムを置くとすごく便利という世界が広まった気がします。

今では各社から様々な便利なサービスが提供されており、インターネットとサーバーサイドアプリケーションの間のレイヤーで便利に働いてくれています。

  • AWSなどのクラウド業者
  • FastlyやCloudflareなどのCDN業者
  • FirebaseなどのMBaaS業者

これらの業者は出自は違いますが、インターネットとサーバーサイドの間という同じレイヤーにいます（厳密にいえばCDN業者はちょっと違います）。
Backend for FrontendでありFrontend for Backendであります。
とりあえずこれを中間業者とひとくくりにします。

今後中間のレイヤーは何をするようになるか

ざっくり言ってFirebaseが目指した世界を、
フロントエンドでもサーバーサイドでもない中間業者が担うようになると考えています。

例えば、確実にログイン処理は中間業者が担うようになるでしょう。
またログイン処理ができるなら、ログインが必要なページもSSRができるようになります。
これはFirebaseではできなかったことです。
すでに存在するサービスも含めるなら、他には

  • 自動HTTPS
  • Edge Cache
  • 画像の最適化や形式変換
  • ABテスト
  • WebSocketのプロキシ
  • SSRとSSG
  • WAF
  • アナリティクス
  • 広告のSSR
  • 様々なサードパーティツールの埋め込み
    • コンシェルジュツール的なもの（ヘルプ用のチャット）
    • SNSのシェアボタン
    • アクセスカウンタ
    • ECサイト向けのカート機能
    • Googleのページ内検索みたいなやつ
    • YoutubeやSlideShareやGist

などが実現可能です。

それはどのようなDXなのか

管理画面もしくはconfigファイルです。
この先、新たなPaaS/FaaS業者が現れ、その管理画面を開いてポチポチ押していくかconfigファイルに一行書くだけでGmailログインもTwitterログインも全部用意されるのです。

フロントエンドにJSライブラリを入れるのではありません。
また、サーバーサイドにコードを書き足すようなものでもありません。

それはどのようなアーキテクチャなのか

まず、サイトオーナーはその中間業者と契約します。
中間業者はサイトオーナーにPaaS/FaaSを提供します。
サイトオーナーはアセットとサーバーサイドのコードを中間業者にアップロードします。
すると中間業者がそれをデプロイします。

サイトオーナーが中間のレイヤーに様々な機能を追加すると、
その機能がユーザーとサーバーサイドアプリのコードの間でHttpRequestかHttpResponseに介入します。
プラグイン機構になっているはずです。
ログイン機能などをスムーズに実装するために、プラグインごとにそのPaaS/FaaSからメモリ領域、ディスク領域が割り当てられているはずです。

なぜ中間のレイヤーでやるべきなのか

フロントエンドではない理由

Web Vitals対策です。
Ajaxが終わるまでコンテンツが見られなかったり、
外部リソースがDLされるたびに画面がカクカクするのを防ぐためです。
Firebase AuthenticationやFirestoreはブラウザ上で実行されるので立ち上がりが遅いという問題があります。
その点、この方式ならほとんど待ち時間が増えません。
これまでReact+Firebase Authentication+Firestoreで作ったサイトはリロードすると４～５秒待たされることがありました。
これなら完全なSSRなので200msくらいで表示できるのです！

また、この手の物をフロントエンドで実装するとITPで今後ややこしくなりそうだなと感じています。

サーバーサイドでない理由

サーバーサイドのコードで外部のサーバーにRPCするもの嫌です。

ログインの処理なんか触りたくない

サーバーサイドにログイン処理のためのコードを入れたくはありません。
そもそも面倒だし実装ミスでセキュリティホール作る可能性があります。
一瞬でもユーザーの生パスワードなんて触りたくないです。

楽

例えばECサイトを作っているとして、この二つなら後者の方が圧倒的に楽です。

  • A
    1. URLから商品IDを抽出
    2. 商品管理ステムのAPIを使って商品情報を取得
      • この時なんかよくわからんアクセスキー的な物をヘッダーに入れる
    3. HTMLを組み立てる
  • B
    1. HttpRequestのContextの中に最初から商品情報が入っている
    2. それを使ってHTMLを組み立てる
ストレージ問題

また、その機能を導入するためにDBを色々いじらないといけないのもストレスでした。
PaaSがプラグインごとに保存領域を与えておいてくれたら、大体どんな機能も簡単に導入できるようになります。
僕はWordPressのプラグインに勝手にDBを触られるのが嫌いでした。

どのようなエコシステムを生むか

僕が思い描いているWebアプリ開発の未来です。

まず、そもそもそのPaaS/FaaSを提供する中間業者が新しく出てきます。
（もしくは既存のクラウド業者かもしれません）
そして、その業者があらゆるプラグインを用意することはないでしょう。
という事は、サードパーティプラグインの仕様が公開されます。
そして、AppStoreやChromeウェブストアのようにサードパーティプラグインのマーケットが始まります。

マーケットができるという事は、課金ができるようになります。
これまで、SendgridやAlgoliaなど個別に契約していたものがPaaSの使用料と一緒に請求してくれるようになります。
これはちょっとゲームチェンジャーっぽいです。

Webアプリ開発者

この世界でWebアプリ開発者が新たなアプリを作ろうと思ったらこういう世界になるでしょう。

  1. まずそのPaaSを契約
  2. その管理画面をポチポチ押すことでほしい機能を導入
  3. それだけでは足りないところをGoやNodeで開発

全盛期のWordPressの世界観ですね。

サードパーティ

もし本当にこうなったら、AppStoreやChromeウェブストアのような新たな産業が立ち上がることになります。
このPaaS向けのプラグイン開発のノウハウが市場価値を持ち始めるたら面白いですね。
そうなったらWebアプリ開発者とサードパーティプラグイン開発者に分業されていきます。
どっちがお賃金高そうですかね。あ、あとPaaS開発者層もいますね。イーロイとモーロック。

【付録】プラグインの仕様の妄想

DOMツリー

HttpResponseに介入できるので、HTMLを変更することはできるのですが、さすがに生HTMLを改変するのは筋悪そうなので、
何かしらのDOMツリーでやり取りすることになるのではないかと思います。
僕がNext.jsの記事を見てこれを書き残そうと思ったのはそういう事です。

時間バジェット

おそらくPaaSはユーザー体験を損ねるプラグインをなるべく排除しようとするはずです。
なので、実行時間制限が課せられ、それを超えたらkillされるでしょう。
1個当たり数十ミリ秒くらいではないでしょうか。

scriptタグの扱い

HTMLをいじれるという事はscriptタグを挿入出来るという事です。
しかし、それだとお行儀の悪いscriptがたくさん入れこまれてしまいます。
なのでscriptタグは特別扱いしてWorkerDOM経由という事になるのではないでしょうか。

Cookieの扱い

各プラグインがいっぱいCookieを入れてしまうとカオスになりそうです。
せっかくディスク領域が提供されているのだから、Cookieは触れないようにして、代わりにプラグインにユーザーごとの識別子とブラウザごとの識別子が与えられるようになるのではないかと思います。

プラグインのコードはこんな感じになると思います

interface Context {
  userID: string | undefined;
  browserID: string;
  memcached: MemcachedContext;
  database: DatabaseContext;
  data: any
}

export async function OnRequest(request: HttpRequest, context: Context) {
// httpヘッダーをいじったり、後続の処理のためにdataに情報を入れたりする
}

export async function OnResponse(response: HttpResponse, context: Context) {
// responseのDOMをいじる
}

アナリティクス

アナリティクス業者にとってこの変化は大きいのではないかと思っています。
これまではアナリティクス系のツールはフロントエンドのJSで情報を収集しcross domainでそれを自社サーバーに送っていました。
しかし、ITPパンチでこの先何ができなくなるかわかりません。
そこでこの方式を使えばfirst partyとしてふるまえます。
こっちのほうが安心ではないかと思います。

ところで、自分は会社のサービスのPageSpeed Insigthsを守るお仕事をしているのですが、
アナリティクス系の業者のscriptは本当にお行儀が悪いです。
DevtoolsのNetworkタブを見ると頭抱えます。
Google Analyticsですら相当です。
なので、アナリティクス系に関してはscriptを全面禁止したいです。
PaaSの入れるscriptタグが代表してユーザーの行動(スクロールとかマウスホバーとか)を一括収集して、ある程度まとめて圧縮して適宜サーバーにあげ、そこからサードパーティに配る方式にしたいです。
個人情報の適切な扱いが必要ですが、それでNetworkタブのわんぱくな子たちがいなくなってくれるなら僕はそっちの方がいいです。

Discussion