gRPC vs. REST: Performance Simplified
--
“Breaking down the monolith”. These were words I heard several times over the course of my previous internships. Companies everywhere are realizing the benefits of building a microservice-based architecture. From lower costs to better performance to less downtime, microservices provide countless benefits relative to their preceding monolithic design. Now with all of these microservices talking to each other thousands of times each second, communication between them needs to be fast and reliable. The traditional method of doing this is JSON-backed HTTP/1.1 REST communication. However, alternatives such as gRPC provide significant benefits in performance, cost, and convenience.
Problem
When classes inside a monolithic service communicate with each other, they do so through well-defined interfaces. These interfaces come with language-native objects to use to pass into and accept from them. Most errors in format and usage would be caught by the compiler and no new objects have to be created by consumers. Any conversion that happens between objects through converters and populators is done at a binary level, and not into a human-readable format.
Compare this to a microservice-based design. Whenever we are trying to consume a new service, we need to build our own objects using their API documentation, making sure the field types and names match up exactly. Then, we need to convert our data into this new object. Next, we need to convert this object into JSON using some converter. Finally, we would perform this entire process again in reverse when accepting responses from the API. This whole process causes two major problems: poor performance and slow development.
Comparison
Considering the problems with the status quo, JSON-backed REST over HTTP/1.1, I’ll be comparing it to a solution that I argue is much better suited for the microservice paradigm we find ourselves in today: gRPC. To compare there effectiveness, I have three major constraints:
- Language-neutral: we want the flexibility to use the best technologies for the job
- Easy to use: development speed is essential
- Fast: every extra millisecond ends up losing customers and costing thousands of dollars in the long run
