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, Iqra Aswad

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

© 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.

[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 JSON documents returned supports several formats for presenting data, such as JSON
by REST APIs, with a reduction of 94%. and XML. JSON is used more often because of its simplicity
In addition to studies on the performance of REST and and efficiency. Fig. 1 shows the REST communication model.
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] delves
into microservices architecture and its communication meth-
ods, primarily REST API and gRPC. It evaluates the pros and
cons of both approaches and conducts a comparative 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 in
Kentico Kontent, a widely used Content Management System.
The study aims to evaluate gRPC using the Goal Question Fig. 1. REST Model
Metric (GQM) methodology. The findings indicate that gRPC
performs exceptionally well in scenarios involving mobile or
IoT applications as clients. Reference [18] discusses load bal- B. GraphQL
ancing challenges in gRPC microservices within Kubernetes
GraphQL, a query language for APIs, was created by
using Go. Reference [19] proposes a solution for building
Facebook and used in communication between clients and
gRPC services using NodeJS as independent modules or
servers [22]. The client requests data as needed with a query
components. Reference [20] focuses on analyzing emerging
so the server can return a response according to the query
technologies for cross-process communication between Linux
request from the client. GraphQL offers an alternative solution
and Android-based platforms using the gRPC framework.
to REST and allows developers to request specific data in
The study involves developing applications in various object-
a more efficient and flexible format. The background of the
oriented programming languages to perform remote procedure
development of GraphQl was to meet Facebook’s needs in
calls between a single-board computer and a smartphone. The
handling complex data and to overcome the problems in the
performance of computational offloading for algorithms in
REST, such as over-fetching or under-fetching data. One of the
each platform is evaluated through data analysis. Our study
main advantages of GraphQL is its flexibility. With GraphQL,
focuses on the performance comparison of REST, GraphQL,
clients can request multiple data sources in a single request,
and gRPC in microservice environments to provide valuable
reducing the requests needed to retrieve the desired data. In
insights into their respective advantages and drawbacks. We
addition, clients can validate their query requests by using
aim to reveal which communication protocols operate effi-
clearly defined types before sending them to the server. Fig.
ciently across various scenarios and workloads.
2 shows the GraphQL communication model.
III. A PI P ROTOCOLS
Application Programming Interface (API) protocols are sets
of rules, conventions, and standards that facilitate commu-
nication and interaction between diverse software programs
and systems. These protocols define the structure and format
of requests and responses, as well as the methods and rules
for communication. The API acts as a bridge that allows
developers to integrate functionality. The most commonly used
API protocols are REST, GraphQL, and gRPC.

A. Representational State Transfer (REST)

REST is an API development architecture that provides Fig. 2. GraphQL Model
client-server-based communication over the HTTP protocol.
PERFORMANCE EVALUATION OF MICROSERVICES COMMUNICATION WITH REST, GRAPHQL, AND GRPC 431

C. gRPC in-memory database, Redis excels in read-heavy operations

Google Remote Procedure Call (gRPC) [23] is an open- and is ideal for our use cases demanding low-latency data
source, high-performance framework for building efficient, access. Initially, we imported the SISTER data, available at
distributed systems and microservices. It was developed by http://sister.unhas.ac.id/ws.php/1.0 into the MySQL database.
Google and designed to enable communication between appli- This imported data includes lecturer profile data totaling 2,221
cations and services in a way that is both language-agnostic entries and lecturer profiles with educational backgrounds,
and platform-independent. The gRPC allows applications to which amounts to 6,197 entries. Subsequently, Redis exported
define their service methods and data structures using Protocol the SISTER data from the MySQL database. The service
Buffers (protobufs), a language-neutral interface definition fetches data from Redis rather than directly from the MySQL
language. Based on these definitions, it generates client and database in the data retrieval process. In cases where Redis
server code in multiple programming languages. Clients and lacks the required data, the service retrieves it from the
servers can then communicate using HTTP/2, benefiting from MySQL database and caches it within Redis. During testing,
features like bidirectional streaming, multiplexing, and effi- data retrieval occurs from Redis. Fig. 5 illustrates the data
cient serialization. It is a high-performance framework for fetching process within the services.
building efficient and language-agnostic distributed systems, Fig. 6 shows that JSON represents flat data. It includes a
microservices, and APIs. Fig. 3 shows the gRPC communica- single object within an array, with several key-value pairs. Fig.
tion model. 7 shows that JSON represents nested data within the ”pen-
didikanformal” array to represent the lecturer’s educational
backgrounds.

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

Fig. 4. System Architecture

Fig. 5. Data Fetching Process

Fig. 7. JSON for Fetching Nested Data

lags with substantially higher response times, particularly as

the request volume increases.
Fig. 6. JSON for Fetching Flat Data
Fig. 9 shows the average response time for fetching nested
data. For REST, as the number of requests increased from 100
to 500, the average response times grew from 5,201.39 ms to
21,148.14 ms for 500 requests. In summary, gRPC provides 16,646.55 ms. In the case of gRPC, the response times also
the fastest response times, followed by REST, while GraphQL increased with more requests, ranging from 5,667.33 ms to
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

Fig. 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-
Fig. 9. Average response time for Fetching Nested Data tably more resource-intensive than REST and gRPC, showing
increased linear CPU utilization with increasing request loads.
Fig. 11 shows the average CPU utilization for fetching
14,962.61 ms. GraphQL showed the highest response times, nested data. For REST, CPU utilization increased from 38.23%
averaging 8510.84 ms to 29,734.59 ms as the number of at 100 requests to 123.01% at 500 requests. gRPC had lower
requests increased. Overall, REST had the lowest response CPU utilization, starting at 30.11% and reaching 84.04%
times, followed by gRPC, while GraphQL exhibited the at 500 requests. In contrast, GraphQL showed significantly
slowest response times, particularly with a larger number of higher CPU utilization, exceeding 100% even at 100 requests
requests. and peaking at 177.41% at 500 requests, suggesting higher
We also measured CPU utilization to assess the impact of processing demands for GraphQL queries than REST and
data fetching load on CPU performance. We aim to gauge 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-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)

Fig. 12, 13, and 14 show that the response time of gRPC is ms. When the number of requests increased to 300, gRPC re-
faster than REST and GraphQL during five minute measure- mained the fastest with 337.34 ms, while REST and GraphQL
ments for fetching flat data. For 100 requests, gRPC has an showed slight increases in response times. However, when the
average response time of 79.9 ms, while REST and GraphQL number of requests further increased to 500, GraphQL had the
have higher averages of 152.56 ms and 196.9 ms, respectively. highest average response time at 1,035.46 ms, while gRPC
As the number of requests increases to 300 and 500, gRPC and REST had response times of 748.22 ms and 798.41 ms,
maintains its speed advantage with average response times of respectively, with gRPC being the fastest. We also measured
66.42 ms and 67.75 ms, compared to REST’s averages of the CPU utilization for five minutes for each data fetching
154.45 ms and 149.68 ms and GraphQL’s averages of 205.04 scenario with a different number of requests (100, 300, and
ms and 204.35 ms, demonstrating its efficiency in handling 500 Requests).
data retrieval operations.

Fig. 18. CPU Utilization during five minutes for Fetching Flat
Fig. 15. Response time during five minutes for Fetching Nested Data (100 requests)
Data (100 requests)
Fig. 18, 19, and 20 show the CPU utilization of three API
Fig. 15, 16, and 17 show that the response time of gRPC protocols during five minutes measurement for fetching flat
is faster than REST and GraphQL during five- minute mea- data. With 100 requests, REST had the lowest CPU utilization
surements for fetching nested data. For 100 requests, gRPC at 3.87%, gRPC was slightly higher at 4.09%, and GraphQL
performed the fastest, with an average response time of 437.03 had the highest utilization at 17.63%. As the request count
ms, followed by REST at 510.47 ms and GraphQL at 589.25 increased to 300, REST’s CPU utilization increased to 4.13%,
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)

gRPC decreased to 3.70%, and GraphQL spiked to 21.62%. The performance evaluation shows that gRPC outperformed
At 500 requests, REST’s CPU utilization increased to 6.95%, REST and GraphQL in terms of response time and CPU uti-
gRPC to 5.98%, and GraphQL had the highest CPU utilization lization. This superiority can be attributed to gRPC’s adoption
at 33.53%. These results suggest that GraphQL places a of the HTTP/2 protocol, a departure from REST and GraphQL,
heavier load on the CPU as the number of requests grows which rely on the HTTP/1 protocol. The efficient handling of
compared to REST and gRPC. data exchange provided by the HTTP/2 protocol is a signif-
icant factor contributing to gRPC’s enhanced performance in
comparison 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
performance of API protocols: REST, gRPC, and GraphQL
in a microservices-based system using Redis and MySQL as
databases. Two distinct data retrieval were examined: fetching
Fig. 21. CPU Utilization during five minutes for Fetching flat data and nested data. Based on the evaluation of response
Nested Data (100 requests) time and CPU utilization for fetching flat and nested data
scenarios, gRPC outperforms REST and GraphQL. This ad-
Fig. 21, 22, and 23 show the CPU utilization of three API vantage can be attributed to gRPC’s utilization of the HTTP/2
protocols during five minutes measurement for fetching nested protocol, which contrasts REST and GraphQL, relying on the
data. For 100 requests, REST had the lowest CPU utilization HTTP/1 protocol. The HTTP/2 protocol is the latest version of
at 3.87%, followed by gRPC at 4.09%, and GraphQL had the HTTP protocol designed for client-server communication.
the highest at 17.63%. As the request load increased to 300 One of its key features is multiplexing, which enables multiple
and 500 requests, the CPU utilization also increased across all requests and responses to be efficiently managed over a single
three protocols. REST maintained the lowest utilization, gRPC connection. This feature proves especially beneficial in gRPC,
in the middle, and GraphQL consistently had the highest CPU where numerous remote procedure call (RPC) requests can
utilization, peaking at 33.53% for 500 requests. be executed concurrently on a single gRPC channel. The
436 MUHAMMAD NISWAR, ET AL.

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