

This way I can focus only on the performance aspect of both gRPC and REST approaches during data transportation. To remove the effects of generating the LargeObjectResponse (proto object) and LargeObjectPOJO (java object), I call the "SetUp Thread Group" and let the servers generate the objects and cache them. To be able to focus directly on the performances of data transportation and serialization/deserialization, the benchmarking setup has the following constraints: To clearly see the effects of using Protocol Buffers, I created a really big object as Proto and Java object, named it LargeObject, LargeObjectPOJO and tested the APIs by fetching instances of this object at different sizes - as it can be set for each endpoint with the count parameter.

Using HTTP/1.1 with JSON is a text-based communication whereas using gRPC and protocol buffers we can make use of HTTP/2 and transport our data in binary format - which helps us increase performance and throughput.ĭisclaimer: These benchmarking tests ignore the throughput comparisons - for now - but focuses on the difference in the latency. So, I wanted to experiment with the implementation of such API, its interaction with other frameworks and, its performance compared to REST APIs using JMeter.Ĭompared to JSON (commonly used in REST APIs as the transfer object), Protocol Buffer offers a great performance improvement thanks to the way it represents the data during transportation. It is mainly because it is said to be more performant than REST and its drawbacks are somewhat negligible if we are planning to use it to design our internal APIs. This benchmarking compares the performances of "gRPC with Protocol Buffers" against "REST with JSON" during data transportation.Īs we are all witnessing the world moving towards the microservices architecture, gRPC's popularity is on the rise.
#Grpc vs rest code#
With the help of plugins, whenever the project is compiled and installed, it generates the required code (hence we call it codegen) under /targets/generated-sources folder. The sole purpose of this project is to generate the code based on the given Protobuff file to enable the Server ( sample-grpc-server) and the Client ( sample-client) to make Remote Procedure Calls (RPC) as if the methods they call are local methods.įor this project, there's a Sample.proto and a LargeObject.proto file located under /src/proto/. This project is the gist of the gRPC part of the main project. This project has sample-grpc-codegen as dependency in its pom.xml. grpc/randomNumbers?count= LargeObjects as Protocol Buffer Object
