Tweet
Tweet

Slide 1

Slide 1 text

TypeScript x GraphQLで2年開発してみて 株式会社令和トラベル Backendエンジニア 木村 祐太 2024/02/20

Slide 2

Slide 2 text

き む ら　 ゆ う た 
 木村　祐太 => きむにゃん
 
 ■略歴
 2018.1 - 2022.12: リクルートでエンジニア
 2023.1 - : 令和トラベルでエンジニア <- イマココ
 
 ■やりたいこと
 人生を豊かにするプロダクトを作って生きていきたい 
 
 ■仕事内容
 開発業務（バックエンドを中心に）
 P. 2 自己紹介

Slide 3

Slide 3 text

No content

Slide 4

Slide 4 text

No content

Slide 5

Slide 5 text

No content

Slide 6

Slide 6 text

今日話すこと - Backend技術選定について - うまくいっていること・課題 - まとめ

Slide 7

Slide 7 text

- NEWT - カスタマー用アプリ - iOS (Swift) - Android (Kotlin) - Web (TypeScript) - 管理システム - ツアー造成・予約・手配管理用のシステム - Web (TypeScript) <- Backendチームで開発 前提：扱うプロダクト

Slide 8

Slide 8 text

- 開発言語: TypeScript - API Layer: GraphQL - GraphQLのAPIをCloud Run上で動作 - 実装にはApollo GraphQLを利用 - GraphQLをいわゆるAPIアグリゲーションの層として使っているわけではなく、単体で 機能するもの Backend Stack

Slide 9

Slide 9 text

なぜGraphQLか - Schema Driven!(RESTは OpenAPIの仕様と組み合わせる必 要がある) - gRPCはWebで使いづらかった(プロ キシが必要) - クライアントが必要な情報を定義で きる。 - Apollo Serverが強力

Slide 10

Slide 10 text

- フロントエンドと言語を合わせることでスイッチングコストが下がる (管理システムもBackendチーム開発) - TypeScriptとApollo Serverのエコシステムが強力 - 型は必要 なぜTypeScriptか

Slide 11

Slide 11 text

NEWT: Back-end Technology Selection Choosing the right technology stack Tech Blogの宣伝！

Slide 12

Slide 12 text

プロダクトの変遷 すごく成長しました

Slide 13

Slide 13 text

- NEWT - カスタマー用アプリ - iOS (Swift) - Android (Kotlin) - Web (TypeScript) - 管理システム - ツアー造成・予約管理システム - Web (TypeScript) Backendチーム構成 Before

Slide 14

Slide 14 text

- NEWT - カスタマー用アプリ - iOS (Swift) - Android (Kotlin) - Web (TypeScript) - 管理システム - ツアー造成・予約管理システム - Web (TypeScript) Backendチーム構成 After

Slide 15

Slide 15 text

TypeScript x GraphQLで進めてうまくいったこと - TypeScript - フロントエンドと同じ言語なのでスイッチングコストが低い - 複雑なデータモデルで構成される管理システムは Backendエンジニアが開発する方が効率的 - フロントエンドメンバーもBackend開発ができる - GraphQL - Scheme Driven開発が良き（後述） - 採用も順調！

Slide 16

Slide 16 text

1. まずSchemaを定義（App/Webチームと議論して決める） 2. Mock化 3. 機能実装 Schema Drivenな開発

Slide 17

Slide 17 text

1. まずSchemaを定義（App/Webチームと議論して決める） 2. Mock化 3. 機能実装 Schema Drivenな開発

Slide 18

Slide 18 text

1. まずSchemaを定義（App/Webチームと議論して決める） 2. Mock化 3. 機能実装 Schemaが決まるとApp/Web開発がすぐに始められる！ Schema Drivenな開発

Slide 19

Slide 19 text

- アプリケーション仕様決定後にWeb/Appエンジニアと共同でSchema設計を実施 - SchemaがAPI仕様書として機能するように書くことで、仕様書として機能するよう に自然とレビューされる 実装されたSchemaを元にクライアント側でクエリを決定できる - App / Webでエンドポイントで分けたりBFFが不要 - Over Fetchもない Demand oriented schema design

Slide 20

Slide 20 text

- アプリケーション仕様決定後にWeb/Appエンジニアと共同でSchema設計を実施 - SchemaがAPI仕様書として機能するように書くことで、仕様書として機能するよう に自然とレビューされる 実装されたSchemaを元にクライアント側でクエリを決定できる - App / Webでエンドポイントで分けたりBFFが不要 - Over Fetchもない Demand oriented schema design 来月の「NEWT Tech Talk vol.6」で この辺の話します！

Slide 21

Slide 21 text

クエリモニタリングをApllo Studioから自前のものに移行 - 前提 - GraphQLのエンドポイントは一つ - クエリはクライアントで決定 - エンドポイント単位ではなくクエリ単位でのモニタリングが必要 - Apollo Studioは強力だった - Apollo ServerにLogging Pluginを組み込むことでモニタリン グできた - 無料枠を超えてプラン変更が必要に - Enterprise - 料金が。。🥹 - Serverless - ApolloのクラウドサービスにAPI Gatewayをおくこ とに。。。 苦労したこと

Slide 22

Slide 22 text

Apollo Studioで重宝していた機能を自前で実装 - Cloud Monitoringでクエリのモニタリング - Schema変更をSlackで通知

Slide 23

Slide 23 text

- TypeScript - ライブラリの追従が大変（もうちょっと枯れて欲しい） - GraphQL - N+1問題（後述） - クエリの自由度がたかすぎる - 性能の悪いクエリの存在 - 負荷をかける攻撃的なクエリの実行 TypeScript x GraphQLでの開発における現状の課題

Slide 24

Slide 24 text

GraphQLスキーマ内の特定のフィールドの値を解決するための関数。 例えばツアーの料金を返すpriceというFieldResolverを実装します。 - ツアーの価格計算にはDBアクセスで多くのデータ取得が必要 - ツアーはtoursというリストで取得できるQueryがある - FieldResolverはオブジェクト単位で実行される N+1問題 - 前提

Slide 25

Slide 25 text

DataLoaderを使う （https://github.com/graphql/dataloader） - DBアクセスをバッチ処理することでDBアクセスを効率化できる ツアー取得の処理 Loaderの実装 N+1問題 - 対応

Slide 26

Slide 26 text

N+1問題は解決！ ただしバッチ処理のためのWait時間が発生により、 複雑な関数では逆に遅くなることも。。。 関数の最初に必要なデータを全て取得処理を書いたり、 データモデルで工夫する必要がある N+1問題 - 残った課題

Slide 27

Slide 27 text

- Pros - TypeScript - 少ない人数でWebもBackendもってなるとTypeScriptは良い選択 - GraphQL - SchemaDrivenな開発で自然とドキュメンテーションされる - 各プラットフォーム(App/Web)からBFFなしで最適なFetchができる - Cons - TypeScript - ライブラリはもうちょっと枯れてほしい - Worker Threadsが難しい(Go比較、個人的な感想です) - GraphQL - 性能の悪いクエリの解決が必要 - 攻撃的なクエリの防御が必要 まとめ1

Slide 28

Slide 28 text

プロダクトの成長に伴い課題の種類が変わってくる - 課題を発見したらすぐにBacklog化、コツコツ対応していく！ - プロダクトの成長戦略から逆算して早めに対処！ まとめ２