|
|
|
|
|
|
by andrewingram
2754 days ago
|
|
|
One point of clarification (or correction, not quite sure) - using GraphQL as an API Gateway (as opposed to the GraphQL server directly talking to the data layer) for 1st-party clients is actually pretty common in the GraphQL world. What's less common is using the GraphQL server for service-to-service communication, though i've been aware of people using it this way for my entire 3 years with GraphQL. I'm not yet convinced it's superior to alternative solutions to this problem (like gRPC, Thrift, other API Gateway patterns like JSON-API), but it could well be. I'm still happy using GraphQL in its sweet spot (and not-coincidentally what it was designed for), which is building an API for 1st-party websites and apps. |
|
|
For example, in one case we had around a dozen services with fairly typical REST APIs, a few of which we wanted to pull large inter-related sets of information from. Using GraphQL allowed us to:
- Have a single large-but-human-readable query to retrieve all report data.
- Analyze deep nesting up front to determine opportunities for caching and eager loading.
- Abstract details regarding what data was coming from what service, plus handle any quirks (e.g. inconsistent auth strategies) at the GraphQL layer.
Without having to make many modifications to the underlying services. We also saw a two-order-of-magnitude performance improvement that would otherwise have required building out a lot of service-specific awareness into our reporting service.
Granted reporting is a unique case, but the simplified gateway layer and potential for query analysis are also major advantages as the number of API consumers grows.