The most practical use case for GraphQL, and the one it was originally designed to support, is a client (iOS or Android app, or Web app) requesting data from a server.
Choosing GraphQL or REST (or other data services like Thrift) depends on the constraints of your application and services.
REST is often the right choice when you need your data access to align tightly to HTTP. For example, if you rely heavily on HTTP-level caching, or if you need to represent data spread across many different domain services which use URLs to reference other data.
GraphQL is often the right choice when network speed and latency is the primary concern and data isn't spread across different domains but is instead centralized to one product. In this case a single network request can load many different kinds of resources at once, and selectively include only what that client needs. Particularly on mobile network connections, this can be a dramatic performance improvement. However caching data may require more sophisticated techniques.
Thrift, or something like it, is often the right choice when network speed is not a concern, but memory and CPU pressure on the server is, and caching is inappropriate. This is often a good choice for service to service communication, which often occurs within or between data-centers.
”However, caching data requires more sophisticated techniques.” Can you elaborate further?
@vivalapanda sure - caching the results of REST endpoints typically means just using the browser's existing cache (or a rough equivalent if not using a browser). Since GraphQL composes all data needed into a single response, simply caching that network response is not a very flexible cache strategy. There are a wide range of cache strategies that you could take (same goes for REST), and the Relay store represents what a very sophisticated GraphQL client cache looks like.
Lee Byron
Engineer @ Facebook
The most practical use case for GraphQL, and the one it was originally designed to support, is a client (iOS or Android app, or Web app) requesting data from a server.
Choosing GraphQL or REST (or other data services like Thrift) depends on the constraints of your application and services.
REST is often the right choice when you need your data access to align tightly to HTTP. For example, if you rely heavily on HTTP-level caching, or if you need to represent data spread across many different domain services which use URLs to reference other data.
GraphQL is often the right choice when network speed and latency is the primary concern and data isn't spread across different domains but is instead centralized to one product. In this case a single network request can load many different kinds of resources at once, and selectively include only what that client needs. Particularly on mobile network connections, this can be a dramatic performance improvement. However caching data may require more sophisticated techniques.
Thrift, or something like it, is often the right choice when network speed is not a concern, but memory and CPU pressure on the server is, and caching is inappropriate. This is often a good choice for service to service communication, which often occurs within or between data-centers.