TypeScript x GraphQLで2年開発してみて

イベント「【タイミー/Voicy/令和トラベル】Backend LT〜技術選定における“見極める力”とは〜」での登壇資料
https://reiwatravel.connpass.com/event/306794/

Transcript

1. TypeScript x GraphQLで2年開発してみて 株式会社令和トラベル Backendエンジニア 木村 祐太 2024/02/20
2. き む ら　 ゆ う た 
 木村　祐太 => きむにゃん
 
 ▪略歴
 2018.1 - 2022.12: リクルートでエンジニア
 2023.1 - : 令和トラベルでエンジニア <- イマココ
 
 ▪やりたいこと
 人生を豊かにするプロダクトを作って生きていきたい 
 
 ▪仕事内容
 開発業務（バックエンドを中心に）
 P. 2 自己紹介
6. 今日話すこと - Backend技術選定について - うまくいっていること・課題 - まとめ
7. - NEWT - カスタマー用アプリ - iOS (Swift) - Android (Kotlin) - Web (TypeScript) - 管理システム - ツアー造成・予約・手配管理用のシステム - Web (TypeScript) <- Backendチームで開発 前提：扱うプロダクト
8. - 開発言語: TypeScript - API Layer: GraphQL - GraphQLのAPIをCloud Run上で動作 - 実装にはApollo GraphQLを利用 - GraphQLをいわゆるAPIアグリゲーションの層として使っているわけではなく、単体で 機能するもの Backend Stack
9. なぜGraphQLか - Schema Driven!(RESTは OpenAPIの仕様と組み合わせる必 要がある) - gRPCはWebで使いづらかった(プロ キシが必要) - クライアントが必要な情報を定義で きる。 - Apollo Serverが強力
10. - フロントエンドと言語を合わせることでスイッチングコストが下がる (管理システムもBackendチーム開発) - TypeScriptとApollo Serverのエコシステムが強力 - 型は必要 なぜTypeScriptか
11. NEWT: Back-end Technology Selection Choosing the right technology stack Tech Blogの宣伝！
12. プロダクトの変遷 すごく成長しました
13. - NEWT - カスタマー用アプリ - iOS (Swift) - Android (Kotlin) - Web (TypeScript) - 管理システム - ツアー造成・予約管理システム - Web (TypeScript) Backendチーム構成 Before
14. - NEWT - カスタマー用アプリ - iOS (Swift) - Android (Kotlin) - Web (TypeScript) - 管理システム - ツアー造成・予約管理システム - Web (TypeScript) Backendチーム構成 After
15. TypeScript x GraphQLで進めてうまくいったこと - TypeScript - フロントエンドと同じ言語なのでスイッチングコストが低い - 複雑なデータモデルで構成される管理システムは Backendエンジニアが開発する方が効率的 - フロントエンドメンバーもBackend開発ができる - GraphQL - Scheme Driven開発が良き（後述） - 採用も順調！
16. 1. まずSchemaを定義（App/Webチームと議論して決める） 2. Mock化 3. 機能実装 Schema Drivenな開発
17. 1. まずSchemaを定義（App/Webチームと議論して決める） 2. Mock化 3. 機能実装 Schema Drivenな開発
18. 1. まずSchemaを定義（App/Webチームと議論して決める） 2. Mock化 3. 機能実装 Schemaが決まるとApp/Web開発がすぐに始められる！ Schema Drivenな開発
19. - アプリケーション仕様決定後にWeb/Appエンジニアと共同でSchema設計を実施 - SchemaがAPI仕様書として機能するように書くことで、仕様書として機能するよう に自然とレビューされる 実装されたSchemaを元にクライアント側でクエリを決定できる - App / Webでエンドポイントで分けたりBFFが不要 - Over Fetchもない Demand oriented schema design
20. - アプリケーション仕様決定後にWeb/Appエンジニアと共同でSchema設計を実施 - SchemaがAPI仕様書として機能するように書くことで、仕様書として機能するよう に自然とレビューされる 実装されたSchemaを元にクライアント側でクエリを決定できる - App / Webでエンドポイントで分けたりBFFが不要 - Over Fetchもない Demand oriented schema design 来月の「NEWT Tech Talk vol.6」で この辺の話します！
21. クエリモニタリングをApllo Studioから自前のものに移行 - 前提 - GraphQLのエンドポイントは一つ - クエリはクライアントで決定 - エンドポイント単位ではなくクエリ単位でのモニタリングが必要 - Apollo Studioは強力だった - Apollo ServerにLogging Pluginを組み込むことでモニタリン グできた - 無料枠を超えてプラン変更が必要に - Enterprise - 料金が。。🥹 - Serverless - ApolloのクラウドサービスにAPI Gatewayをおくこ とに。。。 苦労したこと
22. Apollo Studioで重宝していた機能を自前で実装 - Cloud Monitoringでクエリのモニタリング - Schema変更をSlackで通知
23. - TypeScript - ライブラリの追従が大変（もうちょっと枯れて欲しい） - GraphQL - N+1問題（後述） - クエリの自由度がたかすぎる - 性能の悪いクエリの存在 - 負荷をかける攻撃的なクエリの実行 TypeScript x GraphQLでの開発における現状の課題
24. GraphQLスキーマ内の特定のフィールドの値を解決するための関数。 例えばツアーの料金を返すpriceというFieldResolverを実装します。 - ツアーの価格計算にはDBアクセスで多くのデータ取得が必要 - ツアーはtoursというリストで取得できるQueryがある - FieldResolverはオブジェクト単位で実行される N+1問題 - 前提
25. DataLoaderを使う （https://github.com/graphql/dataloader） - DBアクセスをバッチ処理することでDBアクセスを効率化できる ツアー取得の処理 Loaderの実装 N+1問題 - 対応
26. N+1問題は解決！ ただしバッチ処理のためのWait時間が発生により、 複雑な関数では逆に遅くなることも。。。 関数の最初に必要なデータを全て取得処理を書いたり、 データモデルで工夫する必要がある N+1問題 - 残った課題
27. - Pros - TypeScript - 少ない人数でWebもBackendもってなるとTypeScriptは良い選択 - GraphQL - SchemaDrivenな開発で自然とドキュメンテーションされる - 各プラットフォーム(App/Web)からBFFなしで最適なFetchができる - Cons - TypeScript - ライブラリはもうちょっと枯れてほしい - Worker Threadsが難しい(Go比較、個人的な感想です) - GraphQL - 性能の悪いクエリの解決が必要 - 攻撃的なクエリの防御が必要 まとめ1
28. プロダクトの成長に伴い課題の種類が変わってくる - 課題を発見したらすぐにBacklog化、コツコツ対応していく！ - プロダクトの成長戦略から逆算して早めに対処！ まとめ２