If you’ve read an article or even some brief description of GraphQL, it probably included a line about what it does better than REST and other APIs. Glancing over the question like that isn't really fair though is it? You won't get the whole picture without really looking at each API’s uses and advantages so let’s try to dig a bit into that here.
GraphQL - the new standard
GraphQL is a flexible system for requesting data that focuses on pinpoint requests and delivering exactly what is required. What sets GraphQL apart from other APIs is its unique approach, it’s client-driven. Instead of handling it as usual i.e. server to a client, here the client decides how everything is handled. The main benefits are:
- adaptability - the client decides what data they want, how they want it and what format they want to get it in,
- efficiency - delivers exactly what the client requests without over fetching,
- flexibility - GraphQl is cross-platform and supports more than a dozen languages (Perl, Java, Python, PHP among others).
The most well-known example of GraphQL application is probably GitHub. They switched to it in 2016 citing scalability and flexibility as the two major reasons. REST simply wasn't cutting it for them, because it often required multiple requests to get the data you wanted and also over-fetched data on each of those requests. With GitHub’s rapid growth and user base in the tens of millions, you can imagine how big a concern that had to be. GraphQL provided exactly the alternative they needed because it’s focused on the client being able to request particular data in a specific format for a specific use.
REST - still most popular one (?)
After voicing some complaints about it it’s only fair to take a look at REST. Even though some question if it’s not outdated it’s still the most commonly used API. REST is a stateless architecture for data transfer. RESTful systems put an emphasis on statelessness and hypermedia. Unlike GraphQL here the concerns of client and server are separated. The usually mentioned advantages are:
- performance - best suited for systems requiring rapid iteration and HTTP standardized verbiage,
- scalability - allows the support of large numbers of components and interactions among them,
- simplicity - REST has a uniform interface which simplifies and decouples the architecture,
- modifiability - components can be modified to fit changing needs even while the application is running.
As mentioned above, REST is still the most popular API. Twitter, Facebook, Google, and Paypal are all using RESTful APIs. REST can tie together a variety of resources that can be requested in a number of ways and in different formats for various purposes. If you need a more general-purpose API than the pinpoint GraphQL this is the one for you.
gRPC - performance at all costs
gRPC is a lightweight and quick system for requesting data, it’s a fresh take on an old method called Remote Procedure Call or RPC. The main difference here is how it defines it’s contract negotiations. REST defines interactions through standardized terms in its requests, GraphQL runs requests against a created schema to fetch exactly what is required. RPC functions on contracts, the negotiation is defined by the relationship between the server and the client not by the architecture. Most of the power relies on the client-side while handling and computations are offloaded to a remote server hosting the resource. To put it short the key advantages are:
- it’s lightweight, requires very little resources which makes it a handy solution for even extremely low powered situations
- it’s efficient, gPRC uses protobufs, a method of serializing structured data which focuses on serializing communication in an effective manner
- it’s open-source and can be freely used, modified or forked
In short, gRPC is suited for systems that need a set amount of data or processing routinely and in which the requester is low power or wants to preserve resources. The best examples are immensely popular IoT devices like voice controllers, smart light switches, smoke alarms locks, and cameras.
Source: grpc.io
One size does not fit all
As you can see each of these options has its own applications and advantages. There is no clear winner here and what you should use, or rather what you want to use, depends mostly on your aims and approach. So now that you hopefully know a bit about each of them, look into what would best fit your project and pick the right one for yourself.
A guest blog post for GraphQL Editor blog by Michal Tyszkiewicz
Speed up your GraphQL API development
GraphQL Editor is a supportive tool for both advanced GraphQL users as well as those taking their first steps with GraphQL APIs. Our all-in-one development environment for GraphQL will help you build, manage & deploy your GraphQL API much faster. Try GraphQL Editor for free!
Top comments (0)