はじめに
今回は社内勉強会のレポートです。
定期的に社内のエンジニアで集まって勉強会を行っています。
勉強会のノリとしてはだいぶ緩く、お題はなんでもいいんですが参加者が気になっている技術などについてあまり前準備なく、みんなで調べて見解を共有するという感じのものです。
具体的に質問や議論があればそれらをテーマにすることもありますが、社内勉強会では参加するメンバーが別々のプロジェクトチームに所属していることが多いので、共通して興味のありそうなものを選択します。
今回はGraphQLについて調べてみました。
GraphQLとは
参考: GraphQLを徹底解説する記事 参考: 15分で分かった気になるGraphQL
まずは理解度を確認するために、GraphQLとは何かをざっくりと確認します。
GraphQLはクエリ言語であり、REST APIの代替として開発されました。
特に複雑なデータ構造や多様なクライアントのニーズを持つアプリケーションで有効なようです。
こちらのスライドにあるように、クエリを送ることで必要なデータを取得できるようになります。
OverFetchとUnderFetch
オーバーフェッチ(OverFetching)
定義: オーバーフェッチは、クライアントが必要以上のデータを取得する状況を指します。
REST APIでの問題: RESTでは、エンドポイントが固定されたデータセットを返すため、クライアントが必要とする特定の情報だけではなく、余分なデータも含まれることが多いです。
GraphQLによる解決: GraphQLでは、クライアントが必要なデータのみを指定してクエリを送ることができます。このため、余分なデータの取得を避け、効率的なデータ取得が可能になります。
アンダーフェッチ(UnderFetching)
定義: アンダーフェッチは、クライアントが一度のリクエストで必要なデータをすべて取得できない状況を指します。
REST APIでの問題: 一つのエンドポイントからは限られた情報しか取得できないため、複数のリソースを組み合わせる必要がある場合、複数のAPIリクエストを行う必要があります。
GraphQLによる解決: GraphQLでは、一つのクエリで複数のリソースや関連するデータを同時に取得できます。これにより、必要なすべてのデータを一度のリクエストで効率的に取得することが可能です。
弊社では、基本的にRESTfulなAPIを作成しているため、このあたりの辛さはあるよねといった課題感を再確認します。
メリット、デメリット
参考: GraphQLを導入する時に考えておいたほうが良いこと
GraphQLのメリット
GraphQL自体はさまざまなWebサイトやブログ等でメリットやデメリットが解説されていますが、まとめると以下のような内容になります。
- 効率的なデータ取得: クライアントは必要なデータのみをリクエストでき、オーバーフェッチやアンダーフェッチを防ぎます。
- 柔軟なクエリ: 複数のリソースを一つのクエリで取得でき、APIリクエストの数を減らすことが可能です。
- リアルタイムデータ: サブスクリプションを利用することでリアルタイムのデータ更新が容易になります。
- 自己文書化: クエリ言語がスキーマに基づいているため、APIの文書化が容易になります。
GraphQLのデメリット
- 複雑なクエリのパフォーマンス: 深くネストされたクエリはサーバーに大きな負荷をかける可能性があります。
- キャッシュの難しさ: HTTPキャッシュの利用がRESTに比べて難しくなることがあります。
- 学習曲線: 新しいクエリ言語の学習とシステムへの適応には時間がかかることがあります。
- ファイルアップロード: 標準のGraphQLはファイルアップロードを直接サポートしていないため、実装にはカスタムスキーマや追加のライブラリが必要になることが多いです。
- エラーハンドリング: デフォルトではGraphQLはエラーを返さず、全てステータスコード200となります。エラーはあくまでレスポンスの内容という形をとります。
- モニタリング: すべてのリクエストが同じエンドポイントを使用するため、リクエストの種類を識別しにくいことがあり、モニタリングが複雑になることがあります。
REST APIのメリット
- 広範なサポートと成熟度: 広く使われており、多くのツールとライブラリが利用可能です。
- シンプルな設計: 理解しやすく、多くの開発者にとって馴染み深いです。
- キャッシュの利用: HTTPキャッシュメカニズムを簡単に活用できます。
- ファイルアップロード: RESTはマルチパートフォームデータをサポートしており、ファイルアップロードが比較的簡単に実装できます
REST APIのデメリット
- オーバーフェッチとアンダーフェッチ: 必要ないデータの取得や、複数のリクエストが必要な場合があります。
- 固定されたデータ構造: エンドポイントが固定されたデータセットを返すため、柔軟なデータ取得が難しいです。
- 多くのエンドポイント: 多様なデータニーズに対応するために多くのエンドポイントを設計する必要があります。
GraphQLの実装
GraphQLは特定のライブラリではなく、RESTのようなアーキテクチャの一つです。そのため、具体的な実装方法はいくつか存在します。
PHPにおいては、LightHouseというGraphQLの実装があります。
また、一般的に知られているのは、Apollo ServerというGraphQLの実装です。
https://www.apollographql.com/
採用事例
GraphQLの概要がなんとなく掴めてきたところで、実際に採用している事例を見てみます。
Next.js + NestJS + GraphQLで変化に追従するフロントエンドへ 〜 ショッピングクーポンの事例紹介
How Netflix Scales its API with GraphQL Federation (Part 1)
考察
採用事例をみて、参加者で気付いたことを話し合いました。
- コンテンツの配信のようなリソースの種類や量が多く、1ページの情報量が多いプロダクトがほとんど
- 発信力もあるかもしれないが、比較的有名なサービスが多い
また、下記のようなサイトも参考にしました。
この回答では、以下のような内容が説明されています。
- マイクロサービスをまとめるためのBFFとしては非常に有効
- GraphQL特有の問題がある(N+1、クエリのコスト)
- フロント、バックが同じチームならREST APIで十分
確かに、マイクロサービスの場合、BFFとしてGraphQLを採用することで、フロントエンドの開発者が必要なデータを自由に取得できるようになります。
弊社での採用についても少し意見を出しました。
- 弊社のプロダクトの場合、マイクロサービスではなく、フロントとバックも分かれていないことが多い
- 採用事例のようなコンテンツの配信のようなリソースの種類や量が多く、1ページの情報量が多いプロダクトはスマレジアプリマーケットくらい
- ただし、リソースの量や開発規模を考慮するとGraphQLを採用するほどのモチベーションはないんじゃないか
脱線
REST APIへの対抗策として、こんなのもあるよと私の方から提案したのが、tRPCというものです。
個人的に副業や個人開発を通してフロントエンドの技術を触っていて、キャッチアップした内容を簡単に共有しました。
Next.js14や、Blitz.jsといったフレームワーク、T3 Stackと呼ばれる技術スタックなどがあり、フロントエンド界隈でのREST API以外のアーキテクチャの動きについて共有しました。
まとめ
今回はGraphQLについてざっくりと調べてみました。
- GraphQLはクエリ言語であり、REST APIの代替として開発されました。
- GraphQLは特定のライブラリではなく、RESTのようなアーキテクチャの一つです。
- GraphQLのメリットとしては、効率的なデータ取得、柔軟なクエリ、リアルタイムデータ、自己文書化があります。
- GraphQLのデメリットとしては、複雑なクエリのパフォーマンス、キャッシュの難しさ、学習曲線、ファイルアップロード、エラーハンドリング、モニタリングがあります。
- GraphQLの実装としては、LightHouseやApollo Serverがあります。
- GraphQLの採用事例としては、メルカリShopsやYahoo!ショッピング、Netflixなどがあります。
- 弊社で採用する候補としては、スマレジアプリマーケットがありますが、リソースの量や開発規模を考慮するとGraphQLを採用するほどのモチベーションはないんじゃないかという結論になりました。
所感
このようなゆるい勉強会を定期的に行っています。
直接的な業務ではなくても、特定の技術にたいして「名前は聞いたことある」程度から「概要は掴めた」程度まで解像度を上げていくことができるので、個人的にはとても良い勉強になっています。
また、社内のエンジニアの技術力や興味のある技術についても知ることができるので、社内の技術力の向上にもつながっていると思います。
ちなみに、弊社ではPHPやLaravelといった技術を採用しているため、このあたりがテーマになった時はもう少し深掘りした内容となることが多いです。
