[補足]フロントエンド・セントリック・アーキテクチャーなど

前回書いた記事でわかりづらいと言われたところを補足します。
https://zenn.dev/teatwo/articles/efb99ea52876fb

「フロントエンド・セントリック・アーキテクチャー」について

何人かの人に言われたのが、これってフロントエンドの話じゃなくない？というツッコミでした。

SPA（シングル・ページ・アプリケーション）とCDN（コンテンツ・デリバリー・ネットワーク）を用いたフロントエンド・セントリックなアーキテクチャーをベースとしつつ、さらにホスティングの分散化を進めた構成

冒頭でこのように書いたことで前提のすり合わせを済ませたつもりだったのですが、そもそもこの「フロントエンド・セントリックなアーキテクチャー」という概念が、思っていたほど浸透していなかったことがわかりました。なので、「フロントエンド・セントリックなアーキテクチャー」について、こちらの記事でも補足します。

いわゆるAPI Economyの話になってくるのですが、それをガツっとフロントエンドに重心を寄せたものです。一昔前にネイティブアプリのバックエンド開発を省力化しクラウドサービス化したものを、mBaaS（mobile backend as a Service）とブランディングしていた時期がありました。ほぼその延長で、最近だと昨年後半にvercelが資金調達時のエッセイやnextjs confにて打ち出していたものがアップデート版だなと思っています（他にもJAMstackやshopify周辺からの発信など）。vercelは、CDNが主力事業のため、フロントエンド中心で行えるサービス構築を整備して促進しているわけですね。一方で、ノーコード/ローコードによるフロントエンド側の省力化の流れもあるわけですが、それと真っ向対決するかのようです。

資金調達時のCEOのエッセイの抜粋です。フロントエンドこそ差別化の源泉になる領域で、バックエンドはコモディティ化するとぶち上げています。

私が見ている限り、特にblog/mediaとcommerceがターゲットになっているという認識です。blog/mediaの記事やcommerceの商品詳細のようなページは、SEOやOGPらweb最適化の中心コンテンツであり、まさにNext.js & vercelのSSG&ISRたちが活きる場所です。さらに、それらを作成するための記事編集ツールや商品管理DBというところはSaaSを組み合わせます。また、認証や決済や顧客サポートは、まさにAPI Economyの領域です。よって、以下のように事業者はSPAとCDNを中心にしたサービス開発（他は他社サービスを組み合わせる）ができるようになるだろうというような話です。

こういう話をフロントエンド・セントリックなアーキテクチャーという表現で指していて、その方向でさらにホスティングを分散化させる話を前回の記事で展開しました。つまり、フロントエンドの話じゃなくない？という質問に対する答えは、「フロントエンドの話」だったら半分Yes、「フロントエンド・セントリックの話」ならNoということです。

httpとipfsのプロトコル説明の違いについて

HTTPがどこのホストのどのディレクトリのどのファイルかを指定するロケーション指向型のプロトコルに対して、どこに置いているかは問わずに（P2Pで拡散されていく） コンテンツの内容自体を直接指定するコンテンツ指向型プロトコルとされています。

この箇所についてです。知人と話していてもぼんやりした感じで終わってはいるのですが、アクセスポイントと分散構成が一つにまとまったものがipfsという説明をしました。

要は、httpそのものはホストやコンテンツが一つである必要があります。分散をするためには、ゲートウェイで受けた後でロードバランサーやディスパッチャで複数のファイルサーバやwebサーバなどに繋げていきます。そこはhttpそのものの責務ではなく、他のさまざまな技術やサービスで構築していきます。一方で、ipfsはP2Pなので基本的にアクセスポイントはどこでもいいです。あなたがノードを立てればそこがアクセスポイントになります。そして、パスの中のハッシュ文字列がコンテンツ探索のキーになり、自身がつながっているネットワークに対して「このコンテンツを持っているノードは？」という問い合わせを行い、見つかったノードに接続してダウンロードを実行します。コンテンツを持っているノードは複数ありえるわけです。

ぼんやりするところは、けっきょくサービス開発する立場に立つと、アクセスポイントまではhttpを使い、その後（ゲートウェイ）でipfsに繋げられるから両者は対照で比べるものじゃなくない？「httpそのものの責務ではなく、他のさまざまな技術やサービスで構築していきます」の一つがipfsということじゃないの？というところですが、あくまでファイル解決のプロトコルとしての特徴比較の話をするならこのような話になるのかなという理解です。

以上が、ロケーション指向型とコンテンツ指向型プロトコルの違いということかなと理解しています。技術的な確かさに目を瞑ってもっと丸めた例えで説明すると、httpがフォルダ階層型に対して、ipfsはタグ型という説明もできるかなと思います。

same originうんぬんについて

この箇所は、セキュリティ倫理ももちろんですし、実用例でピックしたものが金融分野（従来強い規制や監督下になる領域）なので、いろいろ配慮しながら記事の主題を進めるための話を捻り出して書いていたところでした。

あくまで技術的な面だけで補足しますと、実用例でピックしたものがフロントエンド・セントリックの説明でAPI Economyにあたるところだとethereumであることが大きいです。ethereumは永続層だけでなくユーザーの公開鍵認証も受け持ちます。フロントエンドとethereum間（正確にはフロント側にウォレットという3つ目の登場人物がいる）のネットワークトランザクションの正当性を証明する時にもそちらの証明書が使われます。また、ethereumは特定の事業者がいなく、フロント側のウォレットというクライアントエージェントとethereum側のスマートコントラクトで大半のことをやっているので、フロントエンドアプリはこの2つの補助をする公開汎用ツールみたいなもので誰が立てても機能するものになっています。なので、https/same originが担う責務がごそっとethereum（＆ウォレット）に移動しているという話でした。