- 6030053921 Keerati Chuatanapinyo
- 6030559121 Siwat Pongpanit
- 6030631621 Anawat Trongwattananon
- 6031022621 Thanapun Yan-amporn
- 6031055321 Weerayut Thinchamlong
- 6031059921 Setthanan Nakaphan
Scenario a. Single client with a small call to insert a book item, a bigger call to insert a list of multiple book items.
In this scenario we just loop through the insert service using exec of child process.
Scenario b. Multiple clients with different kind of calls.
Both applying the child process to send request and have two clients.
Scenario c. Vary the number of concurrent calls from 1 to 4096 calls. Both using Class to generate multiple client objects to call concurrent calls.
In scenario a, a performance of gRPC inserting a book is quite close to a performance of REST API. We notice that ina scenario c gRPC performs far better than REST API. Of course, gRPC would be better than REST API since gRPC uses http/2 while REST API uses http/1. However, there is something weird about scenario b. I think it is because of the interface of gRPC client to access the server makes its performance more terrible than REST API.
Comparison of the gRPC and REST API from the aspects of language neutral, ease of use, and performance.
Language Neutral: Since REST API has been renowed and dominated in software development industry, developer usually familiar with the syntax of REST API more than gRPC.
Ease of Use: REST API's payload format is JSON which is more readable than proctobuf. Additionally, client need no setup to sent a request to a server just call a web server address.
Performance: From the benchmarking experiment, overall, gRPC is faster than REST API.
Does your results comply with the results in this Medium article? How?
Not really since in scenario b result does not comply with a benchmark result in that article.