Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
入社3ヶ月の振り返りを兼ねた Wantedlyのバックエンド設計の紹介
Search
Tomomi Nishino
December 18, 2024
240
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
入社3ヶ月の振り返りを兼ねた Wantedlyのバックエンド設計の紹介
入社から3ヶ月のオンボーディングの振り返りを兼ねて、gRPC + Protocol BufferとGraphQLでのAPI実装について説明します。
Tomomi Nishino
December 18, 2024
More Decks by Tomomi Nishino
See All by Tomomi Nishino
分岐地獄を脱出した話: 抽象メソッド化と動的なインスタンス生成
nishinot2024
0
240
Featured
See All Featured
Context Engineering - Making Every Token Count
addyosmani
9
1.2k
Discover your Explorer Soul
emna__ayadi
2
1.3k
We Are The Robots
honzajavorek
0
380
Building a Scalable Design System with Sketch
lauravandoore
464
34k
A Modern Web Designer's Workflow
chriscoyier
699
190k
Ten Tips & Tricks for a 🌱 transition
stuffmc
1
240
AI: The stuff that nobody shows you
jnunemaker
PRO
10
1.1k
<Decoding/> the Language of Devs - We Love SEO 2024
nikkihalliwell
1
330
Marketing to machines
jonoalderson
1
5.8k
Unsuck your backbone
ammeep
672
58k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
666
130k
The SEO identity crisis: Don't let AI make you average
varn
0
560
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しか経験してこなかったバックエンドエンジニアの感想