REST vs gRPC vs GraphQL
September 26, 2024
💡 How to choose the right API framework for your needs.
Building a new application and confused about all of the API framework options? You aren't alone. There are a lot of options for you and your team to build your back-end and front-end APIs, so we will go through the options and compare them. Don't worry we won't bring up SOAP/XML or any other older API technology.
TLDR: Take a look at our comparison table at the end of this article.
REST, JSON & OpenAPI
REST is by far the most used API framework today and is used by front-ends to communicate to back-ends as well as micro-services. It is based on HTTP and usually follows the HATEOAS concept.
REST APIs use HTTP actions as "verbs". HTTP GET is used to retrieve information while HTTP POST is usually used to create an object.
You will see that we've used the word "usually" a few times and that is because REST isn't really a framework and its rules are very loose. While most REST-based APIs are similar, they can also be very different and are almost always a dis-organized can-of-noodle-soup in terms of objects, path structures, and HTTP verbs.
JSON is almost always used as the data format. OpenAPI (previously known as Swagger) can be used to define the API.
GraphQL
REST can cause a lot of HTTP calls to pick up all of the data that you need for a front-end application. You call /user to get the current user, then call /todos to pick up their TODOs, then /news to pick up your app's news, ...
GraphQL comes to the rescue by creating a powerful querying language which can also specify which fields and objects to return.
While GraphQL has nowhere near the popularity of REST for BE <> FE APIs, some large companies have moved to this framework, most notably Shopify.
gRPC & Protobuf
The newest entrant into API frameworks is Google's gRPC. (no brownie points for guessing what the ‘g' stands for)
The main premise for gRPC is that the actual mechanics of the call are hidden and the API is defined as a series of function/methods calls like any other in your code.
The actual communication is somewhat hidden as well, but is usually run through HTTP/RPC and almost always uses the Protobuf data format.
Protobuf is sent in a binary format and so it is very compact and fast. This is one of the main reasons that gRPC+Protobuf are popular with internal micro-services. There currently isn't a lot of use of gRPC between FE and BE due to the lack of support on front-end frameworks.
Comparison
| REST | GraphQL | gRPC | |
|---|---|---|---|
| Used for Front-End calling a Back-End API | ✅ Almost always | ✅ Up-and-coming | ❌ Not really (yet) |
| Used for micro-services | 🤷♂️ Sure, but... | 🤷♂️ Sure, but... | ✅ Oh yea! |
| Used for customer-facing API | ✅ REST is well understood and has the most language support | 🤷♂️ Unless your customers have very technical developers, GraphQL could slow them down in implementing your API | ❌ While this should be the best choice, there simply isn't sufficient language support nor wide-spread understanding of gRPC to make it your first choice for a public API. |
| Data Format | 🤷♂️ JSON (text) | 🤷♂️ JSON (text) | ✅ Protobuf (binary) |
| API Definition | ❌ OpenAPI / Swagger (sometimes) | ✅ GraphQL Schema | ✅ Protobuf schema |
| Speed | ❌ Lots of independent calls plus text JSON results make REST the slowest option | 🤷♂️ GraphQL can be quick if you return just the needed fields and also return other relevant objects (plus use GZIP with the HTTP response). But if you run it like REST with single object queries, then it will be just as slow. | ✅ gRPC is by far the fastest option as the data is in binary and the results can be anything you want (and not just a single type of object as in REST) |
Good News
The good news is that Unified.to's APIs are accessible by all three API frameworks.