Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
入社3ヶ月の振り返りを兼ねた Wantedlyのバックエンド設計の紹介
Search
Sponsored
·
Your Podcast. Everywhere. Effortlessly.
Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.
→
Tomomi Nishino
December 18, 2024
0
190
入社3ヶ月の振り返りを兼ねた Wantedlyのバックエンド設計の紹介
入社から3ヶ月のオンボーディングの振り返りを兼ねて、gRPC + Protocol BufferとGraphQLでのAPI実装について説明します。
Tomomi Nishino
December 18, 2024
Tweet
Share
More Decks by Tomomi Nishino
See All by Tomomi Nishino
分岐地獄を脱出した話: 抽象メソッド化と動的なインスタンス生成
nishinot2024
0
200
Featured
See All Featured
Jamie Indigo - Trashchat’s Guide to Black Boxes: Technical SEO Tactics for LLMs
techseoconnect
PRO
0
66
DevOps and Value Stream Thinking: Enabling flow, efficiency and business value
helenjbeal
1
110
The Cult of Friendly URLs
andyhume
79
6.8k
Avoiding the “Bad Training, Faster” Trap in the Age of AI
tmiket
0
79
Exploring the relationship between traditional SERPs and Gen AI search
raygrieselhuber
PRO
2
3.6k
Efficient Content Optimization with Google Search Console & Apps Script
katarinadahlin
PRO
1
330
The World Runs on Bad Software
bkeepers
PRO
72
12k
Taking LLMs out of the black box: A practical guide to human-in-the-loop distillation
inesmontani
PRO
3
2k
Tell your own story through comics
letsgokoyo
1
810
How STYLIGHT went responsive
nonsquared
100
6k
Into the Great Unknown - MozCon
thekraken
40
2.3k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
32
2.1k
Transcript
© 2024 Wantedly, Inc. 入社3ヶ月の振り返りを兼ねた Wantedlyのバックエンド設計の紹介 Dec. 18 2024 -
Tomomi Nishino @keppagurun Wantedly Tech Night 〜Wantedlyのバックエンド開発のリアル〜
© 2024 Wantedly, Inc. ⾃⼰紹介 西野 智美 Tomomi Nishino X:@keppagurun
Visit Client Growth所属 2024年9月にウォンテッドリー入社 オンボーディングが終了してチームの施策に 参加し始めたところ これまでのマイクロサービスの開発経験は JSON + REST APIの構成のみ
© 2024 Wantedly, Inc. Wantedlyのマイクロサービスアーキテクチャ • マイクロサービス間通信 ◦ gRPC +
Protocol Buffers • Frontend ↔ Backend間の通信 ◦ GraphQL この構成でのAPI実装を身につけるのが オンボーディングの内容
© 2024 Wantedly, Inc. 今日話すこと • gRPC + Protocol Buffers
◦ スキーマファースト開発の良さ • GraphQL ◦ gRPC(Protocol Buffers)との併用 対象者 • gRPC + Protocol Buffers + GraphQL の初学者
© 2024 Wantedly, Inc. gRPC + Protocol Buffers スキーマファースト開発の良さ
© 2024 Wantedly, Inc. gRPC + Protocol Buffers gRPCとは Google社が開発したRemote
Procedure Callのフレームワーク。 多くのプログラミング言語やプラットフォームをサポートしており、HTTP/2による効率化 された通信と、送受信メッセージにProtocol Buffersを選択することで低遅延かつ高いパ フォーマンスを出すことができる。 Protocol Buffersとは 構造化データをシリアライズするための仕組み。バイナリフォーマットのため軽量かつ高速 な処理ができる。 シリアライズ・デシリアライズするためには.protoファイルでのスキーマ定義が必要。
© 2024 Wantedly, Inc. gRPC + Protocol Buffers スキーマファーストとは データの構造や仕様を定義したスキーマを最初に作成し、そのスキーマに基づいて開発を進
める手法のこと。APIの作成においては、フロントエンドとバックエンドがスキーマを共有 すること効率的で一貫性のある開発が行えるのが特徴。 ➡ 詳しく知りたい初学者向け ウォンテッドリーAdvent Calender 2024の18日目「今さらスキーマファーストに入門する」もどうぞ
© 2024 Wantedly, Inc. gRPC + Protocol Buffers Protocol Buffersのスキーマ定義
• .protoファイル • 型とフィールド名の組み合わせ ◦ エンジニアであれば直感的にわかりやすい このことで生まれるメリットは? Protocol Buffersはスキーマ定義が必要になる
© 2024 Wantedly, Inc. gRPC + Protocol Buffers Wantedly Engineering
Handbook protobuf スキーマと gRPC 通信より https://docs.wantedly.dev/fields/the-system/apis スキーマファースト開発が強制されるのが protobuf + gRPC の強みのひとつです。スキー マファーストであることによって以下のような利点があります。 • サーバーとクライアントが実装を並行して進めることができる。 • データに関する暗黙の知識を言語化し、共有する機会になる。
© 2024 Wantedly, Inc. gRPC + Protocol Buffers 実際に経験してみて •
前提としてウォンテッドリーは職務混合型のチーム体制を取っている ◦ フロントエンドエンジニアとバックエンドエンジニアが同じチームにいる • バックエンドエンジニアが作成した.protoファイルをフロントエンドエンジニアもレ ビューする ◦ 早い段階で理想的な設計に近づけることができる ◦ 手戻りが少なくなる • .protoファイルはコードの一部だがドキュメントの代わりになる ◦ パラメータについて列挙した仕様書を作成して保守する必要がない ◦ まだ把握できてない既存機能を調べる時にかなり助けられた
© 2024 Wantedly, Inc. GraphQL gRPC(Protocol Buffers)との併用
© 2024 Wantedly, Inc. GraphQL GraphQLとは Facebook社(現Meta社)によって開発された、APIのためのクエリ言語。またはそのサー バー側ランタイムのこと。 データベースにおけるSQLのSELECT文のように、クライアント側からレスポンスに欲しい パラメータだけを指定することができるのが特徴であり、REST
APIとの大きな違いである。 マイクロサービスアーキテクチャではバックエンドのサービスが増えるにつれてWebアプリ からの接続先が増えていってしまうが、GraphQLサーバーをAPIゲートウェイとして利用す ることでWebアプリからの呼び出し先を1つに集約できるメリットもある
© 2024 Wantedly, Inc. GraphQLにAPIを作成するには GraphQL APIを作成するには、データをどのような型で受け取り、どのような型で返すのか をGraphQLのSDL(Schema Description Language)でスキーマを定義する必要がある。
次に、そのスキーマで定義されたAPIが実際にデータを操作するための処理(リゾルバ)を 実装する。 このスキーマは先ほどのProtocol Buffersのスキーマとは別のものになる。 GraphQL
© 2024 Wantedly, Inc. GraphQL GraphQLでもスキーマを定義する必要がある ため、ウォンテッドリーではProtocol Buffers との併用にあたっては.protoファイルの定義に 基づいて、GraphQLスキーマのリクエストと
レスポンスの型を定義している。 これはGraphQL Nexusなどを利用して、 GraphQL部分の実装負担が減るように整備さ れている。 このあたりは試行錯誤の歴史があり、 理解するまでにかなりの時間がかかった
© 2024 Wantedly, Inc. まとめ
© 2024 Wantedly, Inc. まとめ • gRPC + Protocol Buffers
◦ 機能的な利点もあるが、スキーマファーストの開発はフロントエンドエンジニアと バックエンドエンジニアが同チームにいる強みを活かせる ◦ スキーマを仕様書として位置付けることで、ドキュメント作成と更新の負担から解 放される • GraphQL ◦ 元々学習コストが高いとは聞いていたが、gRPCと併用している場合はさらにハー ドルが高くなると感じた ◦ REST APIのような気軽さはないがマイクロサービスを集約することができるのは実 装の面白みがある技術だと感じた JSON + REST APIしか経験してこなかったバックエンドエンジニアの感想