INTL JOURNAL OF ELECTRONICS AND TELECOMMUNICATIONS, 2024, VOL. 70, NO. 2, PP.

429–436
Manuscript received November 8, 2023; revised June, 2024. doi: 10.24425/ijet.2024.149562

Performance evaluation of microservices

communication with REST, GraphQL, and gRPC
Muhammad Niswar, Reza Arisandy Safruddin, Anugrayani Bustamin, and Iqra Aswad

Abstract—Microservice architecture has become the design In addition to REST and GraphQL, another data exchange
paradigm for creating scalable and maintainable software sys- method gaining attention today is Google Remote Procedure
tems. Selecting the proper communication protocol in microser- Call (gRPC). gRPC offers an efficient and versatile approach
vices is critical to achieving optimal system performance. This
study compares the performance of three commonly used API to communication among distributed services. Unlike the
protocols: REST, GraphQL, and gRPC, in microservices ar- REST and GraphQL methods that utilize the HTTP/1 protocol,
chitecture. In this study, we established three microservices gRPC employs the HTTP/2 protocol and supports streaming
implemented in three containers and each microservice contained data. gRPC simplifies remote procedure calls across various
a Redis and MySQL database. We evaluated the performance of programming languages, delivering enhanced performance and
these API protocols using two key performance metrics: response
time and CPU Utilization. This study performs two distinct speed in microservice communication [4].
data retrieval: fetching flat data and fetching nested data, with In this study, we aim to evaluate and compare the per-
a number of requests ranging from 100 to 500 requests. The formance of REST, gRPC, and GraphQL for data exchange
experimental results indicate that gRPC has a faster response within a microservice system under both fetching flat data
time, followed by REST and GraphQL. Moreover, GraphQL and nested data. Our study includes a performance analysis
shows higher CPU Utilization compared to gRPC and REST. The
experimental results provide insight for developers and architects with key performance metrics, including response time and
seeking to optimize their microservices communication protocols CPU utilization. By evaluating these three communication
for specific use cases and workloads. protocols, we aim to assist developers and organizations in
Keywords—Microservices; API; gRPC; REST; GraphQL making informed decisions when designing and implementing
microservices-based systems.
I. I NTRODUCTION
OFTWARE development using microservices architec- II. R ELATED W ORK
S ture has changed the way we design applications. This
architecture advocates breaking down complex applications
There have been many studies that compare the performance
of REST and GraphQL. Reference [5] describes the perfor-
into smaller, self-contained microservices. Each microservice mance of the REST and GraphQL in using the Ocelot and Hot
has specific tasks and that can be managed and changed Chocolate Application Programming Interface (API) gateways
without affecting other components. It allows development in the case of writing data and getting data. Reference [6]
teams to focus on specific aspects of the application, improving discusses the advantages and disadvantages of the REST and
scalability, faster changes, and better fault isolation [1]. GraphQL. When dealing with data that undergoes frequent
In microservice communication, two commonly used pro- changes and needs to be handled efficiently with resource opti-
tocols are Representational State Transfer (REST) and Graph mization in mind, GraphQL is the preferred choice. Reference
Query Language (GraphQL). REST has been one of the most [7] describes the REST as the appropriate selection for the
widely used data exchange methods, which relies on a number data exchange method in situations where data is consistently
of endpoints to access and manipulate data. Although REST accessed. Reference [8] [9] focuses on implementing GraphQL
remains popular, it comes with certain drawbacks, such as in a web application, which shifts from REST to GraphQL.
over-fetching or under-fetching data, where the retrieved data Reference [10] [11] compares REST and GraphQL for API
may exceed or fall short of actual needs. Addressing these web design, focusing on response times and data sizes. Two
drawbacks, GraphQL emerges as an attractive alternative. NodeJS apps performed CRUD (Create, Read, Update, Delete)
GraphQL allows clients to specify the data they needed operations on MongoDB. There are no major differences for
[2] [3], overcoming REST’s inefficiency problem and giving a few queries or resource removal. GraphQL outperformed
application developers more control. REST when displaying data under heavy loads and for small
data portions, while REST performed better for large data por-
Muhammad Niswar, Reza Arisandy Safruddin, Anugrayani Bustamin, tions. Reference [12] compared the performance of REST and
Iqra Aswad are with Department of Informatics, Faculty of Engineer- GraphQL architectural models in three different applications
ing, Hasanuddin University, Gowa, South Sulawesi, Indonesia (e-mail:
[email protected], [email protected], [email protected], based on two metrics, i.e., response time and data transfer
[email protected].) rate. It found that GraphQL improved performance in most

© The Author(s). This is an open-access article distributed under the terms of the Creative Commons Attribution License (CC BY 4.0,
https://creativecommons.org/licenses/by/4.0/), which permits use, distribution, and reproduction in any medium, provided that the Article is properly cited.
430 MUHAMMAD NISWAR, ET AL.

cases, except for workloads above 3,000 requests, where REST A. Representational State Transfer (REST)
performed better. For smaller workloads (100 requests), both REST is an API development architecture that provides
REST and GraphQL showed similar performance. Reference client-server-based communication over the HTTP protocol.
[13] compares REST and GraphQL for data communication in REST was first introduced by Roy Fielding in 2000 as his
web applications. An experiment was conducted to assess the doctoral dissertation at the University of California [21]. REST
performance of both approaches when requesting nested ob- uses the HTTP/1.1 protocol to send data from clients to
jects. The results indicate that GraphQL outperformed REST servers. In systems that use REST, each service usually has a
in most scenarios. Reference [14] assesses these benefits in certain endpoint so that it can interact between services and
practice by migrating seven systems from standard REST- exchange data. In REST, there are several methods that can be
based APIs to GraphQL. The key finding is that GraphQL used, including GET, POST, PUT, and DELETE. The REST
can significantly reduce the size of JavaScript Object Notation supports several formats for presenting data, such as JSON and
(JSON) documents returned by REST APIs, with a reduction XML. JSON is used more often because of its simplicity and
of 94%. efficiency. Figure 1 shows the REST communication model.
In addition to studies on the performance of REST and
GraphQL, there are several studies that discuss the perfor-
mance of gRPC. Reference [15] explains microservices and
gRPC, covering their workings, implementations, limitations,
and applications. It relies on reliable online sources to demon-
strate a microservice with gRPC servers. Reference [16]
explores microservices architecture and its communication
methods, primarily REST API and gRPC. It evaluates the
pros and cons of both approaches and conducts a compar-
ative analysis. It presents a decision-making framework for
organizations to determine if adopting gRPC offers substantial
benefits over REST for their architecture. Reference [17]
explores the potential of gRPC for improving content delivery. Fig. 1. REST Model
The study aims to evaluate gRPC using the Goal Question
Metric (GQM) methodology. The findings indicate that gRPC
performs exceptionally well in scenarios involving mobile B. Graph Query Language (GraphQL)
or IoT applications as clients. Reference [18] discusses load
GraphQL, a query language for APIs, was created by
balancing challenges in gRPC microservices within Kuber-
Facebook and used in communication between clients and
netes using Golang. Reference [19] proposes a solution for
servers [22]. The client requests data as needed with a query
building gRPC services using NodeJS as independent modules
so the server can return a response according to the query
or components. Reference [20] focuses on analyzing emerging
request from the client. GraphQL offers an alternative solution
technologies for cross-process communication between Linux
to REST and allows developers to request specific data in
and Android-based platforms using the gRPC framework.
a more efficient and flexible format. The background of the
The study involves developing applications in various object-
development of GraphQL was to meet Facebook’s needs in
oriented programming languages to perform remote procedure
handling complex data and to overcome the problems in the
calls between a single-board computer and a smartphone. The
REST, such as over-fetching or under-fetching data. One of the
performance of computational offloading for algorithms in
main advantages of GraphQL is its flexibility. With GraphQL,
each platform is evaluated through data analysis.
clients can request multiple data sources in a single request,
Our study focuses on the performance comparison of REST,
reducing the requests needed to retrieve the desired data. In
GraphQL, and gRPC in microservice environments to pro-
addition, clients can validate their query requests by using
vide valuable insights into their respective advantages and
clearly defined types before sending them to the server. Figure
drawbacks. We aim to reveal which communication protocols
2 shows the GraphQL communication model.
operate efficiently across various scenarios and workloads.

C. Google Remote Procedure Call (gRPC)

III. A PPLICATION P ROGRAMMING I NTERFACE (A PI )
gRPC [23] is an open-source, high-performance framework
P ROTOCOLS
for building efficient, distributed systems and microservices.
API protocols are sets of rules, conventions, and standards It was developed by Google and designed to enable commu-
that facilitate communication and interaction between diverse nication between applications and services in a way that is
software programs and systems. These protocols define the both language-agnostic and platform-independent. The gRPC
structure and format of requests and responses, as well as allows applications to define their service methods and data
the methods and rules for communication. The API acts as structures using Protocol Buffers (protobufs), a language-
a bridge that allows developers to integrate functionality. The neutral interface definition language. Based on these defini-
most commonly used API protocols are REST, GraphQL, and tions, it generates client and server code in multiple program-
gRPC. ming languages. Clients and servers can then communicate
PERFORMANCE EVALUATION OF MICROSERVICES COMMUNICATION WITH REST, GRAPHQL, AND GRPC 431

an in-memory database, Redis excels in read-heavy operations

and is ideal for our use cases demanding low-latency data
access. Initially, we imported the SISTER data, available at
http://sister.unhas.ac.id/ws.php/1.0 into the MySQL database.
This imported data includes lecturer profile data totaling 2,221
entries and lecturer profiles with educational backgrounds,
which amounts to 6,197 entries. Subsequently, Redis exported
the SISTER data from the MySQL database. The service
fetches data from Redis rather than directly from the MySQL
database in the data retrieval process. In cases where Redis
lacks the required data, the service retrieves it from the
Fig. 2. GraphQL Model MySQL database and caches it within Redis. During testing,
data retrieval occurs from Redis. Figure 5 illustrates the data
fetching process within the services.
using HTTP/2, benefiting from features like bidirectional Figure 6 shows that JSON represents flat data. It includes
streaming, multiplexing, and efficient serialization. It is a high- a single object within an array, with several key-value pairs.
performance framework for building efficient and language- Figure 7 shows that JSON represents nested data within the
agnostic distributed systems, microservices, and APIs. Figure ”pendidikan formal” array to represent the lecturer’s educa-
3 shows the gRPC communication model. tional backgrounds. The data in Figures 6 and 7 are dummy
data, used to avoid exposing sensitive information.

V. P ERFORMANCE E VALUATION AND R ESULT

Performance evaluation has been conducted to assess the
impact of data fetching load on response time and CPU perfor-
mance. This evaluation aims to evaluate the data exchange with
Fig. 3. gRPC Model REST, gRPC, and GraphQL to determine the most suitable
approach for both flat data and nested data cases. We used
Apache JMeter for API load testing. The Apache JMeter
IV. S YSTEM D ESIGN application is open source software designed to conduct load
In this study, we have developed microservices using test on functional capabilities and assess performance [24].
Golang, with the case study of the Integrated Education
Information System in the Ministry of Education and Culture A. Concurrent Requests Evaluation
Indonesia, known as SISTER. It is designed to manage and In concurrent requests evaluation, multiple clients initiate
monitor resources in the education sector, including data re- requests concurrently, ranging from 100 to 500 requests, to
lated to academic institutions, research, and human resources. assess response times and CPU utilization under these simul-
This system aims to improve the efficiency and effectiveness taneous load conditions. This approach allows us to gauge
of educational management and administration. how the system performs when subjected to varying levels of
Our study utilizes Hasanuddin University’s SISTER data, concurrent user activity. Response time measurements were
specifically lecturer data and the lecturer’s educational back- conducted for both the fetching flat data and nested data. Each
ground. This research aims to assess the performance of evaluation was carried out over ten iterations. The average
REST, gRPC, and GraphQL. Our proposed service architecture response time (aveRT ) can be calculated using equation (1) :
consists of three services implemented in three containers,
including authentication services, fetching lecturer profiles ser- n
1X
vice (flat data), and fetching lecturer profile with educational aveRT = (trespi − treqi ) (1)
n i=1
background service (nested data). Each service contained a
Redis and MySQL database. Figure 4 shows the architecture In equation (1), n represents the total number of requests,
of our system. treqi is the request time of the i-th request, and trespi is the
The evaluation comprises two distinct data retrieval, i.e., the response time of the i-th request. The equation calculates
fetching flat data and nested data. Fetching flat data refers the average time interval required for the client to receive a
to JSON structures where all the data is organized at the response from the sent request.
same level, typically using simple key-value pairs. On the Figure 8 shows the average response time for fetching flat
other hand, fetching nested data refers to JSON structures data. For REST, the average response times increase as the
where data is organized hierarchically, with one or more items number of requests increases, ranging from 1,113.33 ms for
containing other items as properties or elements. 100 requests to 4,009.83 ms for 500 requests. gRPC offers
This study utilizes Redis and MySQL as Database Man- significantly lower response times, with averages ranging from
agement Systems, with MySQL as the long-term storage 233.84 ms for 100 requests to 2,606.59 ms for 500 requests.
solution and Redis as the in-memory storage system. Being On the other hand, GraphQL shows the highest response times,
432 MUHAMMAD NISWAR, ET AL.

Fig. 4. System Architecture

Fig. 5. Data Fetching Process

Fig. 7. JSON for Fetching Nested Data

lags with substantially slowest response times, particularly as

Fig. 6. JSON for Fetching Flat Data the request volume increases.
Figure 9 shows the average response time for fetching
nested data. For REST, as the number of requests increased
with averages increasing from 3,852.07 ms for 100 requests to from 100 to 500, the average response times grew from
21,148.14 ms for 500 requests. In summary, gRPC provides 5,201.39 ms to 16,646.55 ms. In the case of gRPC, the
the fastest response times, followed by REST, while GraphQL response times also increased with more requests, ranging
PERFORMANCE EVALUATION OF MICROSERVICES COMMUNICATION WITH REST, GRAPHQL, AND GRPC 433

Fig. 8. Average response time for Fetching Flat Data

Fig. 11. Average CPU Utilization for Fetching Nested Data

Figure 10 shows the average CPU utilization for fetching flat

data. For REST requests, as the number of requests increased
from 100 to 500, CPU utilization gradually increased from
10.26% to 48.90%. With gRPC requests, CPU utilization also
increased with the number of requests, going from 10.95% to
36.11%. However, for GraphQL requests, CPU utilization ex-
hibited a different trend, starting remarkably high at 120.09%
for 100 requests and gradually increasing to 142.15% for 500
requests. These figures highlight the varying CPU resource
demands of different data request protocols. GraphQL was no-
tably more resource-intensive than REST and gRPC, showing
Fig. 9. Average response time for Fetching Nested Data
increased linear CPU utilization with increasing request loads.
Figure 11 shows the average CPU utilization for fetching
nested data. For REST, CPU utilization increased from 38.23%
from 5,667.33 ms to 14,962.61 ms. GraphQL showed the
at 100 requests to 123.01% at 500 requests. gRPC had lower
highest response times, averaging 8,510.84 ms to 29,734.59
CPU utilization, starting at 30.11% and reaching 84.04%
ms as the number of requests increased. Overall, REST had
at 500 requests. In contrast, GraphQL showed significantly
the lowest response times, followed by gRPC, while GraphQL
higher CPU utilization, exceeding 100% even at 100 requests
exhibited the slowest response times, particularly with a larger
and peaking at 177.41% at 500 requests. This indicates that the
number of requests.
workload is being distributed across at least two CPU cores,
We also measured CPU utilization to assess the impact of
suggesting higher processing demands for GraphQL queries
data fetching load on CPU performance. We aim to gauge
than REST and gRPC as the request load increased.
how the act of fetching data, whether it involves retrieving
flat or nested data, influences the CPU utilization. We examine
CPU performance across a range of scenarios, each involving B. Consecutive Requests Evaluation
a varying number of data retrieval requests, spanning from 100 In the consecutive request evaluation, clients initiate re-
to 500 requests. quests consecutively for five minutes with a varying number
of requests, from 100 to 500 requests, to measure response
time and CPU utilization during the test.

Fig. 12. Response time during five minutes for Fetching Flat
Data (100 requests)
Fig. 10. Average CPU Utilization for Fetching Flat Data
434 MUHAMMAD NISWAR, ET AL.

Fig. 13. Response time during five minutes for Fetching Flat Fig. 16. Response time during five minutes for Fetching Nested
Data (300 requests) Data (300 requests)

Fig. 14. Response time during five minutes for Fetching Flat Fig. 17. Response time during five minutes for Fetching Nested
Data (500 requests) Data (500 requests)

Figures 12, 13, and 14 show that the response time of gRPC (Figure 15), gRPC performed the fastest, with an average
is faster than REST and GraphQL during five minutes mea- response time of 437.03 ms, followed by REST at 510.47
surements for fetching flat data. For 100 requests (Figure 12), ms and GraphQL at 589.25 ms. When the number of requests
gRPC performed the fastest, with an average response time increased to 300 (Figure 16), gRPC remained the fastest with
of 79.90 ms, followed by REST at 152.56 ms and GraphQL 337.34 ms, while REST and GraphQL showed slight increases
at 196.90 ms. When the number of requests increased to 300 in response times with an average of 517.08 ms and 565.59 ms,
(Figure 13), gRPC remained the fastest with 66.42 ms, while respectively. However, when the number of requests further
REST and GraphQL showed slight increases in response times increased to 500 (Figure 17), GraphQL had the highest average
with an average of 154.45 ms and 205.04 ms, respectively. response time at 1,035.46 ms, while gRPC and REST had
However, when the number of requests further increased to response times of 748.22 ms and 798.41 ms, respectively, with
500 (Figure 14), GraphQL had the highest average response gRPC being the fastest.
time at 204.35 ms, while gRPC and REST had response times We also measured the CPU utilization for five minutes for
of 67.75 ms and 149.68 ms, respectively, with gRPC being each data fetching scenario with a different number of requests
the fastest. (100, 300, and 500 Requests).

Fig. 15. Response time during five minutes for Fetching Nested Fig. 18. CPU Utilization during five minutes for Fetching Flat
Data (100 requests) Data (100 requests)

Figures 15, 16, and 17 show that the response time of Figures 18, 19, and 20 show the CPU utilization of three
gRPC is faster than REST and GraphQL during five minutes API protocols during five minutes measurement for fetching
measurements for fetching nested data. For 100 requests flat data. With 100 requests (Figure 18), REST had the lowest
PERFORMANCE EVALUATION OF MICROSERVICES COMMUNICATION WITH REST, GRAPHQL, AND GRPC 435

Fig. 19. CPU Utilization during five minutes for Fetching Flat Fig. 22. CPU Utilization during five minutes for Fetching
Data (300 requests) Nested Data (300 requests)

Fig. 20. CPU Utilization during five minutes for Fetching Flat Fig. 23. CPU Utilization during five minutes for Fetching
Data (500 requests) Nested Data (500 requests)

CPU utilization with an average of 3.87%, gRPC was slightly the highest, averaging 37.53%. As the request load increased
higher with an average of 4.09%, and GraphQL had the highest to 300 (Figure 22) and 500 (Figure 23) requests, the CPU
utilization, averaging 17.63%. As the request count increased utilization also increased across all three protocols. REST
to 300 (Figure 19), REST’s CPU utilization increased with an maintained the lowest utilization, gRPC in the middle, and
average of 4.13%, gRPC decreased with an average of 3.70%, GraphQL consistently had the highest CPU utilization with
and GraphQL spiked with an average of 21.62%. At 500 an average of 90.30% for 500 requests.
requests (Figure 20), REST’s CPU utilization increased with The performance evaluation shows that gRPC outperformed
an average of 6.95%, gRPC with an average of 5.98%, and REST and GraphQL in terms of response time, while REST
GraphQL had the highest CPU utilization, averaging 33.53%. demonstrated lower CPU utilization compared to the others.
These results suggest that GraphQL places a heavier load on gRPC’s superior performance can be largely attributed to
the CPU as the number of requests grows compared to REST its use of the HTTP/2 protocol, which offers several ad-
and gRPC. vantages over the HTTP/1 protocol utilized by both REST
and GraphQL. HTTP/2 enables more efficient data exchange
through features like multiplexing and reduced latency, mak-
ing it a key factor in gRPC’s enhanced performance when
compared to its counterparts.

VI. C ONCLUSION
Microservice architecture is now the prevailing framework
for developing software systems that are both scalable and
easy to maintain. The selection of the proper communication
protocol within microservices is essential for attaining the
best possible system performance. This research evaluates the
Fig. 21. CPU Utilization during five minutes for Fetching performance of API protocols: REST, gRPC, and GraphQL
Nested Data (100 requests) in a microservices-based system using Redis and MySQL
as databases. Two distinct data retrieval were examined:
Figures 21, 22, and 23 show the CPU utilization of three fetching flat data and nested data. Based on the evaluation
API protocols during five minutes measurement for fetching of response time and CPU utilization for fetching flat and
nested data. For 100 requests (Figure 21), REST had the nested data scenarios, gRPC had the fastest response time,
lowest CPU utilization with an average of 10.51%, followed while REST showed the lowest CPU utilization compared
by gRPC with an average of 20.84%, and GraphQL had to gRPC and GraphQL. gRPC’s use of HTTP/2, with its
436 MUHAMMAD NISWAR, ET AL.

multiplexing feature, allows multiple requests over a single [10] P. Margański and B. Pańczyk, “Rest and graphql comparative analysis,”
connection, making it highly efficient for concurrent remote Journal of Computer Sciences Institute, vol. 19, pp. 89–94, 2021.
[Online]. Available: https://doi.org/10.35784/jcsi.2473
procedure calls. These findings provide insights for choosing [11] M. Mikuła and M. Dzieńkowski, “Comparison of rest and graphql
API protocols in microservices environment. web technology performance,” Journal of Computer Sciences Institute,
vol. 16, pp. 309–316, 2020. [Online]. Available: https://doi.org/10.
35784/jcsi.2077
R EFERENCES [12] M. Seabra, M. F. Nazário, and G. Pinto, “Rest or graphql? a performance
comparative study,” in Proceedings of the XIII Brazilian Symposium on
[1] I. Karabey Aksakalli, T. Çelik, A. B. Can, and B. Tekinerdoğan,
Software Components, Architectures, and Reuse, 2019, pp. 123–132.
“Deployment and communication patterns in microservice architectures:
[Online]. Available: https://doi.org/10.1145/3357141.3357149
A systematic literature review,” Journal of Systems and Software, vol.
[13] M. D. C. França and E. da Silva, “Performance evaluation of rest
180, p. 111014, 2021. [Online]. Available: https://www.sciencedirect.
and graphql apis searching nested objects,” Anais do Computer on
com/science/article/pii/S0164121221001114
the Beach, vol. 11, no. 1, pp. 237–244, 2020. [Online]. Available:
[2] G. S. M. Diyasa, G. S. Budiwitjaksono, H. A. Ma’rufi, and
https://doi.org/10.14210/cotb.v11n1.p237-244
I. A. W. Sampurno, “Comparative analysis of rest and graphql
[14] G. Brito, T. Mombach, and M. T. Valente, “Migrating to graphql:
technology on nodejs-based api development,” Nusantara Science and
A practical assessment,” in 2019 IEEE 26th International Conference
Technology Proceedings, pp. 43–52, Apr. 2021. [Online]. Available:
on Software Analysis, Evolution and Reengineering (SANER). IEEE,
https://nstproceeding.com/index.php/nuscientech/article/view/322
2019, pp. 140–150. [Online]. Available: https://doi.org/10.1109/SANER.
[3] M. Vesić and N. Kojić, “Comparative analysis of web application
2019.8667986
performance in case of using rest versus graphql,” in Proceedings
[15] H. Vo, “Applying microservice architecture with modern grpc api to
of the Fourth International Scientific Conference on Recent Advances
scale up large and complex application,” 2021. [Online]. Available:
in Information Technology, Tourism, Economics, Management and
https://urn.fi/URN:NBN:fi:amk-2021060314024
Agriculture (ITEMA), Online-Virtual, 2020, pp. 17–24. [Online].
[16] M. Stefanic, “Developing the guidelines for migration from restful
Available: https://doi.org/10.31410/ITEMA.2020.17
microservices to grpc,” Masaryk University, Faculty of Informatics,
[4] Y. Lee and Y. Liu, “Using refactoring to migrate rest applications
Brno, pp. 1–81, 2021. [Online]. Available: https://is.muni.cz/th/ozxws/
to grpc,” in Proceedings of the 2022 ACM Southeast Conference, [17] B. P. Rebrošová, “grpc layer for content delivery in kentico kontent,”
ser. ACMSE ’22. New York, NY, USA: Association for Computing Master’s thesis, Masaryk University, 2021. [Online]. Available:
Machinery, 2022, p. 219–223. [Online]. Available: https://doi.org/10. https://is.muni.cz/th/d1f9l/Masters Thesis.pdf
1145/3476883.3520220 [18] K. Nieman and S. Sajal, “A comparative analysis on load balancing and
[5] N. Vohra and I. B. K. Manuaba, “Implementation of rest api vs graphql grpc microservices in kubernetes,” in 2023 Intermountain Engineering,
in microservice architecture,” in 2022 International Conference on Technology and Computing (IETC). IEEE, 2023, pp. 322–327.
Information Management and Technology (ICIMTech). IEEE, 2022, [Online]. Available: https://doi.org/10.1109/IETC57902.2023.10152023
pp. 45–50. [Online]. Available: https://doi.org/10.1109/ICIMTech55957. [19] M. Vasiljević, A. Manasijević, A. Kupusinac, Ć. Sukić, and
2022.9915098 D. Ivetić, “One solution of component based development in nodejs for
[6] S. L. Vadlamani, B. Emdon, J. Arts, and O. Baysal, “Can graphql modularization of grpc services and rapid prototyping,” SAR J, vol. 2, pp.
replace rest? a study of their efficiency and viability,” in 2021 181–185, 2019. [Online]. Available: https://doi.org/10.18421/SAR24-06
IEEE/ACM 8th International Workshop on Software Engineering [20] M. Araújo, M. E. Maia, P. A. Rego, and J. N. De Souza, “Performance
Research and Industrial Practice (SER&IP). IEEE, 2021, pp. 10–17. analysis of computational offloading on embedded platforms using the
[Online]. Available: https://doi.org/10.1109/SER-IP52554.2021.00009 grpc framework,” in 8th International Workshop on ADVANCEs in
[7] A. Lawi, B. L. Panggabean, and T. Yoshida, “Evaluating graphql and ICT Infrastructures and Services (ADVANCE 2020), 2020, pp. 1–8.
rest api services performance in a massive and intensive accessible [Online]. Available: https://hal.science/hal-02495252
information system,” Computers, vol. 10, no. 11, p. 138, 2021. [Online]. [21] R. T. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, and T. Berners-
Available: https://doi.org/10.3390/computers10110138 Lee, “Architectural styles and the design of network-based software
[8] B. Lama, “Implementing graphql in existing rest api,” B.S. thesis, architectures,” Ph.D. dissertation, UC Irvine, 2000. [Online]. Available:
Universitat Politècnica de Catalunya, 2019. https://ics.uci.edu/∼fielding/pubs/dissertation/top.htm
[9] M. Vogel, S. Weber, and C. Zirpins, “Experiences on migrating [22] The GraphQL Foundation. (2015) ”graphql”,. Accessed: September 26,
restful web services to graphql,” in Service-Oriented Computing– 2023. [Online]. Available: https://graphql.org/
ICSOC 2017 Workshops: ASOCA, ISyCC, WESOACS, and Satellite [23] Louis Ryan (Google). (2015) ”grpc”,. Accessed: September 16, 2023.
Events, Málaga, Spain, November 13–16, 2017, Revised Selected [Online]. Available: https://grpc.io
Papers. Springer, 2018, pp. 283–295. [Online]. Available: https: [24] The Apache Software Foundation. (n.d) ”apache jmeter”,. Accessed:
//doi.org/10.1007/978-3-319-91764-1 23 October 23, 2022. [Online]. Available: https://jmeter.apache.org/