なぜ私たちはほとんど GraphQL を使わないのか（そして、使う時）

GraphQL は素晴らしいツールですが、Xenotix Labs がリリースする製品の 90% にとっては、デフォルト設定としては間違った選択です。30 以上の本番環境アプリでの経験に基づいた私たちの論理をここに紹介します。 GraphQL が真に役立つのは、(1) 非常に異なるデータ構造要件を持つ多数のクライアントがいる場合、(2) REST エンドポイントが over-fetch してしまうような深くネストされた関係性を持つデータがある場合、(3) サービスの上部にスキーマ層を管理する規律を持つチームである場合です。Shopify、Facebook、GitHub などはこれらの条件を満たしますが、大多数のスタートアップの MVP では該当しません。 インディアン起業家の MVP では、単一のモバイルアプリ、単一の管理ダッシュボード、同じチームによる構築、エンドポイントが 100 個未満の場合、REST がシンプルで優れた選択です。世界中のどのエンジニアも REST 呼び出しのデバッグを知っています。OpenAPI 仕様は簡単に生成できます。URL プレフィックスによるバージョン管理は手っ取り早い。HTTP セマンティクスによるキャッシュは無料です。 私たちは ClaimsMitra（8 サービスにわたる 114 つ以上のエンドポイント）、Legal Owl（7 ユーザー persona を持つ LegalTech）、Veda Milk（D2C 購読サービス）、Cricket Winner（Kafka と WebSockets を使用したリアルタイムクリケット、リアルタイム以外には REST を使用）、Growara（WhatsApp 自動化）に REST を使用しています。どこに GraphQL もありません。 私たちは GraphQL を端からエンドまで使用した 1 つのプロジェクトしかリリースしていません：複数のコンテンツソース（YouTube、PDF、クイズ、ユーザー生成ノート）を持つ教育コンテンツ集約器、そして異なる 4 つのクライアントアプリ（学生、教師、保護者、管理者）。各クライアントは、同じ下位データから異なるスライスを読み取るように求めています。GraphQL は、REST エンドポイントを 4 倍書き直さないように助かりました。 そこでも、GraphQL レイヤルは薄く保持しました。それは REST マイクロサービスを覆うゲートウェイであり、ビジネスロジックを完全書き直したものではありません。GraphQL レゾルバーは、私達の内蔵 REST API を呼び出し、レスポンスを構成します。これにより、サービス側は REST に引き続き従いつつ、クライアント側が GraphQL 表面を提供し続けることができます。 GraphQL の複雑さは、認証、エラーハンドリング、キャッシュにおいて現れます。認証は、エンドポイント 1 つに 1 つのミドルウェアではなく、フィールドごとの、またはレゾルバーごとの認証が必要で、これはより多くのコードと境界事例を必要とします。エラーハンドリングは、GraphQL レスポンサーが部分的に成功し得るため、理屈立てるのに困難です。キャッシュは、HTTP キャッシュを失い、独自のものを発明する必要があります。 さらに、N+1 クエリーは、思っている以上に簡単に陥り得ます。DataLoader は助けになりますが、自動化されていません。私達はある GraphQL パフォーマンスリグレスをデバッグしましたが、REST では不可能なものがあったのです。 モバイルアプリ 1 つ、ウェブダッシュボード 1 つ、そして 150 個未満の API エンドポイントを持つ起業家であれば、REST をデフォルトにしてください。クライアント表面が 3 つ以上あり、 materially（質的に）異なるデータ要件を持っている場合、またはチームがスキームファーストの規律を真に望む場合のみ、GraphQL を探してください。 私達からインディアン企業で 30 つ以上の本番アプリをリリースしています。Flutter、Next.js、AWS 上での Node.js。Veda Milk（D2C ドairy）、Cricket Winner（Kafka と WebSockets を使用したリアルタイムクリケット）、Legal Owl（LegalTech スーパーアプリ）、ClaimsMitra（114 つ以上の REST API）、Growara（AI WhatsApp 自動化）、7S Samiti（インドの農村部向けオフラインファースト AI トレーナー）。MVP をリリースしており、最もシンプルで機能するスタックを探している場合は、https://www.xenotixlabs.com を訪問するか、leadgeneration@xenotix.co.in へメールをお送りください。

GraphQL is a great tool. It is also the wrong default for 90 percent of the products we ship at Xenotix Labs (https://www.xenotixlabs.com). Here is our reasoning after 30+ production apps. GraphQL genuinely helps when (1) you have many different clients with very different data shape requirements, (2) your data has deep nested relationships that REST endpoints would over-fetch on, and (3) your team has the discipline to maintain a schema layer on top of your services. For Shopify, Facebook, GitHub, these conditions are true. For most startup MVPs, none of them are. For an Indian founder's MVP: a single mobile app, a single admin dashboard, both built by the same team, with <100 endpoints. REST is the simpler choice. Every engineer on the planet knows how to debug a REST call. OpenAPI specs are easy to generate. Versioning via URL prefix is straightforward. Caching via HTTP semantics is free. We use REST for ClaimsMitra (114+ endpoints across 8 services), Legal Owl (LegalTech with 7 user personas), Veda Milk (D2C subscription), Cricket Winner (real-time cricket on Kafka + WebSockets, with REST for non-realtime), and Growara (WhatsApp automation). No GraphQL anywhere. We shipped one project on GraphQL end-to-end: an educational content aggregator with multiple content sources (YouTube, PDFs, quizzes, user-generated notes) and 4 different client apps (student, teacher, parent, admin). Each client wanted different slices of the same underlying data. GraphQL saved us from writing 4x the REST endpoints. Even there, we kept the GraphQL layer thin—it's a gateway over REST microservices, not a full rewrite of the business logic. The GraphQL resolvers call our internal REST APIs and compose the response. This lets us stay REST-native on the service side while still serving a GraphQL surface to clients that need it. GraphQL's complexity shows up in auth, error handling, and caching. Auth: instead of one middleware per endpoint, you need per-field or per-resolver auth, which is more code and more edge cases. Error handling: a GraphQL response can be partially successful, which is hard to reason about. Caching: you lose HTTP caching and have to invent your own. Also: N+1 queries are easier to stumble into than you'd think. DataLoader helps but isn't automatic; we've debugged GraphQL perf regressions that would have been impossible in REST. If you're a founder with 1 mobile app, 1 web dashboard, and <150 API endpoints, default to REST. Reach for GraphQL when you have 3+ client surfaces with materially different data needs, or when your team genuinely wants the schema-first discipline. We ship 30+ production apps from India. Flutter, Next.js, Node.js on AWS. Veda Milk (D2C dairy), Cricket Winner (real-time cricket on Kafka + WebSockets), Legal Owl (LegalTech super-app), ClaimsMitra (114+ REST APIs), Growara (AI WhatsApp automation), 7S Samiti (offline-first AI tutor for rural India). If you're shipping an MVP and want the simplest stack that works, visit https://www.xenotixlabs.com or email leadgeneration@xenotix.co.in.