2023/04/25 に開催したオフライン勉強会「Encraft #2」をレポートします。
私は、このイベントに受け付け兼写真撮影のスタッフとして参加しました。
Encraft とは、"Enablement" と "Craftsmanship" をテーマにした勉強会です。「Encraft とは？」にこのイベントについての熱い想いを書いているので、ぜひご覧ください。
また、セッションの感想をハッシュタグ #encraft でつぶやいていただけると嬉しいです。
なお、この勉強会は株式会社ナレッジワークが提供します。
テーマ
前回の #1 のテーマは、「フロントエンド × 設計」でした。
今回の #2 のテーマは、「サーバーとクラインアントを結ぶ技術」です。
昨今のウェブアプリケーションは、サーバーサイドとクライアントサイドで実装を分けて開発を行うことが多くなっています。サーバーサイドとクライアントサイドがインターネットを介して通信を行うことで、2 つの実装が 1 つのアプリケーションとして動作します。
このとき通信するデータ形式が無秩序だと開発効率が悪いので、一定のルールを取り決めます。このルールのことを、スキーマやプロトコルと呼びます。
今回は、このスキーマやプロトコルを深掘りすることがテーマです。
3 名の登壇者の皆さんが実践の中で得た知見、良いところやイマイチなところなどを発表していただきました。
セッション
1. コミュニケーションを支える技術：Protobuf スキーマによる明確な API 定義
登壇者の @IT_parsely さん
- protobuf 採用の背景
- 型安全
- シンプルなスキーマ
- 自動生成の文化や周辺ツールの存在
- gPRC <-> HTTP 変換可能
- protobuf 駆動開発
- Design Doc で設計する時点で protobuf で API 定義する
- 型の強み
- フロントエンド
- ts-proto で型定義を生成する
- API クラインアントを生成する
- バックエンド
- protoc で型定義やルータからのハンドラのコードを生成する
- CI
- GitHub Actions で API 定義の変更を検知して、自動でコードを生成し PR を作る
- フロントエンド
- 権限管理の拡張
- 権限をセキュアに実装できる
- 認可の処理を自動生成することで、実装ミスを防ぐ
- protobuf の extensions で拡張している
- ユーザーがアクセスできる UI の出しわけにも利用している
- エラーハンドリング
- エラーも型安全に扱いたい
- が、gRPC では Details に Any な message を入れるしかない
- そこで、Details の中身をエラー型に変換する plugin を作った
- まだ問題があり、特定の API が返すエラー型を定義できていない
- 今後やりたいこと
- protoc-gen-validate の導入
- より安全なエラーハンドリング
- gRPC-Web の導入
2. プロトコル、インターフェースとしての GraphQL
登壇者の @sonatard さん
- Stack 社の API
- Protocol Buffers on HTTP -> GraphQL
- GraphQL とは
- Overfetch の解消
- Underfetch の解消
- スキーマ駆動開発
- スキーマ駆動開発
- Frontend / iOS /Android / Backend のコードを生成する
- GraphQL のメリット
- デザインのユースケースに引っ張られて、API を変更しなくてよい
- Query でできること
- 遅い field の優先度を下げることができる (@defer directive)
- 大きなリストをストリームで受け取ることができる (@stream directive)
- Protocol Buffers on HTTP との比較
- Pros
- スキーマの表現力
- Graph 構造
- Union, Interface を標準サポート
- resolver によりフィールド追加が容易
- スキーマ管理
- 静的解析ツールが実装しやすい
- 独自実装の追加が容易
- GraphQL の directive は Protobuf の Plugin より追加しやすい
- スキーマの表現力
- Cons
- Microservice
- GraphQL ではスキーマ設計が難しい
- プロトコルに強く依存
- クラウドサービスの対応が少ない
- ライブラリ
- iOS / Android 用のライブラリは発展途上
- ライブラリに影響が大きい
- Microservice
- GraphQL やるならベットする覚悟を持つ
- Pros
3. スキーマ設計を妥協したい - pbuf でも gql でも zod でもなく JSON Schema が選ばれました
登壇者の @sadnessOjisan さん
- 前提
- Protocol Buffer や GraphQL を導入できるのは恵まれた環境
- 10 年以上の間、継続的に開発されているアプリケーションにスキーマを導入するのは困難
- 手書きの API スキーマ定義はある
- サーバーから実際に返ってくる値がスキーマ定義と違う 🚨
- ドキュメント・バリデータ・型は同期していないとだめ
- スキーマや実装が信用できるかという問題
- コードから生成しない Spec は嘘をつける
- 型生成していてもごまかせる
- スキーマや実装が信用できるかという問題
- 実際に運用しているスキーマの利用方法
- サーバーから受け取るスキーマレスなデータを、クライアントでスキーマフルなデータにする
- 歴史のあるサービスでサーバサイドでスキーマを利用できない前提がある
- クライアントが独自にスキーマを持っている状態なのでスキーマ開発とは呼べないかも
- 長生きしてきたサービスをメンテしているので、長生きする IDL を採用したい
- 2023 年現在では、zod がベスト
- joi -> yup -> zod と流行り廃りがある
- JSON Schema を採用
- 2023 年現在では、zod がベスト
- サーバーから受け取るスキーマレスなデータを、クライアントでスキーマフルなデータにする
- スキーマの生成方法
- TypeScript の型から JSON Schema を生成している
- バリデータの生成方法
- ajv で型づけ
- バリデーションに失敗した時のハンドリング方法
- スキーマレスなデータにスキーマをつけているから、よく失敗する
- サービスを止めるような例外は起こせない
- スキーマ違反は、Sentry でログする
- 期待しないデータを集計して、API を改善するサイクルに載せる
- スキーマ違反は、Sentry でログする
- スキーマを持たせるならなるべく根に近いところからやっていくほうが効果が高い
- リプレイスするなら
- DB のスキーマから正しい型を作る
- コンパイルタイムチェッククエリ
- 型安全な言語を使う
- Rust とか
- DB のスキーマから正しい型を作る
- レガシーを未来に繋げていくのは楽しい！
運営にあたって
Triple-Win アンケート
モデレーターの @yoshiko_pg さんからの告知
今回から参加者がアンケートに答えると、ナレッジワーク社が OSS プロジェクトに寄付をする試みをはじめました。参加者の 1 回答当たり 8 ドルをナレッジワークが OSS に寄付することで、参加者と OSS プロジェクトをナレッジワーク社が繋ぐ仕組みです。
30 人の方がアンケートに答えてくださり、240 ドルを open collective 経由で Prettier に寄付いたしました。ありがとうございます！
Triple-Win アンケートからの寄付
試験的な配信
今回、試験的に YouTube で Live 配信をしました。
会場のマイクの指向性のせいか、音声が途切れたり聞こえづらくなってしまったことがありました。ご視聴いただいた皆さまには、申し訳ありませんでした。なんとか配信中に改善を試みましたが、完全に解決することはできませんでした。次回の Encraft で配信するかは未定ですが、もし配信する際は集音についてテストしようと考えています。
開催の様子
日比谷国際ビルのコンファレンススクエアで開催
モデレーターの @tenntenn さんの乾杯のご挨拶
発表中の様子
質問に答える @sonatard さん
発表の後は懇親会
懇親会での交流
今回も懇親会も盛り上がり、皆さん交流が図れたようでした。
さて、次回の Encraft も絶賛企画中です。
Connpass でグループメンバーになっていただけると、開催通知メールが送られます。開催を知りたい方は、以下のリンクよりグループメンバー登録をよろしくお願いします。
Discussion