강의

멘토링

로드맵

カカオの面接官が教える、ドキュメントベースのフレームワーク通信パターンのためのGraphQL

Swaggerドキュメントを修正し、APIスペックを合わせ、フロントエンドと繰り返しコミュニケーションを取っていると、「なぜ同じ作業を二度も繰り返しているのだろう?」という悩みに直面します。私自身も実務で同じようなもどかしさを何度も感じ、その過程でGraphQLを深く使い込みながら、データ中心の設計手法に関心を持つようになりました。この講義では、単なるGraphQLの文法ではなく、実際のサービスでどのような問題を解決するために登場したのか、そしてResolverの構造、N+1問題、Federationといった実務的な悩みについて共に掘り下げていきます。開発者間のコミュニケーションコストを削減し、より柔軟なAPI構造を設計する流れを自然に習得できるよう構成しました。

33名 が受講中です。

難易度 入門

受講期間 無制限

TypeScript
TypeScript
JavaScript
JavaScript
GraphQL
GraphQL
MSA
MSA
Government-Funded Bootcamp
Government-Funded Bootcamp
TypeScript
TypeScript
JavaScript
JavaScript
GraphQL
GraphQL
MSA
MSA
Government-Funded Bootcamp
Government-Funded Bootcamp

受講後に得られること

  • 単にQueryを作成するレベルにとどまらず、実際のサービスでGraphQLスキーマをどのように設計すべきかという感覚を掴むことができます。「なぜこのような構造に分けるのか?」を理解できるようになります。

  • REST APIで繰り返されていたOver Fetching / Under Fetchingの問題を直接解決しながら、フロントエンドとバックエンドがデータを中心にいかに柔軟に協業できるかを経験することになります。

  • Resolverの構造化、DataLoader、N+1問題の解決戦略まで、実務で必ず直面するパフォーマンス問題を直接扱うことで、「動くGraphQL」ではなく「運用可能なGraphQL」を作れるようになります。

  • Swaggerドキュメントを別途管理することで発生していたスペックの不一致問題の代わりに、Introspectionベースの自己ドキュメント化構造を理解し、APIドキュメント化の方式そのものを新たに見つめ直すことになります。

  • 単なるCRUDレベルを超えて、Federation、Subscription、認証処理といった高度なパターンまで学習し、実際の本格的なサービス環境でもGraphQLをどのように拡張するのか、その流れを理解できるようになります。

ドキュメントベースの通信??Swagger??これって一体何なの??

  • 以下の内容は実際の会話内容です。

😄 Hong : 会社で本当にただAPIを一つ開発する時も、すごく面倒なのがSwaggerをすごく要求されることなんだ…。あのフォーマットに合わせて、スペックが変わるたびに一緒に修正しなきゃいけないから、本当に面倒だよ

😄 Hong : 毎回感じることなんだけど… Swaggerもやらなきゃいけないし、ドキュメント作成もしなきゃいけないし、なぜ重複した作業を二度もするんだろう 単純に開発者同士のコミュニケーションに限定するなら、個人的にはドキュメントというものがそれほど重要なのか分からないんだけど

😄 Hong : いっそgRPCみたいに.protoファイルを見てDDDっぽく開発すればいいんじゃないかと、もどかしく感じます

😁Kakao 面接官(開発者) : 成長したな、凡夫よ…(笑)冗談はさておき、実際それほど間違ったことを言っているわけでもないと思うよ

😁Kakao 面接官(開発者) : 僕も以前はみんながやっているから、だからただ同じようにやっていたんだけど、やりながらも"これを何でこうやってるんだろう??"という疑問はあったよ。そうやって他のことを追求していくうちに成長できた気がするけど?

😁 Toss 開発者 : ㅋㅋㅋㅋ Hong、凡夫よ… ㅋㅋㅋㅋㅋ そのために GraphQL があるじゃん。Facebookで作ったんだっけ?

😁Kakao面接官(開発者) : うん、だから私も勉強しながらそれ関連で結構使ってみたんだけど、Hongが言った通りgRPCと同じだよ。事実上、HTTP通信を規格化して進めるっていう感じだね

😁Kakao 面接官(開発者) : これは僕が教えてあげるよ(笑)話に出たついでに、久しぶりにGraphQLの古参としてちょっと扱ってみたくなったな

開発者が敬遠しがちなスペックのドキュメント化。どうすれば開発者同士のコミュニケーションコストを減らすことができるでしょうか? ⚡

数多くのサービスがデータを中心に繋がる環境において、私たちは単なるREST APIの設計を超えて、「データをどのように伝達し、消費するのか」そのものについて悩むことになります。

バックエンドではすでに準備されたデータを返しているのに、フロントエンドでは不要なフィールドまで受け取ってしまったり、逆に一つの画面を構成するために複数のAPIを再度呼び出さなければならない状況が繰り返されたりします。

そうしているうちに、自然とこのような悩みが生まれるようになります。

  1. なぜ必要なデータだけをリクエストすることはできないのだろうか??

  2. APIのバージョンが増え続ける構造は、本当に正しいのだろうか??

  3. Swaggerのスペック文書と実際のレスポンス構造が食い違う問題は、なぜ繰り返されるのだろうか??

  4. フロントエンドとバックエンドが、データをもっと柔軟にやり取りしながら協力することはできないだろうか??

GraphQLは、まさにこのような問題意識から出発しています。

単にRESTを代替する技術ではなく、クライアントが必要なデータを直接定義して取得する方式で、APIの役割そのものを再設計したアプローチです。実際の現場でなぜGraphQLが登場することになったのか、
どのような状況でRESTよりも強力なのかをお伝えし、単純なCRUDレベルを超えて、Schema設計、Resolverの構造化、N+1問題の解決、DataLoaderの活用、Federation、Subscription、認証処理など、実務で必ず直面する構造的な問題についても共に見ていきます。

「GraphQLの文法を知っている開発者」ではなく、"データ中心のAPI構造を設計できる開発者"へと成長する過程となるよう、この講義を通じてお手伝いいたします。🚀

TypeScript, JavaScript, GraphQL, MSA, 国費支援ブートキャンプ

GraphQLは単なるAPI技術ではありません。 ⚡

従来のRESTベースの構造では、画面ごとに必要なデータが異なるにつれて、APIの数も増えていくことになります。
Web、Mobile、Adminページがそれぞれ異なるデータを要求し始めると、結局バックエンドは似たようなAPIを追加し続けることになり、構造はますます複雑になります。


しかし、GraphQLは少し異なる方法でアプローチします。

クライアントが「どのデータが必要か」を直接定義し、サーバーはそのリクエストに合わせて必要なデータだけを組み合わせて返します。つまり、サーバーが画面を基準にAPIを設計するのではなく、データ構造そのものを中心に動作するようになるのです。


また、GraphQLは単に一つのデータベースだけを見ているわけではありません。

User Database、Post Database、外部API、Commentシステムなど、異なるデータソースを一つのSchemaの下で有機的に繋げることができます。そのおかげで、フロントエンドは内部構造を知らなくても、単一のEndpointだけで必要なデータを取得できるようになります。


申し上げましたが、この講義では単にQueryの文法だけを説明するのではありません。

実際のリゾルバーがどのような役割を果たすのか、
なぜDataLoaderが必要なのか、
N+1問題がなぜ発生するのか、
サービスの規模が大きくなるにつれてスキーマをどのように進化させるべきかまで、併せて扱います。


単に「GraphQLの使い方」を学ぶのではなく、複雑なサービス環境でデータをどのように設計し、繋げるべきかという思考法を共に身につけることになります。🚀

しかし、GraphQLも万能ではありません。 ⚡

多くの開発者が、最初はGraphQLを単に「RESTより便利なAPI技術」程度のアプローチで使い始めます。

しかし、実際のサービス環境では、思った以上に多様な問題に直面することになります。

  1. Resolverが増えるほど複雑になる呼び出し構造、

  2. うっかり作成したクエリ一つによって発生するN+1問題

  3. 肥大化しすぎるスキーマ、

  4. 権限処理とキャッシング戦略、

  5. MSA環境におけるFederation設計まで

結局重要なのは「GraphQLの文法」ではなく、データの流れをどのように設計するかという観点です。 🚀

実際の講義内容をチラ見せ 🍡

Prismaを活用したデータマイグレーションおよびGUI

Databaseの最も致命的な問題であるN+1問題を防止するためのDataLoaderパターン

非同期およびイベント通信(PubSub)のためのSubscriptionパターン

この講義を一緒に準備してくださったカカオ面接官の方の経歴 🤭

12年目のバックエンドサーバー開発者で、カカオでサーバー開発をしながら面接官としても活動しているChoiと申します。

Hongさんとは以前Conferenceで縁があり、講義活動の中盤から継続して共に積極的に参加しながら、多様なテーマで講義を作ってきた経歴があります。このように講義を作り上げながら、多くの方々と対話しコミュニケーションをとることは、私の開発者人生において大きな助けとなり、多様な視点を学べる時間であると考えており、より幅広いテーマを扱うために努力しています。

いわゆる大企業という一つの経歴が良い開発者であることを証明するとは思いませんが、少なくとも一般的なプラットフォームに比べて、より多くのトラフィックと経験を得られると考えています。このような部分を常に講義に盛り込みながらお伝えしていきたいと思います。

[現] カカオ本社 サーバー開発者

[前] ソウル4年制コンピュータ工学専攻

実習環境

  • OS :

    Apple M3 Air

  • Node : v25.5.0

  • IDE : VsCode

こんな方に
おすすめです

学習対象は
誰でしょう?

  • Swaggerを修正してAPIドキュメントを合わせる作業が繰り返されるたびに、「なぜ同じことを二度やっているんだろう?」と思っているバックエンド開発者

  • 画面一つを作るためにREST APIを複数呼び出し、フロントエンドとデータスペックの調整を続けることに疲れ果てている開発者

  • GraphQLの文法は少し目にしたことがあるが、実際のResolverの構造や実務的な設計手法についてはまだイメージが湧いていない開発者

  • MSA環境や大規模サービス構造において、データフローをどのように接続し管理すべきか悩んでいるサーバー開発者

  • 単なる技術の使い方よりも「なぜこのような技術が登場し、どのような問題を解決しようとしているのか」を理解しながら成長したい開発者

前提知識、
必要でしょうか?

  • 初心者向けの講座です!難易度が低いため、事前知識は必要ありません。

こんにちは
Hongです。

インフラン認証

キャリア認証

9,462

受講生

585

受講レビュー

157

回答

4.7

講座評価

32

講座

自己紹介

家でだらだら過ごしていたところ、開発に興味を持ち始めて勉強をスタートし、現在は板橋(パンギョ)でプラットフォームサーバーの開発を担当しています。私が勉強してきた方法や、実務で直面する可能性のある様々な問題点とその解決策を皆さんに提供したいと考え、知識共有者としての活動を続けています。

 

講義は私一人の知識だけで作られるものではありません。すべての講義には、共に作り上げてくださる方々がいます。

 

知識共有者の経歴

[前] サンドボックスIP関連ブロックチェーン開発者

[前] メタバースバックエンド開発者

[] 板橋(パンギョ)でベテランになりつつあるサーバー開発者

 

インタビュー履歴

その他の問い合わせ

  • unduck2022@gmail.com

カリキュラム

全体

16件 ∙ (3時間 58分)

講座資料(こうぎしりょう):

授業資料
講座掲載日: 
最終更新日: 

受講レビュー

まだ十分な評価を受けていない講座です。
みんなの役に立つ受講レビューを書いてください!

期間限定セール

¥30,360

60%

¥9,896

Hongの他の講座

知識共有者の他の講座を見てみましょう!

似ている講座

同じ分野の他の講座を見てみましょう!