ATProtocol のアプリ開発の つまづき 2024年2月21日 K-NKSM

自己紹介 K-NKSM Bluesky: @knksm5.final-techblog.com Twitter/X: @KNKSM5 ● 通信プロトコルの実装・設計をしてます ○ AWS・PythonによるIoT機器向けプロトコルの実装 ○ Webアプリのフロントエンド・バックエンド間通信の設計・実装 ● AT Protocolなどについて発信するブログを書いてます ○ AT Protocolの概要を理解したい | 最後のテックブログ

AT Protocolプロトタイプアプリ開発の経緯 ● ブログ執筆→AT Protocol概要は把握した気がする ○ 実際に手を動かし理解の解像度を上げたい ● AT Protocol上の非app.bskyサービスの話を聞かないのはなぜ？ ○ 情報不足？ ○ 破壊的変更を警戒？ ● 技術的な疑問 ○ AT Protocolが現段階でどこまで実用に耐えうるのか？ ○ 普及するうえで何が足りないのか？ ○ インフラ構成などに関する暗黙的な制約はあるか？ ● 色々試したい技術が溜まってた ○ Go ○ React AT Protocolアプリ（非app.bskyのサービス）を自作、疑問を解決

AT Protocolプロトタイプアプリ構成 ● 短文投稿サイト（アカウント、テキストのポスト、タイムライン、フォロー） ● AWS Lambda・DynamoDB・API Gatewayによるサーバーレス構成 ○ BlueskyのEC2+Express+RDS PostgreSQLと全く異なる構成を取ることで何か発見があるかも ○ 高稼働率を見込めないならコストメリット高（ c.f.ATProtocolをsmallからbigまで触ってわかったこと） ● バックエンド ○ Goを使用 ■ 勉強のため ○ PDSとAppViewが一体化してる体 ■ 現状野良LexiconをBluesky PDSが処理できない ■ Relayとの連携なし ● フロントエンド：TypeScript+React+Vite ○ 仕事で最近触っているので ● Lexicon ○ Domain authority ■ Blue（色）+Sky（自然、さわやか） →White Windとかよさそう→com.whtwnd ○ query / procedure系 com.whtwnd.feed.getAuthorFeed com.whtwnd.feed.getTimeline com.atproto.repo.createRecord（投稿、フォロー用） グレー：未完

現状 動作のようす ログインページ（ダミー） →ダミータイムライン →タイムライン更新（com.whtwnd.feed.getTimeline) →ポスト（com.atproto.feed.createRecord） →タイムライン更新 API Gateway Lambda モノレポ バックエンド フロントエンド

開発風景 1. Lexiconを手で書く 2. atprotoリポジトリのlex-cliでクライアント（TypeScript）生成 3. indigoリポジトリのlexgenでバックエンド（Go）生成 4. 生成されたrecordタイプの構造体コードにて、MarshalCBORが無いというエラーが出るので空実装 を追加 5. whyrusleeping/cbor-gen のcmd/genを使用して各構造体コードのMarshalCBOR実装本体を生成 a. 4で空実装を追加していないとエラーで動かない 6. 4の空実装を削除し、5で出てきたcbor_gen.goをソースディレクトリに配置 7. 生成されたデータ型を入出力できるLambdaの関数を追加 8. フロントエンドReactコード実装 9. 2で生成されたXRPCクライアントを使用してAPI呼び出しを実装 エラーが無くなるまで繰り返し

つまづき１：indigoや@atprotoパッケージのドキュ メントがない ● XRPCクライアントを動かすのも一苦労 ○ XRPCクライアントが何かエラーを返している →CIDがプレースホルダのままだからバリデーションで引っかかっているっぽいなー、 CIDちゃんと計算しよう →データのCBORシリアライズどうやったらいいんだ？ →indigoのソースコードを調べる →whyrusleeping/cbor-genを動かす必要に気づく →cbor_genの使い方をソースコードを読んで調べる →cbor_genでMarshalCBORを生成する →CID計算をバックエンドに実装 →フロントエンドのエラーが直る

つまづき２：Lexiconを手で書いたりコードを生成し たくない ● XRPC APIを実装している関数の型情報+αからLexiconを逆に生成できる ツールがほしい ○ Lexiconは第三者にプロトコルを公開・説明するための記述言語 ○ 特に試行錯誤が必要な開発初期はバックエンド実装→Lexicon生成→フロントエンドXRPC コード生成の順にしたい ● 可読性 ○ Swagger UI的なものがあると嬉しい？

つまづき３：単純にやることが多い ● 超ミニマルな短文投稿サイト作るのにも結構な労力がかかるんですね … ○ インフラ構成、DB、画面設計、ビルド・デプロイスクリプトの作成… ● PDSから作っている事による作業の増大 ○ CID計算、TID採番、… ○ MSTの構築・更新も実装すべきなんですが…（未実装） ○ 将来野良Lexiconを何でも受け入れるPDSが出てきてくれればAppView開発だけ に専念可能？

その他雑感・疑問 ● Lambda中心の構成で今のところ問題は起きていない ○ 今は接続の受け側オンリーのため ○ AppViewを作ってRelayをconsumeするなら常時稼働物が必要？ →インフラ面の暗黙的制約？ ● 標準的な開発手順（Getting started）の不足 ○ プロトコルの全体概要把握 →AT Protocol開発者の気持ちを推測しながら開発着手　が必要 ■ 取っ掛かりがないので、手を動かしながら学んでいくスタイルの人には辛いかも ■ Repositoryの仕組みなど、とりあえず手を動かす上では後回し可だが atprotoのページでは 強弱なく記載 ● PDS・Relay・AppView・Labeler・Feed Generator…テストどうする？ ○ テストに特化した軽量モックがほしい ■ テストコードから容易にデータを初期化可、起動停止が容易、 etc

● プロトタイプAT Protocolアプリを作成中 ○ 短文投稿サイト（ポスト、タイムライン取得、アカウント、フォロー） ○ com.whtwnd Lexiconを作成し、ドメイン取得 ○ AWS Lambda中心サーバーレス構成+Goのバックエンド+TypeScript & React ● 投稿、タイムライン取得まで作成 ● つまづき ○ indigoや@atprotoパッケージのドキュメントがない ○ Lexiconを手で書いたりコードを生成したくない ○ 単純にやることが多い ● 標準的な開発手順（Getting started）を記載した資料がない ● AT Protocolインフラの軽量モックがほしい まとめ コントリビュートチャンス！！！