When to use GraphQL, gRPC, REST, and Webhooks
- Language agnostic: GraphQL uses its own schema definition language that can be incorporated into most servers, irrespective of the underlying languages or frameworks they use.
- Single endpoint: Requests made with GraphQL query a single endpoint. These requests contain the shape of the data and the fields required, and the endpoints return exactly what the request needs. This makes GraphQL queries much more efficient than traditional REST queries, where multiple requests might be needed to get sufficient data.
- Strongly typed: GraphQL has strongly-typed schemas. These schemas act as contracts between the client and the server, allowing API consumers to know the exact type of structure the data should have.
- Complexity in caching: Unlike REST APIs that support caching requests by default, setting up caching for GraphQL is a complex and challenging process.
- Difficulty in error handling: GraphQL requests always return HTTP 200 (OK) status codes, even if there are errors in the GraphQL layer. When errors occur, they are placed in the “errors” key in the response while still returning the 200 status code. Hence, developers find it difficult to distinguish between successful and failed requests.
When to use GraphQL
- Applications that are bandwidth-sensitive: GraphQL is more suitable for platforms such as smartphones or IoT devices, where it becomes critical to manage the amount of requested data. Using GraphQL to return the exact data required by applications hosted on these devices reduces bandwidth consumption.
- Applications that use data from multiple data stores: GraphQL can build responses from multiple data sources. All the data can then be nested into a single response, making it useful for applications such as reporting dashboards.
- Lightweight clients: gRPC allows clients to offload computations to remote servers, making them more lightweight.
- High efficiency: gRPC uses protocol buffers (Protobufs) to communicate more efficiently between clients and servers than traditional REST APIs that use JSON objects. Protobufs are language and platform-neutral systems that are used to serialize data into binary, making the messages smaller in size and faster to transmit.
- Open source: gRPC is an open-source protocol designed as a successor to HTTP. It aims at allowing developers to focus on the contracts between applications and servers, offloading features such as compression and stream prioritization to the underlying protocols.
- Limited browser support: gRPC relies heavily on the HTTP/2 protocol, which most popular browsers still do not widely support.
- Limited community support: gRPC has still not received as much community involvement as other protocols. GraphQL has slightly more than 17,000 discussion threads on Stack Overflow, while gRPC has less than 5,000.
- Protobuf is not human readable: Files are compressed into a non-human readable format by Protobuf, unlike other protocols that use XML or JSON.
When to use gRPC
- Real-time streaming communication services: gRPC works well for real-time streaming communication services that require lightweight and efficient message communications.
- Micro-service architecture: Protobufs in the gRPC framework allow developers to create services that can communicate with each other efficiently and independently using their preferred programming language.
- Uniform interface
- Well-established standard: REST has been a long-standing standard for web application development and has a large community of developers supporting it.
- Simple, scalable, and predictable: Comprehensive documentation makes it simple to develop applications with REST. It uses standardized parameters with responses that have predictable structures and status codes. With REST, clients and servers can scale independently, making it very flexible to use.
- Caching support: REST uses caching by default, allowing browsers to cache requests locally. Subsequent requests can validate whether the cached data is still valid before making another request to the server.
- Overfetching: REST APIs tend to return more data than that requested by the clients.
- Underfetching: When a server does not return enough information to any request, the client needs to make additional queries, making the process inefficient.
When to use REST
- Developing public APIs: Since REST is highly standardized, it is better for developing public APIs that are going to be consumed by a large number of clients.
- Developing simple applications: REST APIs are easy and quick to implement, making them a good option for simple applications.
- Easy updates: Webhooks are ideal for pushing data into applications where the client needs to be updated regularly. It is far more complex to cater to such requests using GraphQL or REST.
- Simple setup: Webhooks are easy and straightforward to set up.
- Difficulty in complex operations: Webhooks only enable receiving data on the client-side, so they become difficult to use for more complex operations.
When to use Webhooks
- Developing automation services: Webhooks make it easy to develop automation services that can be triggered by servers when required.
- Notification services: Webhooks can post data to clients when triggered to update clients with notification messages.
If you enjoyed our blog, and want to work on systems and challenges related to globally distributed systems, serverless databases, GraphQL, and Jamstack, Fauna is hiring!
Subscribe to Fauna's newsletter
Get latest blog posts, development tips & tricks, and latest learning material delivered right to your inbox.