Web 2.0:次世代ソフトウェアのデザインパターンとビジネスモデル(後編) - 7. リッチなユーザー経験 https://japan.cnet.com/article/20090424/5/
https://japan.cnet.com/article/20090424/5/japan.cnet.com
What Is Web 2.0 - O'Reilly Media の2005年の翻訳。GUI開発周りの時代の変化に興味があるので読んだ。
よく見たらユーザー体験ではなくユーザー経験になってて、まだUXという用語が浸透してなかった時期かもしれない。
- この頃はAjaxを使ったリッチなWeb UIが出始めていた
- デスクトップからWebアプリケーションへ活発にシフトしていった時期
- オフィススイートやクリエイター向けのソフトはWebにするのは難しいと言われていたんだけど10年で予想よりWeb化したと思う
- Flashさんも現役で、RIA売りしている時期だった。FlexはOSS化前なので普及してなかったと思う
- ブラウザはIE中心でギークがFirefoxを使っていた
- JavaScriptライブラリはAjaxユーティリティにPrototype.jsが使われていてRailsにデフォルトにしばらく入っていた
- 統合コミュニケーションクライアントについては現在ではテキストチャットとビデオ通話に落ち着いたと思う
- Skypeはあったがビデオ通話するという用途ではなかったような記憶
- まとめると世の中のアプリケーションがオンライン化してきたのでWebブラウザでそれを実装する技術も盛んになったり、オンラインになることでリッチなユーザー体験が提供できるよというのが2.0の文脈にあった
Island Architecture https://mainawycliffe.dev/blog/island-architecture/
Astro, Qwik, Markoなどのコンセプトの下地にあるIsland Architectureについて
2022
今までのアウトラインを含めた包括的な記事なのでこれを先に読んだ
2020
Island Architecture自体はPreact作者のこのブログ以降よく見るようになった
Island Architecture
- HTML/JavaScriptの配信とページのレンダリング戦略に特徴を持つ
- Islandアーキテクチャでは静的なHTMLとしてページをレンダリングして、さらに動的なコンポーネントを局所化してプログレッシブにHydrationしていくアプローチを取る
- この1つ1つのコンポーネントをIslandと呼ぶ
- 用語の元ネタはPHPアプリケーションのテンプレートをReactで書きたかったEtsyの人たち から来たとされている
- 実装にrequestIdleCallback APIを使用できる
- requestIdleCallback
- 実際に使われているかどうか知らない
- IslandはクライアントにはプレースホルダなViewとして到達する
- エントリーポイントが1つなSPAと対比してMPAと呼ばれることがある
感想
- これは一見Jamstackアーキテクチャの中のSSG+CSRの発展形に思える
- NextやGatsbyで作成した静的ページをベースに一括生成が難しい(大量にページ生成が必要になってしまう)動的部分だけCSRで分けて作るという方法があったがそれを最適化して名前を付けた感じ
- やりたいことは 新しいメルカリ Web のスタックも似ていそう
- 独立したIslandが存在するアプリケーションに向いているとされていて、それぞれのコンポーネント同士が動的に連動するとどうなるのか
- AstroにはさらにページごとのSSRがある
- https://docs.astro.build/en/guides/server-side-rendering/
- SSG+CSR+SSR
- しかしそうなるとRSCと比べてどうなんだろう
- 三文字用語が多過ぎる
- Fresh@Deno はRemix風インターフェイスとPreactによるIsland実装があっていいとこどり
- MarkoやQwikは更にチャンクやHydration戦略の実装に改善点があるらしいけど、そこまでは理解できてない
- builder.ioはQwik開発元
Remix + Deno https://github.com/remix-run/remix/tree/main/templates/deno
- Remix v1.6からDenoビルドに対応してる
- Deno Deployにもデプロイできる
- アーキテクチャはたぶん内部esbuildでDeno互換のコードにトランスパイルしてる
Ryan Dahl@JavaScript Containers がこの件についてRemixConfで触れているのかと思ったらDeno DeployとFreshの宣伝を元気にしていた。
- Denoファーストでないのでデプロイにソースコードアップロードする部分が結構時間かかるHello Worldプロジェクトで数分クラス
- この部分をRyanもポイントにしていた
- リポジトリの運用について Use npm to manage NPM dependencies for Deno projects っていうDenoプロジェクトで依存管理にnpmを使うように決めた経緯が文章化されていて、こういう仕組みがあるプロジェクトをはじめてみかけたので良いなと思った
Reactコアチームとは交わらないがユーザーサイドの独自の意見を持っているRemix作者たちの思想については、render(fm)というポッドキャストで聞いていて予備知識があった
OpenSeaの仕組みを理解しよう https://note.com/dkcrypto1/n/nd41962e151ae
OpenSeaのスマートコントラクトによるエスクロー決済の解説の記事。@niwatakoさんから教えてもらった。
著者の@dkcrypto1さんは業界内の人らしい。
分かったこと
- それぞれの売買方法でトランザクションが購入者/買い手・販売者/売り手どちら方向から行われるかで制約が違う
- OpenSeaのスマートコントラクトの実体がWyvern Exchange Contract https://etherscan.io/tokens/label/opensea
- 販売時点ではスマートコントラクトに自分のウォレットにあるNFTを移動する許可を与える。この時GAS代が発生する
- NFTの移動を行うのがOpenSeaの代理人AuthenticatedProxyで、各ウェレットごとに存在する
- OpenSeaのサーバーに署名済みのSell Orderがオフチェーンで記録される
- 購入時点では買い手がOpenSeaから取得したOrderを特定できるを付けて自分のウォレットからトランザクションを実行する
- Sell Orderを取り消すにはオンチェーン操作が必要になりGAS代
- Sell Orderの価格がここに記録されているので署名して作り直さないと価格は変えられない
- 価格を低く変更した時は購入時の量を調整すれば取引を満すことができるが増えると満たせないので価格は下げることしかできない
- 買い手のトランザクションでコントラクトによってETHを売り手のウォレットに移動する
- コントラクトによって販売者のウォレットにあるNFTを買い手のウォレットに移管する
- OpenSeaは仲介手数料を受け取る
- 買い手が価格を提示する場合は方向が逆でBuy Orderの情報をオフチェーンで記録する
- 売り手がBuy Orderを取得しトランザクションを実行してNFTの移動する
- スマートコントラクトに移動を許可する対象がトークンになるのでECR20互換のWETHにする必要がある
- 買い手から売り手へのWETHの移動はTokenTransferProxyという別のOpenSea代理人がいる
感想
- これらのスマートコントラクトと代理人を使った買い手と売り手のトランザクションを色々なパターンで組合せることでOpenSeaの各体験が成り立っている
- オフチェーンを使うことでGas代発生ポイントを減らしUXを向上できているがオンチェーンでない制約がある
他の記事
他に自分で検索して「スマートコントラクトによるエスクロー決済」も読んだ。
https://note.com/yamapyblack/n/n666d2f5870ae
著者はCryptoGames CTOの@yamapyblackさんで、たぶんこの記事を元にしたスライドが以下
分ってないこと
思考実験的に「opensea.ioへのアクセスが完全に遮断された状態でこの機能が使えるのか?=そうなのなら分散型っぽくない?」と思ったので考えてみたのだけど以下がクリアでない
Decentralized Web Node (DWN) SDK https://github.com/TBD54566975/dwn-sdk-js
DWA SDKというのがある(web3.jsみたいなもの?) で言っていたものがあったので確認した。
プロジェクトのステータス的にはSDKの仕様を決めるためにテストから書いていっているような状態。7月にv1.0にする予定らしい。
仕様というかプロトコルとかペイロードの中身の詳細とかの作業に今はいるようだ。
IPFSの人達が手動する multiformat の共通仕様にのっとったメッセージングを実現する。
ethereum smart contractでいうとABIのレイヤーを想像していて、DWNが他のNodeと交換するメッセージの中にCID形式でシリアリアズしたデータにdid:jack... みたいな識別子が入っている。
// 「aliceがプレイリストに楽曲を追加するための権限を要求」みたいなコンテキストだと思う const msg = { 'descriptor': { 'ability': { 'description' : 'some description', 'method' : 'CollectionsWrite', 'schema' : 'https://schema.org/MusicPlaylist' }, 'method' : 'PermissionsRequest' as const, 'objectId' : '03754d75-c6b9-4fdd-891f-7eb2ad4bbd21', 'requester' : 'did:jank:alice' }, 'attestation': { 'payload' : 'farts', 'protected' : 'farts', 'signature' : 'farts' } }; verifyMessageSignature(msg, resolver)
ssi-sdk というのもリンクされていたがこっちはあまり理解していない。DWN SDKがブラウザで動かすのを考えると、SSI SDKはサーバーで動かすものっぽいけど。
Web5: Decentralized Web Platform https://docs.google.com/presentation/d/1SaHGyY9TjPg4a0VNLCsfchoVG1yU3ffTDsPRcU99H1E/
何
BTCを利用したIDベースのシステム。ION Design Document が基盤にある
Web5というナンバリングはWeb3への「分散Web実現したいならシンプルに2と3にすでにあるこれだけでいいよ」という皮肉にも取れる。
Decentralized Web Nodes
Decentralized Web Nodesという用語が聞き慣れなくて気になった
Network Topology を見るとユーザーサイドにNodeがある(local DWN)
- ? alchemy や infura のようなDWNがあるのか
- 分散じゃないものとたとえとしてPWAからDWAへという比較をしている
- DWA SDKというのがある(web3.jsみたいなもの?)
tbDEX
tbDEXというのが何なのかと思ったけど固有名詞でこれがTBDってことらしい
なのでリアルワールドの実装はtbDEXでこれを実現するためのプラットフォームと考えるとわかりやすいと思った