gRPC vs REST: New Possibilities and Proven Practices
For a long period REST was considered a number one option for Application Programming Interface (API) design. But as time goes by, new technologies and approaches emerge and evolve giving rise to alternative solutions.
We at Surf have been on the app development market since 2011, which gave us a chance to witness approaches and technologies extending and replacing each other. We can even consider ourselves pioneers in checking new ways to deliver quality and high-performance products.
In this article we suggest discussing REST and gRPC: whether they are comparable, what their purposes are, their pros and cons and use cases, and how to choose the effective approach to API design for your project. Let’s start off with their definition and main pros and cons.
What is REST?
Representational state transfer (REST) is a software architectural style that was created to guide the design and development of the architecture for the World Wide Web.
Advantages of REST
REST is a good choice for complicated systems to be developed by several distributed teams who do not know much about each other. And this is due to some advantages such as:
- simple and commonly used conception: any junior engineer has some experience with REST and there is no need to explain how it works;
- HTTP possibilities used to the maximum: these possibilities include caching, response state codes, modifiers;
- server and client exist separately: they may have different speeds, different set of features;
- wide range of profiler tools available: a tester can define bug origin without involving developers;
- easy-to-use frameworks for most programming languages and platforms.
In 2015, when we started developing an iOS food delivery app for O’KEY, we built a REST API to integrate the app with the backend, and developed a native iOS app with Objective-C. The app was successfully launched and used for several years with the same code base.
Disadvantages of REST
The question may arise: when things run so smoothly with REST, why to look for any other solution?
The point is that REST does work well,but it has some weaknesses too.
- Diversified understanding and interpretation of principles as REST is an architecture style, but not a standard, protocol, or framework;
- A need to describe interfaces and data structures;
- Complex synchronization of changes between nodes and only a few methods to automate it:
- Impossibility to reuse the services for working with API between platforms;
- Low scalability;
- Streaming is impossible (the option here is to to use WebSockets or other technology/library additionally for streaming. But more technologies within one project make the code base more complicated).
As we’ve mentioned, we are used to looking for new solutions and approaches. Therefore, when gRPC appeared we studied it to see the difference between gRPC and REST and what advantages we can get using gRPC.
What is gRPC?
Definition
gRPC is a modern open source high performance Google Remote Procedure Call (RPC) framework that can run in any environment. gRPC was created in 2015 and grew into an alternative for REST.
gRPC advantages
gRPC is created to connect services in and across data centers and connect devices, mobile apps and browsers with backend services. The advantages that gRPC offers include:
- support for 11 programming languages (C#, C++, Dart, Go, Java, Kotlin, Node, Objective-C, PHP, Python, Ruby);
- simple declarative service description;
- fast integration and scalability;
- integration with actual technologies (Kotlin coroutines, Rx, etc.);
- bidirectional streaming (gRPC also works with a single request where the client sends the request and gets back a single response).
We used all gRPC pros highlighted to develop Twim, a cryptocurrency exchange app. For the apps in the exchange domain, it is vitally important that the quotes are constantly updated in real time. So, we needed to maintain a high data transfer rate — up to 20 times per second. Instead of REST, we used a bunch of gRPC, HTTP/2 and protocol buffers (protobuf) together with RxJava to increase speed of data transfer.
The protobuf serialization protocol worked as a good alternative to JSON. It quickly packaged the data for the client and server in binary format, optimized for the minimum message size.
gRPC disadvantages
Our experience with gRPC for the cryptocurrency exchange app was successful. But still, before embracing a brand new approach, it is better to know the disadvantages as well. And we’re not going to lie- gRPC has some:
- no versioning we used to with REST;
- no sufficient error processing;
- no out-of-the-box caching;
- no browser support;
- complicated profiling and sniffing.
Now, let’s go into a more detailed comparison of gRPC and REST and in what way their pros and cons may influence the choice for a specific project.
gRPC and REST
The first and obvious difference is the protocol used: HTTP/2 vs HTTP/1.1. What does it mean? HTTP/2 has some pros as compared to HTTP/1.1:
- Binary protocol: HTTP/2 uses binary, but not text format, therefore it is more compact and faster;
- Multiplexing: HTTP/2 may send multiple streams of data at once through a single Transmission Control Protocol (TCP) connection. As a result, resources don’t block each other, as it may happen with HTTP/1/1;
- Compressed headers: small files load faster;
- Server Push feature: allows to reduce a number of additional requests.
gRPC opens some new possibilities for developers that allow improving performance and quality level. It also enables preserving the single architecture style (for example, no need to combine REST with WebSockets for streaming) and creating live and quickly updatable UI.
When we considered gRPC for our project, we compared the performance of gRPC and JSON (JSON is one of the most commonly used formats that API providers can use to deliver data in the REST architecture). For benchmarking, we used a simple data structure (production cases are usually much more complicated) and checked how the time of the processes depends on the number of objects.
Here are the results for serialization and deserialization processes where the curve looked somewhat different, but the overall picture was clear.
40 objects in JSON weigh about 4 times more than 40 objects in proto structure, and we’re talking about 40 objects only. Our production routine usually implies much more objects and the volume can be much higher, correspondingly.
Summing up
In conclusion, we would like to highlight once again that gRPC undoubtedly has some advantages: starting from being developed by Google and successfully used by companies like Square, Netflix, Cisco, and other major market players (which means the framework has solid community support, as well as successful use cases by industry giants) to better performance and streaming possibilities.
But when choosing any technology or tooling for your project, you should take into account its disadvantages as well. Make sure the technology you want to use:
- is able to meet your business-goals;
- has no technical limits that can affect future development of your product;
- has proven itself in practice;
- has specifications and standards to comply with;
- is scalable and allows easy integration for further product growth;
- will have reasonable expenses to implement your project.
If you need any additional information or advice on any technology, call us and we will be glad to discuss it with you.
