Arabian Journal for Science and Engineering

https://doi.org/10.1007/s13369-024-09474-9

RESEARCH ARTICLE-COMPUTER ENGINEERING AND COMPUTER SCIENCE

Performance and Availability Analysis of API Design Techniques for API

Gateways
Fikri Aydemir1 · Fatih Başçiftçi2

Received: 16 August 2022 / Accepted: 6 August 2024

© King Fahd University of Petroleum & Minerals 2024

Abstract
API design refers to the process of developing Application Programming Interfaces (APIs) that expose the functionality of
software applications to their clients. This paper provides a performance and availability-related analysis of three modern API
design techniques, namely Representational State Transfer, Google’s Remote Procedure Call Framework, and Apache Thrift
to practically show which of these techniques should be used in the implementation of the API Gateways for performance and
availability considering that the gateways undertake a crucial role as they are the backbone of communication in Microservices
Architecture and the performance and availability are two critical factors that determine how well API gateways can perform.
For our analysis, an API Gateway prototype for each of the three API design techniques was developed by using Microsoft’s
.NET framework, and load-tests against each of these three prototypes were performed and analyzed. The results of this paper
are expected to be helpful for both researchers and practitioners in the software industry who need to choose from different
industrial API design techniques for API Gateway development.

Keywords API Gateway · API design technique · Microservices architecture · REST · gRPC · Apache Thrift

1 Introduction phase of migrating their legacy monolithic systems into mod-

ern MSA-based systems [4–7].
A traditional software system with monolithic architecture Inter-modular boundaries in almost every software system
encapsulates all complex functions into a single applica- are defined in terms of Application Programming Interfaces
tion. In such an application, the codebase can become (APIs). This is a necessary strategy, particularly for modular
overwhelmingly complex and incomprehensible over time. reusability in software [8]. This strategy is needed in MSA,
As a consequence, it becomes rather challenging to make too [9]. In MSA, each microservice provides an API encap-
bug fixes and feature additions in such an application [1]. sulating an atomic group of functions that represent a specific
Microservices Architecture (MSA) has emerged as a soft- internal implementation of the overall system. The clients of
ware engineering practice to overcome the problems that the system, such as mobile app clients, desktop clients, and
were encountered in traditional monolithic systems [2, 3]. server-side clients, can directly call these microservice APIs
Hence, there is an increasing shift today in large corporates, without any intermediary entity. Nevertheless, the granular-
such as Amazon, Airbnb, Netflix, and Uber, to the use of ity level of the APIs that are provided by microservices (i.e.,
MSA and many more firms are currently in the transition the number of functions they encapsulate) is generally differ-
ent from the granularity level that is expected by the clients
of those microservices. In other words, clients generally
B Fatih Başçiftçi expect more coarse-grained microservice APIs encapsulat-
basciftci@selcuk.edu.tr ing a larger set of system functions, whereas microservice
Fikri Aydemir APIs provide relatively finer-grained APIs. Hence, there is a
fikri.aydemir@kuveytturk.com.tr need in MSA for an intermediary component that aggregates
the APIs of the microservices to provide a coarser-grained
1 Information Technologies, R&D Center Kuveyt Turk
API between microservices and their clients [10–13].
Participation Bank, Konya, Turkey
2 Faculty of Technology, Department of Computer
Engineering, Selcuk University, Konya, Turkey

123
 Arabian Journal for Science and Engineering

such RPC-based API design techniques that may well be con-

sidered for the design and implementation of coarse-grained
APIs that are provided by API Gateways [3, 18, 19].
The contribution of this paper comes from its practical
aspect that shows which of the industrial API design tech-
niques, namely REST, gRPC, and Apache Thrift, should be
used in the implementation of the API Gateways considering
that the API gateways are the backbone of communication
between microservices and their clients. Performance and
availability are two critical factors in the analysis of how
well the gateways can perform in MSA. From this perspec-
tive, the question this paper tries to answer can be stated as
follows: “From a performance efficiency and availability per-
spective, which API design technique, namely REST, gRPC,
Fig. 1 API gateway: an API-oriented central control entity and Apache Thrift, brings better practical results in the imple-
mentation of API Gateways?” From this perspective, our
contribution in this paper is to draw conclusions that can be
practically used in the IT industry in selecting an API design
API Gateway, as a software component in MSA, comes technique for the implementation of API gateways. Here, our
into play at this point to meet this need. It provides a coarse- rationale behind selecting the API design techniques, namely
grained API to the clients of the microservices besides the REST, gRPC, and Apache Thrift, for our evaluation is that
other services it provides, such as login authentication, iden- they are the most commonly used API design techniques in
tity control, traffic control, load balancing, flow control, the industry today to develop service APIs [18, 19]. Hence,
reverse proxy, and health check control [10]. Therefore, it is believed that their performance and availability analysis
API Gateway can be envisioned as an API-oriented, cen- would be beneficial for both academia and the IT industry.
tral control entity in MSA, which sits at the boundary of Our rationale behind using performance efficiency and
the microservices and enables client applications to call availability as metrics for analyzing the API design tech-
microservices through a well-defined API with the right niques is that these metrics represent direct indicators that can
level of granularity [10–13] as illustrated in Fig. 1. Due help conclude which of the API design techniques is better to
to the intermediary role of API Gateways, they must oper- use in the implementation of API Gateways. Hence, for our
ate very quickly while dispatching API calls with very little analysis concerning performance efficiency and availability,
downtime. Therefore, performance and availability are cru- three separate API Gateway prototypes have been developed
cial non-functional qualifications that any API Gateway must involving REST, gRPC, and Apache Thrift as the API design
have. techniques, and tests were performed against each of the three
API design can be defined as the process of developing prototypes to see which of them outperforms the other.
APIs that expose the functionality of software applications For the performance measurement, a strategy that is out-
to their users (i.e., client applications, such as mobile clients, lined in [7] was used. In this strategy, the performance
web clients, and desktop clients). In the software industry, efficiency of a system is measured based on the request
there are API design techniques, such as Representational throughput. On the other hand, for the availability-related
State Transfer (REST) [14], Google’s Remote Procedure Call evaluation, average error rates [7, 20, 21] were analyzed
framework (gRPC) [15, 16], and Apache Thrift [17–19] that under different volumes of request loads.
can be utilized in the design and development of API Gate- To provide a practically usable analysis in our research, a
ways. commercial bank in Turkey, named Kuveyt Türk Participa-
REST [14] is the prevailing API design technique today tion Bank, cooperated. This bank has planned to transform its
that can be utilized in the design and implementation of monolithic banking platform to an MSA-based architecture
API Gateways. Nevertheless, API Gateways increasingly where an API Gateway is needed. The bank has provided us
embrace lightweight and high-performance network commu- with a realistic clustered environment where our prototypes
nications [18] to meet their high performance and availability were deployed as a case study. Consequently, the results that
qualifications. Therefore, Remote Procedure Call (RPC)- are provided in this paper were intended to help the bank
based API design techniques with better performance and choose from one of the API design techniques in their API
availability characteristics may be considered for API Gate- Gateway implementation.
ways as an alternative to REST. Apache Thrift and Google’s Moreover, to provide a concrete API Gateway imple-
Remote Procedure Call (gRPC) are well-known examples of mentation, Microsoft’s .NET framework v4.8 [22], which

123
Arabian Journal for Science and Engineering

is a general-purpose software development framework, was Montesi and Weber [11] evaluated different deployment
used in the C# language for the implementation of our API strategies/patterns for the common mechanisms found in
Gateway prototypes. In this context, .NET v4.8 was used MSA including API gateways. The authors proposed a
particularly because the existing code-base in the banking microservices programming language, named Jolie, for their
platform of the bank makes use of this particular version of deployment evaluation.
the .NET framework, and bank officials asked us to stick to Xu et al. [12] proposed a microservice security agent to
this version to avoid version-related possible problems that integrate an edge computing platform with an API gateway
may have been encountered in our prototypes’ implementa- for establishing a secure authentication mechanism. In this
tion. work, the authors implemented a REST-based API Gateway
The source code for the gRPC-based and Thrift-based API for communicating with services and configuring access con-
Gateway prototypes that were developed in the context of this trols. They also made use of the term round-trip-time (RTT)
paper was made available on GitHub. Links to this GitHub to demonstrate the efficiency of their API Gateway imple-
repository can be found in the supplementary material section mentation for real-world scenarios.
at the end of this paper. Lu et al. [13] proposed a microservice approach for IoT
The content that is provided in the rest of this paper is orga- systems where the “thing” in IoT was represented as a
nized as follows: In Sect. 2, earlier research work related to microservice. The authors argued that a microservice-based
our study has been summarized. In Sect. 3, the current state approach to building IoT systems could be combined with
of the art has been explained by providing background about patterns for microservices including API gateways. Their
the API design techniques being analyzed in this paper. Here, approach was experimented with by using two case studies of
our reasoning about the use of API design techniques for IoT systems in personal health management and connected
API Gateways particularly in MSA, and the limitation of our autonomous vehicle realms to show that interoperable, and
study have been explained. In Sect. 4, the experimental setup secure IoT services can be interconnected effectively via an
of our API Gateway prototypes for each of the API design API gateway.
techniques has been described in terms of performance effi- In [23], REST API performance was compared to
ciency and availability for analysis. In Sect. 5, our results advanced message queuing protocol (AMQP) by calculating
and comments have been presented. In Sect. 6, our conclu- the average number of messages that are being exchanged
sions have been drawn and possible future work has been for some time. Results of the work showed that AMQP out-
mentioned. performs REST for scenarios that require processing a large
amount of data.
Concerning API design in general, Afonso et al. [24] pre-
sented a combined semiotic and cognitive method to enhance
2 Related Work communication between designers and programmers for bet-
ter API design. Similar work was presented in [25] as an API
Our literature study has shown that the microservices-related framework to aid API designers in better organizing their
research area is relatively new and the number of published design decisions about business and technical concerns.
papers especially in the intersection of API Design, API Gate- There are also studies concerning other API design aspects
ways, and MSA is rather limited. such as usability. For example, Stylos et al. [26] proposed
Such intersection, for instance, exists in the communica- a general technique concerning the usability of API design
tion mechanisms in MSA involving API Gateways, such as choices particularly for identifying and preventing usability
circuit breakers, and service discovery agents. The studies problems in APIs. Similar work with more practical content
about these mechanisms do not only include the func- was made by Piccioni et al. [27] where authors systematically
tional design aspects of those software entities but also their observed the behavior of programmers in using a persistence
non-functional aspects, such as availability, interoperability, library API concerning flexibility and usability. In another
performance, scalability, security, and usability, which influ- work in this realm, Rauf et al. [28] conducted a literature
ence the quality of those entities including API Gateways. study to determine which API factors at which API devel-
Among these studies, Zhao et al. [10], for example, made opment phases could be used in the literature for usability
design proposals from a development efficiency perspective evaluation.
for implementing the functions that are provided by API Zuo et al. [29] proposed a scheme that could optimize the
Gateways in MSA, such as load balancing and automatic API Gateway implementation for performance and maintain-
service blowing. The authors conclude that Continuous opti- ability. The authors achieved this optimization by reducing
mization of the API gateway can make the development more the coupling degree of core services in the API Gateway
concise and efficient, and can achieve high-quality interac- implementation that was implemented in Java and by imple-
tion with microservices. menting a database with a memory buffer for holding the

123
 Arabian Journal for Science and Engineering

configuration data of the gateway. For the performance mea- sensor hardware, and Quality of Service (QoS) issues to
surement of the gateway, the authors set up test cases that achieve more robust and efficient network performance. For
produced various numbers of request loads and observed the this purpose, they highlighted SOA middleware for WSNs
associated response rates. and its characteristics in their survey. Although this particu-
A rather similar work to our research area in this paper was lar work at [32] was not directly related to API Gateways, it
made by Shafabakhsh et al. in [7] where authors performed intersects with our paper in the sense that both are concerned
a performance-wise and availability-wise comparison of with performance.
asynchronous and synchronous inter-microservice commu- In [33], Her et al. particularly proposed metrics, such as
nications that particularly utilized RabbitMQ, gRPC, and throughput and service response time, for practically measur-
REST. In comparison to this work in [7], our study in this ing service performance in SOA (i.e., the ancestor of MSA).
paper provides a performance and availability-related evalua- The measurement of these metrics was then performed in a
tion of synchronous communication that particularly utilized Hotel Reservation Service as a case study to show their appli-
API design techniques, namely REST, gRPC, and Thrift, cability and usefulness. Similar to this work, in our work in
instead. These API design techniques inherently provide a this paper, performance was a determining metric for decid-
synchronous communications scheme for the implementa- ing the proper API design technique to use particularly in
tion of API Gateways, which also, by design, establish a MSA.
request/response-based synchronous inter-communications Our study in this paper particularly focuses on MSA rather
scheme between clients and back-end microservices. than its earlier ancestor Service-Oriented Architecture (SOA)
There are also studies in the field of wireless sensor net- although SOA has been a solution for challenges in dis-
works (WSN) where the performance of API Gateway-like tributed systems. This is because MSA is considered to be an
systems, such as border surveillance systems, is investigated. evaluation of SOA where services are treated as more coarse-
For instance, in [30], the authors provided a comparison grained functions that are dependent on each other, whereas
basis for a set of well-known routing protocols, such as Ad MSA treats its services as more fine-grained functions that
hoc On-Demand Distance Vector (AODV), Optimized Link act independently of each other [34, 35]. This situation makes
State Routing Protocol (OLSR), and DSR, which can be uti- MSA-based distributed systems easier and faster to build and
lized in border surveillance systems that guard the entrance deploy today’s cloud-based distributed software systems in
of the WSNs. The authors concluded that DSR performed comparison to SOA. This is because the services themselves
better than other protocols in border surveillance applica- in MSA are smaller and, thus, easier and faster to deploy
tions. This work resembles our work in the sense that authors into cloud-native orchestrion platforms, such as Kubernetes
considered a set of well-known routing protocols concerning [36–43]. Moreover, API Gateways are the implementation
performance, such as Ad hoc On-Demand Distance Vector of a particular architectural pattern within the MSA (i.e.,
(AODV), Optimized Link State Routing Protocol (OLSR), namely API Gateway pattern). Therefore, the contribution of
and DSR, in designing the system architecture they proposed. this paper comes from its practical aspect that shows which of
In another study in the field of WSN, Hammoudeh et al. [31] the industrial API design techniques, namely REST, gRPC,
developed a modular border surveillance system architecture and Apache Thrift, can be used in the implementation of
that allowed timely and mission-centric event detection in the the API Gateways considering that the API gateways are the
WSN. In this architecture, authors designed and implemented backbone of communication between microservices and their
a method to calculate the required number of sensor nodes to clients. Performance and availability are two critical factors
achieve a specified level of coverage in WSN, which showed that determine how well the gateways can perform in MSA
significant performance gains in comparison to its best rival [3, 34, 39]. Hence, the context of our study in this paper is
in the literature, namely dynamic source routing (DSR) just particularly concerned with MSA and not SOA in compari-
like gRPC has been proposed as the API design technique in son to the related work that is summarized in Table 1 (e.g.,
our paper here. [32–35]).
In addition, there are studies, particularly in the intersec- As a side note, there are other API design techniques, such
tion of Service-Oriented Architecture (SOA) and the WSN. as GraphQL [44], that are also gaining popularity. Hence, a
SOA is the ancestor of MSA and it treats services as more future study would be to measure the performance of an API
coarse-grained functions that are relatively coupled with each Gateway having a GraphQL API. Nevertheless, the scope of
other in comparison to MSA. In the study at [32], for instance, our work in this paper is limited to the use of those 3 API
the authors provided a survey where they explored state- design techniques in API Gateway implementation particu-
of-the-art approaches based on SOA and Service-Oriented larly.
Middleware (SOM) architecture that provided solutions for
WSN-related challenges, such as communication, security,
power consumption, data aggregation, heterogeneities of

123
 Table 1 Summary of the related study

Authors and references Publication Summary Intersecting research fields

year

Zhao et al. [10] 2018 This paper provides a design proposal for the authentication of API Gateways to improve MSA, API gateway
the development efficiency of API Gateways. However, it is not related to the performance
efficiency and/or availability of API Gateways
Montesi and Weber [11] 2016 This paper focuses on the deployment strategies for the programming of widely used Microservices patterns, API gateway
MSA-based patterns including circuit breaker, service discovery, and API gateway
Xu et al. [12] 2019 This paper is about the security aspects of API Gateways. The authors proposed a secure Edge, computing, IoT, API gateway, security
access mechanism to their edge computing network (i.e., Internet of Things (IoT) device
network) via API Gateways
Arabian Journal for Science and Engineering

Lu et al. [13] 2017 This paper proposes that each IoT device in an IoT device network can be envisioned as if it IoT, API gateway, security
is a microservice and that an API Gateway can be used to access the IoT devices securely.
Nevertheless, this paper does not explicitly touch on techniques/technologies to develop
performance-efficient API Gateways
Fernandes et al. [23] 2013 This paper provides a performance comparison study of RESTful Web services and the Web services, AMQP-based messaging,
AMQP Protocol and resembles our work in the sense that both attempt to make a performance
performance comparison. However, the concern in this paper is more on web services, not
API Gateways
Afonso et al. [24] 2012 This work proposes a method to evaluate API as an artifact that facilitates collaboration and API design
communication between designers and programmers
Lindman et al. [25] 2020 This paper provides a strategic API framework to support business concerns when API design and maintenance
designing, updating, or maintaining APIs
Stylos et al. [26] 2006 This paper proposes a usability analysis technique based on common API design choices API usability
Piccioni et al. [27] 2013 This work covers the use of a cognitive dimensions framework to improve API usability API usability
Rauf et al. [28] 2019 This paper provides an evaluation basis for the usability of APIs API usability
Zuo et al. [29] 2020 This paper is similar to our work in the sense that both are related to API Gateway and its Microservices, API gateway and system
performance. However, our paper focuses on the specific use of API design techniques performance
that can be used in API Gateways and it bases its performance comparison logic on these
techniques
Sharei-Amarghan et al. 2013 In this paper, the performance of several WSN protocols was analyzed in the context of WSN, border surveillance systems and system
[30] border surveillance systems, which act like API Gateways on the border of WSNs performance

123
 Table 1 (continued)

Authors and references Publication Summary Intersecting research fields

year

Hammoudeh et al. [31] 2017 This work is similar to [30] in the sense that authors make performance comparisons for WSN, border Monitoring systems and system

123
border monitoring systems, which act similarly to API Gateways, in WSNs performance
Alshinina et al. [32] 2017 This work is in the intersection of SOA and WSN realms and it intersects with our paper in SOA, WSN and system performance
the sense that both our paper and this paper are concerned with performance
Her et al. [33] 2007 This paper provides a framework for measuring performance in SOA systems while ours is SOA, system performance
rather concentrated on MSA
Newman [34] 2015 This resource provides a sound background on MSA and its emergence as a continuation of MSA
SOA
Rademacher et al. [35] 2017 This paper sets out conceptual and practical differences between SOA and MSA and MSA, SOA
classifies them based on a hierarchical scheme
Erl [36] 2005 This resource describes the concepts, specifications, and standards behind service SOA
orientation and Web Services
Papazoglou et al. [37] 2007 This paper reviews technologies and approaches in SOA SOA
Papazoglou [38] 2012 This resource introduces the concepts, principles, techniques, and standards of web services SOA
Nadareishvili et al. [39] 2016 This resource provides background on the principles and practices of MSA MSA
Pahl et al. [40] 2016 This paper provides a systematic classification of the existing research on microservices and MSA, cloud
their application in the cloud
Azzedin et al. [41] 2019 This paper proposes an architecture that enables petroleum industries to select the necessary SOA
services from the SOA-based IT ecosystem
Saddam et al. [42] 2023 This paper provides a summary of the concerns about microservices and SOA Microservices and web-services
Farag et al. [43] 2010 This resource provides a solid background on the applicability and use of P2P and Grid SOA, P2P, grid computing
computing techniques for delivering efficient service-oriented computing
Arabian Journal for Science and Engineering
Arabian Journal for Science and Engineering

3 State of the Art

Remote Procedure Call (RPC) is a distributed application

development technique that was originally proposed by
Birrell and Nelson in their paper in 1984 [45] to make
inter-process communication (IPC) between operating sys-
tem (OS) processes (e.g., client and server-side application
processes) through a network protocol. Since the original
proposal of RPC, numerous frameworks, protocols, and spec-
ifications on top of RPC have been released, such as Common
Object Request Broker Architecture (CORBA), Microsoft’s
Distributed Common Object Model (DCOM), and Java
Remote Method Invocation (RMI) [46, 47]. Lately, modern
RPC-based techniques, such as gRPC [15] and Apache Thrift
[17], emerged for designing APIs.
As an alternative to RPC, the term “Web Service” emerged
in the early 2000s as a method of communication for stan-
dardizing the integration of web-based applications by using
technologies, such as Simple Object Access Protocol (SOAP)
and Representational State Transfer (REST) [14]. In the IT
industry today, Representational State Transfer (REST) is
the dominant method for designing stateless web service
APIs due to its simplicity [48, 49]. RESTful web services
are unique in that their APIs are defined based on resources
that are identified by Unified Resource Indicators (URIs)
and manipulated through HTTP verbs, such as GET, PUT, Fig. 2 Apache Thrift RPC call processing [18]
POST, and DELETE [14]. Nevertheless, because REST is
designed based on the client–server architecture that utilizes
a request-response protocol, namely HTTP, it doesn’t address while the client RPC stub together with the server RPC stub
concerns, such as serialization, messaging, and data stream- represents the code that is generated by the Thrift compiler.
ing [18]. The client process makes use of the client RPC stub to call a
On the other hand, today’s modern cloud-based software specific method that is provided by the Server process (i.e.,
systems come with requirements, such as high-performance, service).
lightweight, and language-agnostic network communica- Similar to Thrift, gRPC is also a high-performance RPC
tions with built-in serialization support [18]. Apache Thrift framework that is developed by Google (historically later
comes into play as a response to meet such requirements. than Thrift) based on Google’s earlier cross-language data
It was originally developed in Facebook as an open- serialization framework, named protocol buffers, and it
source, cross-language serialization and remote procedure is designed to meet the same need that Thrift tries to
call (RPC) framework that can meet the above-mentioned meet, which is the rapid development of high performance,
requirements that REST lacks. It also facilitates rapid appli- lightweight, cross-language service APIs. In addition, gRPC
cation development as it enables cross-language storage and offers data streaming that both REST and Thrift lack.
retrieval of data over the wire [17–19, 50, 51]. In gRPC, application-level types and service interfaces are
Thrift claims to provide a complete software development defined in text files in protocol buffers definition language
stack where application-level types and service interfaces format. The protocol buffer compiler (protoc) reads these
are defined in text files that are written in thrift interface files and generates serialization code and RPC client/server
definition language (IDL) format. The Thrift IDL compiler stubs that supply all necessary infrastructure for the clients
reads these IDL files and outputs serialization code and RPC to call a service API on the server side remotely as illustrated
client/server stubs that supply the necessary infrastructure in Fig. 3 [15, 16, 52].
to call a function remotely in any of the target programming In comparison to Thrift, gRPC allows bidirectional com-
languages [50, 51]. By using these stubs, the client and server munication over HTTP/2 protocol between clients and
start a request-response-based communication flow between servers. Hence, just like a client can call a function on the
each other as shown in Fig. 2. Here, the client process and server, the server can initiate a call back to a specific client.
server process represent the developer-written code blocks On the other hand, Thrift works on a lower transport layer

123
 Arabian Journal for Science and Engineering

Fig. 3 gRPC Call processing [16]

protocol, namely TCP/IP, and does not support streaming in

comparison to gRPC. Both gRPC and Thrift claim to offer
high performance in server-side applications.

4 Implementation

4.1 The Monolithic System at Hand

To keep our evaluation as realistic as possible, a mono-

lithic software system (namely Business-Oriented Architec-
ture—BOA [53]) was used in our work in this paper. BOA
has been developed in Kuveyt Türk Participation Bank since
2010 as an attempt to produce an end-to-end integrated mul-
tichannel banking platform. The bank has permitted us to
make use of BOA to produce data traffic and to use the related
banking libraries available in the BOA infrastructure.
The internals of BOA have been designed as a multi-
tiered Model View Controller (MVC) [54] application using
Microsoft technologies, such as Windows Communication Fig. 4 Overview of the multi-tier monolith BOA architecture
Foundation (WCF) [55], Windows Presentation Foundation
(WPF) [56], and .NET framework [22]. This has been illus-
trated in Fig. 4 by the yellow frames, namely the orchestration on the other hand, represent specialized server-side appli-
layer, business logic layer, and data integration layer, together cations (e.g., windows services) that run scheduled tasks in
with the presentation layer at the top. BOA. Examples of such tasks can be a batch task that sends
The clients that are listed side-by-side at the top of Fig. 4 campaigns and/or banking services-related SMS messages
represent the client applications that make use of the BOA and/or e-mails via BOA infrastructure or a batch task that
infrastructure. Here, WPF client is used by administrative makes scheduled money transfers for specific purposes.
bank personnel who are mostly working at branch offices. The dashed vertical frames in gray in Fig. 4 represent
iOS and Android clients represent the native mobile apps of infrastructure modules that contain critical application logic
the bank, which are used by the customers of the bank, while that influences how the entire architecture behaves. These
the React web client represents the Internet banking web- modules are named Identity Management, Core Banking,
site again used by the customers of the bank. Server APPs, Notification Engine, and Workflow Engine, respectively.

123
Arabian Journal for Science and Engineering

Lastly, the vertical transactional management module pro-

vides single-lock transaction management in BOA to guar-
antee end-to-end transactional integrity. This is represented
by the vertical frame in blue in Fig. 4.

4.2 Preparation of the Experimental Environment

There is a plan in the bank to transform its monolithic BOA

infrastructure to an MSA-based banking IT infrastructure
that can be possibly sold to other banks as a cloud-native
banking platform. Hence, our evaluation in this paper pro-
vides input for determining which API design technique
(i.e., REST, gRPC, or Apache Thrift) to use particularly
for the implementation of API Gateway in the resulting
MSA-based system. Therefore, the following sub-sections
describe the experimental environment that was established
for our evaluation by utilizing the existing BOA infrastruc-
Fig. 5 Experimental setup: API gateway dispatching requests towards
ture modules/libraries as a starting point. This experimental microservices that make use of BOA DLLs
environment does not exactly reflect the resulting MSA-
based system that is planned by the bank as a whole. However,
it is sufficient for our evaluation purposes. the BOA implementation to fulfill the required banking oper-
ations, such as sending campaign emails and making money
transfers.
4.2.1 Determining Candidate Monolithic Modules to be
Transformed into Microservices 4.2.2 Determining Types of Clients

The very first step in preparing our experimental environ- The second step in preparing our experimental environment
ment was to determine candidate BOA modules from where is to determine the types of clients that can simulate the client
microservices were deduced. Because the bank allowed us requests. Among the clients of BOA, namely WPF client,
only to investigate the implementation of notification and iOS/Android client, react client, and server apps, our focus is
core modules in their monolith BOA infrastructure, the noti- limited particularly on the server APPs in order not to expose
fication engine and core banking module were chosen as the ourselves to client-side technologies in producing our exper-
primary candidate modules to transform into microservices. imental test data. Therefore, in the following subsection, it is
A notification engine is used within the entire BOA sys- described how the server APPs were simulated to generate
tem to send enterprise-related messages, such as campaign the data traffic for our experiments.
emails, bulk SMS messages, and alerts. On the other hand,
core banking is used to fulfill critical business operations, 4.2.3 How do Server APPs Should Reach API Gateway?
such as money transfers and accounting. Both of these mod-
ules, named notification engine and core banking module, In this step of preparing our experimental environment,
are critical for performance efficiency and availability since Apache JMeter [57] was used to simulate two server APPs,
any absence or delay in the provision of the services that are namely campaign batch task and money transfer batch task,
provided by these modules will break the end-to-end success which act as scheduled tasks as shown at the top of Fig. 5. The
of the financial operations. Therefore, they fit well into the rationale behind using the campaign batch task and money
context of our experiments. transfer batch task was that Kuveyt Türk Bank specifically
Hence, in the context of the study in this paper, two allowed us to study the internals of these two batch tasks in
microservices were implemented, which fulfilled the func- producing artificial test requests.
tionality of these modules (namely notification engine and On the other hand, the rationale for using JMeter was that
core banking) partially for the sake of our performance and it could help us generate a large number of artificial requests
availability-related evaluation. These two microservices are that can mimic the behavior of those two batch tasks. These
called notification microservice and transfers microservice, JMeter-generated artificial requests could be continuously
respectively, as seen in Fig. 5. The implementations of these pushed to our API Gateway prototype in our experimental
microservices make use of several DLLs that are available in setup, which is then called the proper microservice(s) where

123
 Arabian Journal for Science and Engineering

Table 2 Configuration of a virtual host where an API gateway prototype 4.2.5 API Gateway and Microservices Deployment
is deployed

Hardware type Capacity For setting up our experiments in a networked environ-

ment, the API Gateway implementation together with the
vCPU 8 Cores microservices (namely notification microservice and trans-
Memory 16 GB fers microservice) were deployed into separate Linux-based
Storage 120 GB SSD virtual machines that were located in a clustered environment
in Kuveyt Türk Bank’s on-premise data center. It would be
technically possible to realize our experiments in a cloud
service provider’s cluster (e.g., Azure). However, due to the
Table 3 Configuration of a virtual host where a microservice is banking regulations in Turkey, it was not allowed to do the
deployed experiments in a cloud provider’s platform. For this reason,
Hardware type Capacity our experiments, whose results have been provided in the
next section, were realized in the clustered environment that
vCPU 8 Cores was located in the bank’s on-premise data center.
Memory 8 GB As a side note, it is worth mentioning that our experiments
Storage 120 GB SSD were performed against the same test database instance,
which is an identical copy of the production database. The test
database is periodically cloned from the production database
by the bank and specific data are jammed in the test database
the real backend application logic was executed per request instance. For example, customer names, birth dates, account
as illustrated in Fig. 5. numbers, account balance data, and other personal data are
intentionally changed through randomizer scripts so that
customer-specific data is only preserved in the production
4.2.4 API Gateway and Microservices Implementation database.

The final and probably the most important step in establishing

our experimental environment is API Gateway as it consti-
tutes the backbone of communications from the clients to the 5 Results and Comments
microservices. Hence, the type of API design technique that
is used in API Gateway implementation is critical in terms 5.1 Performance Efficiency
of performance and availability.
To evaluate the API design techniques, namely REST, Throughput is a fundamental measurement of performance
gRPC, and Apache Thrift, three different API Gateway proto- efficiency as it indicates the number of transactions that are
types in C# were implemented in our study involving the use produced over a specific period. In the context of our analy-
of each of these techniques. These prototypes were deployed sis, the strategy that is outlined in [7] was used. According
to identical virtual hosts with the specifications indicated in to this strategy, the performance efficiency of each of the
Table 2 as follows: API Gateway prototypes was calculated based on the request
On the other hand, two experimental microservices throughput, which can be expressed as the total number of
(named notification microservice and transfers microservice) requests that were processed per second by each of the API
where requests are dispatched by API Gateway prototypes Gateway prototypes over a fixed period (i.e., 3 min).
using the ASP.NET Web API framework [58] were imple- Our REST-based API Gateway was implemented in C#
mented. The rationale behind implementing notification by using the ASP.NET Web API framework [43]. On the
microservice and transfers microservice particularly was that other hand, both our gRPC-based API Gateway prototype
the bank provided us to study only the source code of the noti- and Thrift-based API Gateway prototype were implemented
fication and money transfer-related modules in the source in C# by using the .NET framework v4.8. .NET framework
code of its monolith BOA platform. Therefore, the applica- v4.8 was particularly used because the prototype codes had
tion that is provided by these experimental services, namely to be compatible with the bank’s existing C# libraries (i.e.,
notification microservice and transfers microservice, is rather Dynamically Linked Libraries—DLLs) that have been in use
similar to the application logic in the notification and money in the existing BOA implementation. DLLs are Microsoft’s
transfer-related modules. These experimental services were implementation of the shared library concept in the Microsoft
then deployed to a virtual host with the specifications indi- Windows and OS/2 operating systems and they are compiled
cated in Table 3: and linked against the .NET framework.

123
Arabian Journal for Science and Engineering

better than the performance of our Thrift-based API Gateway

prototype. Therefore, the performance strength (i.e., request
throughput) of our API Gateway prototypes can be ordered
from the highest to the lowest as gRPC, REST, and Thrift.
At the time of writing this paper, Thrift’s official netstd
NuGet package library (namely C#.NET Core bindings for
the Apache Thrift RPC system [60]) with version 0.14.1 was
used in our Thrift-based API Gateway prototype implemen-
tation. This NuGet package library has been under active
development since 2019. However, in our performance eval-
uation, it was observed that our Thrift-based API Gateway
prototype that was developed based on this NuGet library
had low performance in comparison to our gRPC and REST-
based API Gateway prototypes.
Fig. 6 Performance comparison in terms of request throughput among
the API gateways utilizing the three API design techniques, namely
5.2 Availability Evaluation
gRPC, Thrift, and REST, for 50, 100, and 200 concurrent clients, respec-
tively
The availability of a system is a ratio that indicates how long
the system can be in normal operation without undergoing a
For the Thrift prototype, TThreadPoolAsyncServer [59] complete failure that implies a hundred percent error rate
was used as the server type in its implementation. This [7, 20, 61]. The availability of a software system can be
specific server type is provided in the NuGet package affected by many factors both software-wise and hardware-
library of Thrift (namely C# net standard bindings for the wise [62–65]. Therefore, there can be different approaches
Apache Thrift RPC system [60]) with version 0.14.1. The to determining the availability of a system. In the context of
TThreadPoolAsyncServer implementation was used because this paper, all factors other than the type of API design tech-
a non-blocking multithreaded server-side implementation of nique were ignored in measuring the availability, and our
Thrift was more useful for our prototype concerning perfor- availability measurements were made based on the average
mance. error rates.
Each of our API Gateway prototypes was deployed into Similar to our performance-related test cases that are
a separate virtual host with an identical configuration that described in the previous sub-section, test cases in JMeter
is indicated in Table 2. Each virtual host is provided by the were implemented for measuring and analyzing the avail-
bank in a virtual clustered environment. ability of our API Gateway prototypes in terms of average
In addition, three different test cases were implemented error rates. These availability test cases utilized our custom
by using JMeter for each of the prototypes for measuring the JMeter samplers that were used in our earlier performance
request throughput. For these test cases, custom samplers tests and we aimed to execute these samplers continuously
in Java were implemented and their compiled jar files were until API Gateway prototypes became completely unavail-
imported into JMeter to make use of them as plugins in our able (i.e., until they undergo a complete failure). Hence, for
JMeter-based test cases. each availability test case, it was presumably concluded that
In the first test case, 50 concurrent virtual clients were a failure occurred as soon as the error rate in the JMeter
run in JMeter to bombard our API Gateway prototypes with console output became a hundred percent.
artificial requests for 3 min. Here, a virtual client made use Nevertheless, it is not practically straightforward to deter-
of exactly one thread. mine the proper number of concurrent test clients as a
Same-wise, in the second test case, the tests were run for baseline, which can lead to a 100 percent error rate (i.e.,
3 min but this time with 100 concurrent clients for each of a complete failure). Therefore, experiments were necessary
the prototypes. For the third test case, 200 concurrent clients to be made via JMeter to determine the minimum number of
were run again for 3 min. Our performance results are shown concurrent clients that could help us simulate an intentional
as request throughput (i.e., # of processed requests per sec- failure on our API Gateway prototypes. Hence, after running
ond) in the vertical axis of the graph which is shown in 15,000 concurrent clients against our REST and gRPC-based
Fig. 6. Here, the performance (i.e., request throughput) of gateway prototypes separately for 10 min, it was observed
our gRPC-based API Gateway was around five times better that there was an average error rate of 40.95 percent for the
than the performance of our REST-based API gateway in all gRPC prototype and an average error rate of 88.38 percent
three test cases. On the other hand, the performance of our for the REST prototype as shown in Table 4. These aver-
REST-based API Gateway prototype was around four times age error rates showed that concerning the availability, our

123
 Arabian Journal for Science and Engineering

Table 4 Average error rates observed at availability-related tests that availability. Our opinion about this situation is that Thrift’s
were executed with 15,000 concurrent clients for 10 min .NET-specific library needs further improvements. One such
API design technique Average error rate (percent)a improvement can be to incorporate an HTTP/2 transport,
which is mainly used in today’s cloud-native service mesh
gRPC 40.95 technologies, into Thrift. This would particularly improve
REST 92.38 Thrift’s performance because Thrift’s current transport layer
a
protocol usage (i.e., TCP usage) puts more load on the CPU
Thrift-based API Gateway prototype was not included in availability
since the transport layer has a variety of controls in commu-
tests because these tests specifically required a high request load (e.g.,
15,000 clients), which could not be undertaken by the Thrift prototype nications in comparison to HTTP/2. Another improvement in
Thrift can be providing support for streaming large amounts
of data since in today’s cloud-native era, there likely happens
gRPC-based API Gateway outperformed its REST counter- a necessity to transfer large amounts of data (e.g., big data)
part since its average error rate was almost half of the average for many IT firms.
error rate of the REST-based gateway. In conclusion, concerning both performance and
On the other hand, unlike our gRPC and REST-based API availability-related efficiency, the strength of our API Gate-
Gateway prototypes, the Thrift prototype could not withstand way prototypes can be ordered from highest to lowest as
request loads with, for example, 7000, 11,000, and 15,000 gRPC, REST, and Thrift [66, 67]. Nevertheless, our API
concurrent clients and became completely unresponsive right gateway prototypes were intentionally developed by using
at the beginning of our availability tests. This was an expected Microsoft’s general-purpose application development frame-
situation due to the low throughput values of the Thrift pro- work, namely .NET, because the bank, where our case study
totype as seen in Fig. 6. For this reason, our Thrift-based was performed, was using .NET-related technologies and it
API Gateway prototype was excluded from the availabil- asked us to stick to this framework. Hence, a possible future
ity tests with 15,000 clients, which were executed against work as a follow-up to this paper would be making a sim-
our gRPC and REST-based prototypes only. Hence, it was ilar evaluation by taking frameworks other than the .NET
concluded that the availability of the Thrift prototype is the framework, such as Java EE, Go or Lua into account while
lowest among all our API Gateway prototypes. implementing the API Gateway prototypes per API design
technique. This would also bring a framework aspect to the
evaluation for possible future work giving an indicator to
6 Conclusion the IT companies on which framework to use in their API
Gateway implementations.
In our work in this paper, performance and availability- As a side note, there are other API design techniques, such
related analyses were made to determine the performance as GraphQL [44], that are also gaining popularity. Hence,
efficiency of today’s modern API design techniques, namely another future study would be to measure the performance
REST, gRPC, and Apache Thrift, particularly in the design of an API Gateway having a GraphQL API.
and implementation of API Gateways due to their working
Acknowledgements The work that is presented in this paper is sup-
characteristics requiring high performance and availability. ported by the Turkish Scientific and Technological Research Council
Our measurements were conducted through a case study that (TÜBİTAK) in the context of a base research project with Project num-
was performed by using the hardware and software resources ber 5210012.
that were provided by Kuveyt Türk Participation Bank. In
Authors’ Contributions Fikri AYDEMİR, Architect Information Sys-
this case study, three separate API Gateway prototypes were tems, R&D Center, Istanbul, Turkey. Fatih BAŞÇİFTÇİ, Selcuk Uni-
developed for each of the API design techniques, namely versity, Faculty of Technology, Dept. of Computer Engineering, Konya,
REST, gRPC, and Apache Thrift, and our evaluation was Turkey.
performed based on the results of the tests that were run
Availability of Supporting Data We have provided the source code
against these prototypes. for our gRPC-based and Thrift-based API Gateway prototypes at the
The test results showed that our gRPC-based API Gate- GitHub repositories that are available at [52, 53], respectively. Due to
way prototype implementation outperformed both REST proprietary reasons, bank-specific code segments have been removed
from the source code of both prototypes and only the skeleton of the
and Thrift-based prototypes substantially in terms of both
server-side implementations has been shared. We could not provide any
performance and availability. Nevertheless, although the code belonging to the REST-based API Gateway implementation due
REST-based prototype provided lower results compared to to preparatory reasons.
its gRPC counterpart, its results were still rather promising.
Our Thrift-based API Gateway prototype, which was
developed based on Thrift’s .NET platform-specific library
[45], showed the worst results concerning performance and

123
Arabian Journal for Science and Engineering

Declarations 14. Fielding, R.T. (the University of California, I. (2000). Architectural

Styles and the Design of Network-based Software Architec-
Conflict of interest The authors of the manuscript confirm that there tures [University of California, Irvine]. https://www.ics.uci.edu/
are no conflicts of interest regarding its publication. ~fielding/pubs/dissertation/top.htm
15. [n.d.] gRPC: A high-performance, open-source universal RPC
Ethical Approval and Consent to Participate Not applicable. framework. https://grpc.io/. Accessed on Mar 2021
16. Du, S.G.; Lee, J.W.; Kim, K.: Proposal of GRPC as a New North-
Human and Animal Ethics Not applicable. bound API for Application Layer Communication Efficiency in
SDN. In: Proceedings of the 12th International Conference on
Consent for Publication Not applicable. Ubiquitous Information Management and Communication (2018).
https://doi.org/10.1145/3164541.3164563
Supplementary Material The source code for our gRPC-based and 17. [n.d.] Apache Thrift software framework for scalable cross-
Thrift-based API Gateway prototypes was provided at the GitHub repos- language services development. https://thrift.apache.org/.
itories that are available at [51, 52] respectively. Nevertheless, due to Accessed on Mar 2021
proprietary reasons, bank-specific code segments were removed from 18. Abernethy, R.: Programmer’s Guide to Apache Thrift. Manning
the source code of both prototypes, and only the skeleton of the server- Publications Co, New York (2019)
side implementations was shared. Unfortunately, it was not possible to 19. Abernethy, R.; Sukegawa, N.: Building High-Performance
provide any code belonging to the REST-based API Gateway imple- Microservices with Apache Thrift. Linux Foundation. http://
mentation because the bank did not permit us to share any code sample events17.linuxfoundation.org/sites/events/files/slides/hp-msa-
for it. thrift.pdf (2017). Accessed on Mar 2021
20. Engelmann, C.; Ong, H.; Scott, S.: The case for modular redun-
dancy in large-scale high-performance computing systems. In:
Proceedings of the IASTED International Conference on Parallel
and Distributed Computing and Networks, PDCN 2009 (2009)
References 21. [n.d.]. Availability Testing. https://testautomationsriram.
wordpress.com/availability-testing/. Accessed on Mar 2021
1. Chen, R.; Li, S.; Li, Z.: From Monolith to Microservices: A 22. [n.d.] .NET Framework: A software development framework for
Dataflow-Driven Approach. In: 2017 24th Asia-Pacific Software building and running applications on Windows. https://dotnet.
Engineering Conference (APSEC), pp. 466–475 (2017). https:// microsoft.com/learn/dotnet/what-is-dotnet-framework. Accessed
doi.org/10.1109/APSEC.2017.53 on Apr 2021
2. Fowler, M.; Lewis, J.: Microservices - A definition of 23. Fernandes, J.L.; Lopes, I.M.C.; Rodrigues, J.; Ullah, S.: Perfor-
this new architectural term. https://martinfowler.com/articles/ mance evaluation of RESTful web services and AMQP protocol.
microservices.html (2014). Accessed on Mar 2021 In: 2013 Fifth International Conference on Ubiquitous and Future
3. Richardson, C.: Microservices patterns: with examples in Java, Networks (ICUFN), pp. 810–815 (2013)
Manning Publications (2019) 24. Afonso, L.; Cerqueira, R.; Souza, C.D.: Evaluating application pro-
4. [n.d.]. 4 Microservices Examples: Amazon, Netflix, Uber, gramming interfaces as communication artifacts. PPIG (2012)
and Etsy. https://blog.dreamfactory.com/microservices-examples/. 25. Lindman, J.; Horkoff, J.; Hammouda, I.; Knauss, E.: Emerg-
Accessed on Mar 2021 ing perspectives of application programming interface strategy: a
5. [n.d.]. Adopting Microservices at Netflix: Lessons for Archi- framework to respond to business concerns. IEEE Softw. 37(2),
tectural Design. https://www.nginx.com/blog/microservices-at- 52–59 (2020). https://doi.org/10.1109/MS.2018.2875964
netflix-architecturalbest-practices/. Accessed on Jan 2021 26. Stylos, J.; Clarke, S.; Myers, BA..: Comparing API Design Choices
6. [n.d.]. Airbnb’s 10 Takeaways from Moving to Microser- with Usability Studies: A Case Study and Future Directions (2006)
vices. https://thenewstack.io/airbnbs-10-takeaways-moving- 27. Piccioni, M.; Furia, C.A.; Meyer, B.: An Empirical Study of
microservices/. Accessed on Mar 2021 API Usability. In: 2013 ACM/IEEE International Symposium
7. Shafabakhsh, B.; Lagerström, R.; Hacks, S.: Evaluating the on Empirical Software Engineering and Measurement, pp. 5–14
impact of inter-process communication in microservice architec- (2013). https://doi.org/10.1109/ESEM.2013.14
tures. CEUR Workshop Proceedings, 2767 (December), pp. 55–63 28. Rauf, I.; Troubitsyna, E.; Porres, I.: A systematic mapping study
(2020) of API usability evaluation methods. Comput. Sci. Rev. 33, 49–68
8. Bloch, J.: How to Design a Good API and Why It Matters. Compan- (2019). https://doi.org/10.1016/j.cosrev.2019.05.001
ion to the 21st ACM SIGPLAN Symposium on Object-Oriented 29. Zuo, X.; Su, Y.; Wang, Q.; Xie, Y.: An API gateway design strat-
Programming Systems, Languages, and Applications, pp. 506–507 egy optimized for persistence and coupling. Adv. Eng. Softw. 148,
(2006) 102878 (2020)
9. Fritzsch, J.; Bogner, J.; Zimmermann, A.; Wagner, S.: From Mono- 30. Sharei-Amarghan, H.; Keshavarz-Haddad, A.; Garraux, G.: Rout-
lith to Microservices: A Classification of Refactoring Approaches. ing protocols for border surveillance using zigbee-based wireless
Lecture Notes in Computer Science, pp. 128–141 (2019) sensor networks. Commun. in Comput. Inf. Sci. (2013). https://doi.
10. Zhao, J.T.; Jing, S.Y.; Jiang, L.Z.: Management of API gateway org/10.1007/978-3-642-38865-1_13
based on micro-service architecture. J. Phys. Conf. Ser. 1087, 31. Hammoudeh, M.; Al-Fayez, F.; Lloyd, H.; Newman, R.; Adebisi,
32032 (2018) B.; Bounceur, A.; Abuarqoub, A.: A wireless sensor network bor-
11. Montesi, F.; Weber, J.: Circuit Breakers, Discovery, and API Gate- der monitoring system: deployment issues and routing protocols.
ways in Microservices. https://arxiv.org/abs/1609.05830 (2016) IEEE Sens. J. 17(8), 2572–2582 (2017). https://doi.org/10.1109/
12. Xu, R.; Jin, W.; Kim, D.: Microservice security agent based on API jsen.2017.2672501
gateway in edge computing. Sensors 19(22), 4905 (2019) 32. Alshinina, R.; Elleithy, K.: Performance and challenges of service-
13. Lu, D.; Huang, D.; Walenstein, A.; Medhi, D.: A Secure Microser- oriented architecture for wireless sensor networks. Sensors 17(3),
vice Framework for IoT. In: Proceedings - 11th IEEE International 536 (2017). https://doi.org/10.3390/s17030536
Symposium on Service-Oriented System Engineering, SOSE 2017, 33. Her, J.S.; Choi, S.W.; Oh, S.H.; Kim, S.D.: A Framework for Mea-
pp. 9–18 (2017). https://doi.org/10.1109/SOSE.2017.27 suring Performance in Service-Oriented Architecture. In: Third

123
 Arabian Journal for Science and Engineering

International Conference on Next Generation Web Services Prac- 53. [n.d.]. Kuveyt Türk’s technology company Architect is the
tices (NWeSP’07) (2007). https://doi.org/10.1109/nwesp.2007.24 fastest-growing information company. https://www.kuveytturk.
34. Newman, S.: Building Microservices, 1st edn. O’Reilly Media, com.tr/en/about-us/about-kuveyt-turk/news/kuveyt-turk-speeds-
Sebastopol (2015) up-its-investments-in-technology-and-transformation-through-
35. Rademacher, F.; Sachweh, S.; Zundorf, A.: Differences between architecht. Accessed on Mar 2021
Model-Driven Development of Service-Oriented and Microservice 54. Krasner, G.; Pope, S.: A cookbook for using the model-view-
Architecture. In: 2017 IEEE International Conference on Software controller user interface paradigm in Smalltalk - 80. J. Object-
Architecture Workshops (ICSAW) (2017). https://doi.org/10.1109/ Oriented Program. - JOOP 1(3), 26–49 (1998)
icsaw.2017.32 55. [n.d.] Windows Communication Foundation (WCF): A framework
36. Erl, T.: Service-Oriented Architecture (SOA) Concepts, Technol- for building service-oriented applications. https://docs.microsoft.
ogy, and Design. Prentice Hall, Hoboken (2005) com/en-us/dotnet/framework/wcf/whats-wcf. Accessed on Apr
37. Papazoglou, M.P.; Van Den Heuvel, W.-J.: Service-oriented archi- 2021
tectures: approaches, technologies, and research issues. VLDB J. 56. [n.d.] Windows Presentation Foundation (WPF): A UI framework
16(3), 389–415 (2007) that creates desktop client applications. https://docs.microsoft.
38. Papazoglou, M.P.: Web Services SOA: Principles and Technology. com/en-us/visualstudio/designers/getting-started-with-wpf .
Pearson Education, vol. 2 (2012) Accessed on Apr 2021
39. Nadareishvili, I.; Mitra, R.; Mclarty, M.; Amundsen, M.: Microser- 57. [n.d.] JMeter: An open-source software designed to load test func-
vice Architecture. O’Reilly Media, Sebastopol (2016) tional behavior and measure performance. https://jmeter.apache.
40. Pahl, C.; Jamshidi, P.: Microservices: A systematic mapping study. org/. Accessed on Apr 2021
In: Proc. of the 6th Int. Conf. on Cloud Computing and Services 58. [n.d.] ASP.net Web APIs: Building secure REST APIs with C#.
Science (CLOSER), 2016, pp. 137–146 (2016) https://dotnet.microsoft.com/apps/aspnet/apis. Accessed on Apr
41. Azzedin, F.; Ghaleb, M.: Towards an architecture for handling big 2021
data in oil and gas industries: service-oriented approach’. Int. J. 59. [n.d.] TThreadPoolAsyncServer Implementation in C#. https://
Adv. Comput. Sci. Appl. 10(2), 554–562 (2019) github.com/apache/thrift/blob/master/lib/netstd/Thrift/Server/
42. Saddam, M.; Saif, A.: Microservices and web-services: a review. TThreadPoolAsyncServer.cs. Accessed on Apr 2021
Peta Int. J. Soc. Sci. Humanit. 1(1), 66 (2023) 60. [n.d.] C# .NET Core bindings for the Apache Thrift RPC system.
43. Farag, A.; Eltoweissy, M.; Khwaja, S.A.: Overview of Service https://www.nuget.org/packages/ApacheThrift. Accessed on Apr
Oriented Architecture for Resource Management in P2P Sys- 2021
tems. In: Antonopoulos, N. et al. (eds.) Handbook of Research 61. Chaczko, Z.; Mahadevan, V.; Aslanzadeh, S.; Mcdermid, C.: Avail-
on P2P and Grid Systems for Service-Oriented Computing: Mod- ability and Load Balancing in Cloud Computing (2011)
els, Methodologies, and Applications, pp. 175–196. IGI Global, 62. Siewiorek, D.P.; Swarz, R.S.: Reliable Computer Systems: Design
Hershey (2010) and Evaluation, 3rd edn. A K Peters/CRC Press, Natick (1998)
44. [n.d.] GraphQL: A query language for APIs. https://graphql.org/. 63. Koren, I.; Krishna, M.C.: Fault-Tolerant Systems, 2nd edn. Morgan
Accessed on Apr 2023 Kaufmann Publishing, Burlington (2020)
45. Birrell, A.D.; Nelson, B.J.: Implementing remote procedure calls. 64. Elms, C.P.: Defining and measuring service availability for com-
ACM Trans. Comput. Syst. 2(1), 39–59 (1984) plex transportation networks. J. Adv. Transp. 32(1), 75–88 (1998)
46. Olsson, R.A.; Keen, A.W.: The JR Programming Language, 1st 65. Daly, J.T.; Pritchett-Sheats, L.A.; Michalak, S.E.: Application
edn. Springer, Boston (2004) https://doi.org/10.1007/b116040 MTTFE vs. Platform MTBF: A Fresh Perspective on System Reli-
47. Waldo, J.: Remote procedure calls and java remote method invo- ability and Application Throughput for Computations at Scale. In:
cation. IEEE Concurr. 6(3), 5–7 (1998). https://doi.org/10.1109/ 2008 Eighth IEEE International Symposium on Cluster Computing
4434.708248 and the Grid (CCGRID), pp. 795–800 (2008)
48. Hirsch, F.; Kemp, J.; Ilkka, J.: Mobile Web Services: Architecture 66. [n.d.]. Sample gRPC Server. https://github.com/faydemir1/
and Implementation. John Wiley & Sons, Hoboken (2007) SampleGrpcServerInCS. Accessed on Apr 2021
49. Bora, A.; Bezboruah, T.: A comparative investigation on implemen- 67. [n.d.]. Sample Thrift Server. https://github.com/faydemir1/
tation of RESTful versus SOAP-based web services. Int J Database SampleThriftServerInCS. Accessed on Apr 2021
Theory Appl 8(3), 297–312 (2015)
50. Prunicki, A.: Apache Thrift. Software Engineering Tech Trends. Springer Nature or its licensor (e.g. a society or other partner) holds
http://jnb.ociweb.com/jnb/jnbJun2009.html (2015) exclusive rights to this article under a publishing agreement with the
51. Slee, M.; Agarwal, A.; Kwiatkowski, M. (n.d.). Thrift: Scalable author(s) or other rightsholder(s); author self-archiving of the accepted
Cross-Language Services Implementation manuscript version of this article is solely governed by the terms of such
52. Chamas, C.L.; Cordeiro, D.; Eler, M.M.: Comparing REST, SOAP, publishing agreement and applicable law.
Socket, and gRPC in computation offloading of mobile applica-
tions: An energy cost analysis. In: 2017 IEEE 9th Latin-American
Conference on Communications (LATINCOM), pp. 1–6 (2017)

123