ThesisPDF Available

Understanding re-emergence of the RPC model in web development

Authors:

Abstract

RPC is a request-response protocol from the 1980s, which allows developers to invoke remote functions from an application. It was originally used in distributed systems, but was also used in web development in the late 1990s and early 2000s. RPC's popularity began decreasing after the REST-style architecture appeared in the early 2000s. However, in the recent years, the RPC-model has re-emerged in web development. This bachelor's thesis focuses on understanding the recent growth in popularity of the RPC model. In addition, this work explores the impact of modern RPC frameworks on web development practices and offers comparison between REST, RPC and GraphQL. This thesis is a literature review that utilizes scientific articles, technological documentation and blog posts. This study found out that in the early 2000s, web development moved from RPC to REST architecture due to the low performance of RPC implementations at the time. The internet was growing rapidly, requiring scalable and high-performance web services, and REST answered to this demand. The 2010s saw new trends in web development, such as microservices and TypeScript. These trends led to the emergence of new RPC frameworks, such as gRPC and tRPC. These modern RPC frameworks leverage advancements in network protocols, serialization formats, and type systems to offer an alternative to the REST architectural style. gRPC is especially popular in microservices systems due to its high performance, whereas tRPC offers developers using TypeScript the ability to develop type-safe full-stack applications. The RPC model has also been integrated into the popular front-end framework React, which provides the ability to call server-side methods directly from client-side components. With the emergence of modern RPC frameworks, developers have more options in web service development tools. Developers have access to more specialized tools and can choose the one that best suits their needs. Although modern RPC implementations may not be as universally applicable as REST or GraphQL, they can offer significant benefits in certain types of applications. gRPC and tRPC streamline the development of web services by offering an improved developer experience. Additionally, they reduce the risk of errors through type safety.
Aalto University
BACHELOR’S THESIS 2024
Understanding re-emergence of
the RPC model in web develop-
ment
Ruupert Koponen
Supervisor: Professor Lauri Savioja
Advisor: Doctoral Researcher Juho Vepsäläinen
Aalto University
School of Science
Bachelor’s Programme in Science and Technology
Abstract
Aalto University, P.O. Box 11000, FI-00076 Aalto www.aalto.fi
Author
Ruupert Koponen
Title
Understanding re-emergence of the RPC model in web development
School School of Science
Degree programme Bachelor’s Programme in Science and Technology
Major Computer Science Code SCI3027
Supervisor Professor Lauri Savioja
Advisor Doctoral Researcher Juho Vepsäläinen
Level Bachelor’s thesis Date 3.5.2024 Pages 28 Language English
Abstract
RPC is a request-response protocol from the 1980s, which allows developers to
invoke remote functions from an application. It was originally used in distributed
systems, but was also used in web development in the late 1990s and early 2000s.
RPC’s popularity began decreasing after the REST-style architecture appeared in
the early 2000s. However, in the recent years, the RPC-model has re-emerged
in web development. This bachelor’s thesis focuses on understanding the recent
growth in popularity of the RPC model. In addition, this work explores the impact
of modern RPC frameworks on web development practices and offers comparison
between REST, RPC and GraphQL. This thesis is a literature review that utilizes
scientific articles, technological documentation and blog posts.
This study found out that in the early 2000s, web development moved from RPC
to REST architecture due to the low performance of RPC implementations at the
time. The internet was growing rapidly, requiring scalable and high-performance
web services, and REST answered to this demand. The 2010s saw new trends in
web development, such as microservices and TypeScript. These trends led to the
emergence of new RPC frameworks, such as gRPC and tRPC. These modern RPC
frameworks leverage advancements in network protocols, serialization formats,
and type systems to offer an alternative to the REST architectural style. gRPC is
especially popular in microservices systems due to its high performance, whereas
tRPC offers developers using TypeScript the ability to develop type-safe full-stack
applications. The RPC model has also been integrated into the popular front-end
framework React, which provides the ability to call server-side methods directly
from client-side components.
With the emergence of modern RPC frameworks, developers have more options
in web service development tools. Developers have access to more specialized
tools and can choose the one that best suits their needs. Although modern RPC
implementations may not be as universally applicable as REST or GraphQL, they
can offer significant benefits in certain types of applications. gRPC and tRPC
streamline the development of web services by offering an improved developer
experience. Additionally, they reduce the risk of errors through type safety.
Keywords API, GraphQL, gRPC, REST, RPC, tRPC
urn https://aaltodoc.aalto.fi
ii
Tiivistelmä
Aalto-yliopisto, PL 11000, 00076 Aalto www.aalto.fi
Tekijä
Ruupert Koponen
Työn nimi
RPC-mallin paluu web-kehityksessä
Korkeakoulu Perustieteiden korkeakoulu
Koulutusohjelma Teknistieteellinen kandidaattiohjelma
Pääaine Tietotekniikka Koodi SCI3027
Vastuuopettaja professori Lauri Savioja
Ohjaaja tohtorikoulutettava Juho Vepsäläinen
Työn laji Kandidaatintyö Päiväys 3.5.2024 Sivuja 28 Kieli englanti
Tiivistelmä
Etäproseduurikutsu (engl. Remote Procedure Call, RPC) on 1980-luvulta peräi-
sin oleva pyyntö-vastaus–protokolla, joka mahdollistaa palvelinpuolen funktioiden
kutsun suoraan asiakasohjelmasta. Sen alkuperäinen käyttökohde oli hajautetut
järjestelmät, mutta 1990-luvun lopussa ja 2000-luvun alussa sitä käytettiin myös
web-palveluiden kehityksessä. RPC:n käytöstä web-kehityksessä siirryttiin kuiten-
kin 2000-luvun alkupuolella REST-tyyliseen arkkitehtuuriin, joka on nykyäänkin
suosituin tapa toteuttaa web-palveluita. Tämä kandidaatintyö tarkastelee RPC-
mallin paluuta web-kehityksessä kahden suositun RPC-viitekehyksen, tRPC:n ja
gRPC:n näkökulmasta. Työn tavoitteena on löytää syitä, jotka ovat vaikuttaneet
RPC-mallin suosion kasvuun viime vuosina. Työ tarkastelee myös nykyaikaisten
RPC-viitekehyksien vaikutuksia web-kehityksen käytäntöihin sekä tarjoaa vertai-
lua RESTin, RPC:n ja GraphQL:n välillä. Tämä työ on kirjallisuustutkimus, jossa
hyödynnettiin tieteellisiä artikkeleita sekä teknologioiden dokumentaatioverkkosi-
vuja. Työssä esitellään myös RPC-viitekehyksiä koodiesimerkkien avulla.
Työssä huomattiin, että 2000-luvun alun web-kehityksessä siirryttiin RPC:stä
REST-arkkitehtuuriin senaikaisten RPC-toteutuksien alhaisen suorituskyvyn ta-
kia. Internet kasvoi nopeasti, joten tarvittiin skaalautuvia ja suorituskykyisiä
web-palveluita, ja REST vastasi kysyntään. 2010-luvulla web-kehityksessä ilmeni
uusia trendejä, kuten mikropalveluarkkitehtuuri ja tyypitetyt kielet, kuten TypeSc-
ript. Uusien trendien myötä ilmestyi myös uusia RPC-toteutuksia, kuten gRPC
ja tRPC. Nämä modernit RPC-toteutukset hyödyntävät verkkoprotokollien, seria-
lisointimuotojen ja tyyppijärjestelmien edistysaskelia tarjotakseen vaihtoehdon
REST-arkkitehtuurille. gRPC on suosittu erityisesti mikropalvelujärjestelmissä
suorituskykynsä ja laajan ohjelmointikielituen ansiosta, kun taas tRPC tarjoaa
TypeScript-kehittäjille keinon kehittää tyyppiturvallisia full-stack sovelluksia.
Modernien RPC-viitekehysten myötä kehittäjillä on enemmän valinnanvaraa web-
palveluiden kehitystyökaluissa. Kehittäjillä on käytössä entistä erikoistuneempia
työkaluja, ja he voivat valita tarpeisiinsa parhaiten sopivan työkalun. Vaikka mo-
dernit RPC-viitekehykset eivät välttämättä ole yhtä yleiskäyttöisiä kuin REST tai
GraphQL, voivat ne tarjota huomattavaa hyötyä tietyntyyppisissä sovelluksissa.
gRPC ja tRPC säästävät kehittäjän aikaa, sillä palvelimelta palautettua dataa ei
tarvitse erikseen validoida ja parsia. Tyyppiturvallisuus vähentää myös virhei-
den riskiä. Näin ollen tRPC ja gRPC voivat huomattavasti suoraviivaistaa web-
palveluiden kehitystä. Työn tulokset osoittavat, että modernien RPC-viitekehysten
käyttökelpoisuus on johtanut niiden suosion kasvuun.
Avainsanat API, GraphQL, gRPC, REST, RPC, tRPC
urn https://aaltodoc.aalto.fi
iii
Contents
Abstract ii
Tiivistelmä iii
Contents iv
1. Introduction 1
2. Early web services: From RPC to REST 3
2.1 Origins of RPC (1970-1980s) . . . . . . . . . . . . . . . . . . . 3
2.2 XML-RPC(1998) .......................... 4
2.3 SOAP(1999) ............................ 5
2.4 REST(2000)............................. 6
2.5 Transition from RPC to REST . . . . . . . . . . . . . . . . . . 7
3. Modern web services: From REST to RPC 10
3.1 OpenAPI(2011) .......................... 10
3.2 GraphQL(2015) .......................... 10
3.3 gRPC(2016)............................. 12
3.4 Performance of gRPC versus REST . . . . . . . . . . . . . . . 13
3.5 TypedRPC.............................. 14
3.6 tRPC(2021)............................. 15
3.7 Comparison between GraphQL, gRPC, and tRPC . . . . . . 17
3.8 RPC-like solutions . . . . . . . . . . . . . . . . . . . . . . . . . 18
4. Discussion 20
4.1 Suitability of modern RPC frameworks . . . . . . . . . . . . 20
4.2 WhoisRPCfor? .......................... 21
4.3 Community involvement . . . . . . . . . . . . . . . . . . . . . 21
4.4 FutureofRPC............................ 21
iv
Contents
4.5 Limitations in modern RPC solutions . . . . . . . . . . . . . . 22
5. Conclusion 23
Bibliography 25
v
1. Introduction
Web services need an Application Programming Interface (API) for commu-
nication between systems. The communication can happen e.g., between a
client and a server, where the client requests a resource from the server
and the server responds with the desired resource. Currently, the most
popular API design style in the web is REST [
1
]. However, an old protocol
called Remote Procedure Call (RPC) has recently been gaining popularity
[2, 3].
RPC is a request-response protocol that allows procedures or function
calls to be executed on a remote machine. It is a protocol that predates the
world wide web, with its first practical applications being in distributed
systems in the 1980s [
4
]. Since then, RPC has played a significant role
in the distributed computing world, with many implementations of the
protocol [5].
Starting from late 1990s and early 2000s, the RPC model was also used
for web-based applications when new innovations, such as SOAP and XML-
RPC gained popularity. However, the popularity of the RPC model in web
development was relatively short-lived, as its implementations and tooling
at the time had many challenges, and REST APIs gained popularity instead.
In his 2000 dissertation, Fielding [
6
] proposed a standardized architec-
tural style for the web, called Representational State Transfer (REST). It
made API development and usage simpler compared to RPC frameworks
from the 2000s, and large tech firms, such as eBay, Flickr, and Amazon
launched public REST APIs [
7
]. The REST APIs enabled the firms to extend
their product easily to other sites.
Since the mid-2000s, REST APIs have been the number one choice in
web API development. However, in the recent years, the RPC model has
re-emerged in web development due to improved tooling and frameworks.
Additionally, the popularity of the microservices architecture and typed
1
Introduction
languages has contributed to the popularity of current RPC tools.
The objective of this bachelor’s thesis is to learn why the RPC model
has re-emerged in web development. To understand why the model has
re-emerged, it is also necessary to examine its history and learn why its
popularity decreased in the 2000s. This thesis also examines how RPC is
used in the modern web and compares different frameworks. Other modern
web service design approaches are also discussed, such as GraphQL. This
thesis aims to answer the following questions:
RQ1:
What are the reasons for the RPC-model gaining popularity in web
development?
RQ2:
How does the re-emergence of RPC affect current web development
practices and what are its benefits?
This thesis will not address the modern usage of RPC outside of web
development, such as in some enterprise systems or in operating systems.
Furthermore, this thesis does not extensively analyze the speed or efficiency
of RPC versus REST, but rather focuses on the practical applicability.
The RPC protocol has been extensively studied starting from the 1980s,
so there is a lot of academic material on it [
4
,
8
,
9
,
10
]. However, the
most recent advancements regarding RPC web technologies lack academic
research, so for that part, this thesis utilizes blog posts, GitHub repositories
and documentation websites.
This thesis goes through the phases in web development in a chronological
order. Chapter 2 examines the functioning principles and history of RPC
and REST. Chapter 3 focuses on the modern era of web services and
introduces modern RPC frameworks, tRPC and gRPC. Chapter 4 discusses
the applicability of modern RPC frameworks and their potential impact
on the future of web services. Finally, Chapter 5 answers the research
questions and concludes the research.
2
2. Early web services: From RPC to REST
This chapter examines the historical evolution of web services, starting
with the inception of the RPC protocol. It explores how RPC functions and
its significance in early web services. Subsequently, the chapter examines
the emergence of REST in 2000 and reasons for the shift from RPC to
REST.
2.1 Origins of RPC (1970-1980s)
The concept of managing network operations as "remote procedure calls"
dates back to the 1970s, when Arpa’s Network Working Group worked
on resource sharing on the ARPA network [
11
,
12
]. The term ’remote
procedure call’ was later generalized by Bruce Jay Nelson in his dissertation
in 1981 [
4
]. Nelson [
4
, p. 9] defined RPC as the "synchronous language-
level transfer of control between programs in disjoint address spaces whose
primary communication medium is a narrow channel". He also identified
problems with prior RPC efforts and designed improved mechanisms in
theory.
The objective of RPC is to simplify the communication between programs
running on different computers within a network. It achieves this by
allowing a program to run a procedure on another machine, just as if it
were running it locally. RPC hides away the complexity of networking
protocols, enabling the programmer to focus on the programming rather
than dealing with the underlying complex protocols. In addition, the goal
of the early RPC implementations was to streamline the development of
distributed systems and make communication more efficient [8].
The process of a remote procedure call is visualized in Figure 2.1. The
process consists of five components: the client, the client stub, the server,
the server stub and RPC runtimes for both the client and the server [
8
]. The
3
Early web services: From RPC to REST
Figure 2.1. Simplified RPC mechanism
client makes a standard local call, which activates a process in the client
stub. The responsibility of the client’s stub is to package the details of
the requested procedure and its parameters into packets. It then requests
the RPC runtime to transmit these forward to the remote system. The
RPC runtime handles acknowledgments, encryption, packet routing and
retransmissions. The server’s runtime receives the packets and hands
them off to the server stub, which unpacks them and makes a local call to
the server program. The server handles the procedure and the results are
returned to the client. Returning the result follows the same pattern in a
reversed order.
2.2 XML-RPC (1998)
The RPC model started gaining traction in web development after the
release of XML-RPC in 1998, an RPC protocol that utilizes eXtensible
Markup Language (XML) to encode the calls and HyperText Transfer Pro-
tocol (HTTP) to transport the calls [
13
]. Similar to original RPC designs,
XML-RPC enabled developers to avoid writing networking code. In his
2003 article, Mark Allman [
14
] compared remote method invocation using
java.net and XML-RPC, and concluded that the java.net implementation
was approximately 50% more complex.
The power of XML-RPC was the support for multiple languages, such as
Python, Java and Perl, and the ability to connect systems that were written
4
Early web services: From RPC to REST
<?xml version="1.0"?>
<methodCall>
<methodName>multiplyNumbers</methodName>
<params>
<param>
<value><int>6</int></value>
</param>
<param>
<value><int>20</int></value>
</param>
</params>
</methodCall>
Figure 2.2. XML-RPC method call example
in different languages [
13
]. As a result of good language support and ease
of use, XML-RPC became a popular method of API communication in web
development in the early 2000s. XML-RPC also has its disadvantages, such
as poor network security [
13
] and no built-in encryption, leaving developers
responsible for incorporating these security measures. In addition, XML-
RPC messages are relatively verbose and heavy, as seen in Figure 2.2.
2.3 SOAP (1999)
One year after the release of XML-RPC, Microsoft released Simple Object
Access Protocol (SOAP) [
15
], which is based on XML-RPC. Figure 2.3
provides an example of data exchange between client and server. The
message is wrapped in a SOAP envelope, which consists of an optional
header and a required message body [
16
]. The header contains application-
defined information on how the message should be processed. The message
body contains the actual message, usually a function call. The server
responds to a client call with a SOAP envelope.
While XML-RPC is able to transfer only simple data types, SOAP enables
the transfer of objects. This makes SOAP more flexible than XML-RPC,
but also potentially more complex. Another advantage of SOAP is its
transport protocol independency, whereas XML-RPC relies on HTTP. The
disadvantage of both XML-RPC and SOAP is the packet size [
10
]. Both rely
on XML, which causes overhead and adds latency to package transmission.
5
Early web services: From RPC to REST
<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2003/05/soap-envelope/"
soap:encodingStyle="http://www.w3.org/2003/05/soap-encoding">
<soap:Body xmlns:m="http://example.com/math">
<m:MultiplyNumbers>
<int1>6</int1>
<int2>20</int2>
</m:MultiplyNumbers>
</soap:Body>
</soap:Envelope>
(a) Message
<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2003/05/soap-envelope/"
soap:encodingStyle="http://www.w3.org/2003/05/soap-encoding">
<soap:Body xmlns:m="http://www.example.com/math">
<m:MultiplyNumbersResponse>
<m:MultiplyNumbersResult>120</m:MultiplyNumbersResult>
</m:MultiplyNumbersResponse>
</soap:Body>
</soap:Envelope>
(b) Response
Figure 2.3. SOAP message and response
2.4 REST (2000)
In his dissertation in 2000, Roy Fielding [
6
] proposed a new architectural
style, the Representational State Transfer (REST), for designing distributed
network-based applications. Contrary to XML-RPC and SOAP, REST was
not a new technology, but rather a set of architectural guidelines to develop
network applications. Fielding’s goal was to design a framework that al-
lows high scalability as the web grew at a fast pace in the 2000s. Fielding’s
design includes a set of architectural constraints that a REST system must
fulfill: client-server model, statelessness, cache labels, uniform interface,
layered system, and an optional constraint, code-on-demand [
6
]. Conform-
ing to these constraints should result in a scalable, performant and easily
modifiable system.
A REST API utilizes HTTP verbs to send requests to the server [
17
].
The most commonly used HTTP verbs are
GET
,
POST
,
PUT
, and
DELETE
. The
6
Early web services: From RPC to REST
POST /users HTTP/1.1
Host: example.com
Content-Type: application/json
{
"name": "John Doe"
}
(a) HTTP request
HTTP/1.1 201 Created
Content-Type: application/json
{
"status": "User created"
}
(b) HTTP response
Figure 2.4. HTTP POST request and response
verbs describe the action that should be done. For example,
GET
requests a
resource from the server,
POST
sends a resource to the server, PUT updates
a resource on the server and DELETE deletes a resource from the server.
An HTTP request consists of a request line, header and an optional
message body [
17
]. Figure 2.4 is an example of a user creation by utilizing
the HTTP
POST
method. The request line contains the HTTP method, the
Uniform Resource Identifier (URI), which is a path to the resource on
the server, and the HTTP version. In Figure 2.4, the header contains
the Content-Type field, but it can also contain other information, such
as caching directives and date, for example. Finally, the message body
contains the data that is sent to the server. The server receives the request
and performs the requested task, and then responds with an HTTP status
code and an optional message body.
2.5 Transition from RPC to REST
In the early 2000s, the internet experienced rapid growth in terms of
users and websites. This growth required more scalable, flexible and
efficient web services. Many web services were built with an RPC-style
architecture, which was problematic. RPC-based web services faced many
issues, such as low performance, high complexity, tight coupling and poor
scalability. For instance, Amazon stated that their RESTful web services
are six times faster than their SOAP-based services [
18
]. The verbosity of
SOAP leads to large message sizes, which increases the transport time and
is especially problematic with slow internet speeds, which were common in
early 2000s. In contrast, REST utilizes HTTP for communication and allows
various data formats, allowing more compact messages. This efficiency is
vital for improving performance, especially in limited bandwidth networks.
To illustrate the differences between SOAP and REST clearly, Table 2.1
provides a side-by-side comparison of their key features.
7
Early web services: From RPC to REST
Feature SOAP REST
Data format XML [10]
JSON, XML, YAML,
HTML, etc. [19]
Communication phi-
losophy
Method-based [19] Resource-based [6]
Statefulness
Support for stateful
operations [19]
Stateless [6]
Transport
Protocol indepen-
dent [10]
HTTP [6]
Scalability
Difficult to scale [
19
]
Easy to scale [19]
Performance
Poor (large message
size) [19]
Faster (small mes-
sage size, HTTP
caching) [19]
Ideal use cases
Legacy applications
[19]
Public and private
APIs with clearly de-
fined resources
Language support Most languages All languages
Table 2.1. Comparison between SOAP and REST
RPC systems typically suffer from tight coupling between client and server.
They require both sides to maintain consistent configurations to operate
correctly [
18
], which complicates the integration of third-party services
and hinders flexibility and scalability. Furthermore, in RPC, data types
are bound to the interface, which is convenient for code generation but
increases dependency between systems. Changes in the data structures
require updates across all connected services [18].
In contrast, the uniform interface constraint of REST simplifies client-
server communication by utilizing HTTP methods (e.g.,
GET
,
POST
) to locate
and operate the resources. Unlike RPC, REST does not define the data
types directly in the interface. Instead, the data types can be defined in the
HTTP
Content-Type
header. This approach simplifies client-server interaction
and results in a more loosely coupled architecture compared to RPC APIs,
therefore increasing scalability and flexibility.
The shift from RPC to REST APIs during the early 2000s represents
a significant turning point in web services architecture, driven by the
rapid growth of the internet and its number of users. Limitations in RPC
technologies, such as complexity and scalability issues inhibited their large
scale use in the web. The REST architecture emerged as an alternative
that addressed the limitations of RPC and offered a more flexible, efficient
8
Early web services: From RPC to REST
and scalable solution. Furthermore, building REST APIs was simpler, less
expensive and more maintainable than RPC APIs [
20
]. The popularity of
REST has been steadily increasing since the early 2000s [
21
] and it is
currently the most widely used architectural style to develop APIs [
1
]. In
contrast, the popularity of RPC has been decreasing since the early 2000s,
apart from the most recent years.
9
3.
Modern web services: From REST to RPC
Despite being the most popular API design style, REST has its limitations.
This chapter introduces modern advancements in web service technologies
with focus on modern RPC frameworks, and discusses how they can address
the shortcomings of REST.
3.1 OpenAPI (2011)
A common problem in REST APIs is documentation, as it can be done in
numerous ways. An API may even lack documentation. Having bad docu-
mentation or no documentation at all is a serious problem. The consumer
of an API has to guess and manually investigate endpoints, responses and
valid requests. To address this problem, the Swagger specification was
released in 2011, and later renamed to OpenAPI in 2016 [22].
The OpenAPI Specification defines a standard interface description for
APIs. It describes available paths, valid requests, and formats to enable
developers and machines to understand how an API is supposed to work
[23].
3.2 GraphQL (2015)
GraphQL, a new challenger for REST-style APIs, was released and open-
sourced by Facebook in 2015 [
24
]. GraphQL is a query language for
declarative data fetching and mutation [
24
]. A client can precisely define
the wanted resources from a server. To make this possible, GraphQL utilizes
schemas that define data structures and types. The GraphQL functioning
principle can be seen from Figure 3.1. The
User
type has
id
,
name
and
email
fields. The client can request the desired fields (
name
and
email
), and the
server responds with the desired fields, omitting the id field.
10
Modern web services: From REST to RPC
type User {
id: String
name: String
email: String
}
(a) Schema
{
user {
name
email
}
}
(b) Request
{
"user" {
"name": "John Doe"
"email": "john@doe.com"
}
}
(c) Response
Figure 3.1. GraphQL schema, request and response
The declarative data fetching approach effectively prevents over-fetching,
which is common problem in REST APIs, where the server dictates the
content of the response. In REST APIs, a client request might result
in the server returning data fields that the client does not need. The
declarative data fetching approach of GraphQL leads to more efficient
network utilization and reduces the amount of processing the client has to
perform on the received data.
GraphQL also simplifies data fetching by providing a single endpoint
that can provide resources. In contrast, REST APIs typically have many
endpoints for different resources, leading to under-fetching. For instance,
when a client needs data on
users
and
posts
from a REST API, the client
would have to make requests to both
/users
and
/posts
endpoints. In the
case of GraphQL, the client would make only a single request to a single
endpoint, and receive a response containing all the required data.
A significant benefit of GraphQL is its type system, which ensures that all
data conforms to server-specified schemas. The GraphQL service publishes
the available operations and fields to the client, and the client chooses how
to consume them. The type system ensures that query errors, for example,
can be caught at development time [
24
]. In addition, the GraphQL schema
streamlines communication between back-end and front-end development
teams. The schema acts as a shared language, automatically providing
front-end developers the up-to-date specification of the data model and
available operations, similar to OpenAPI interface definitions.
The popularity of GraphQL has been steadily increasing since 2015 [
25
].
Many large companies, such as Facebook, GitHub, Pinterest and Shopify
use it for building their web services [26]. Vadlamani et al. [27] surveyed
38 GitHub software developers about REST and GraphQL in 2021. The
developers were asked about their opinions on both, as well as benefits
and weaknesses. The majority of developers (55%) perceived GraphQL
to make efficient resource requesting easier than REST. Some noted that
11
Modern web services: From REST to RPC
GraphQL services are unnecessary complex and difficult to learn compared
to REST. Nearly half (47%) of the developers thought that organizations
providing public REST APIs would benefit from migrating to GraphQL,
while 36% of the developers were neutral. The survey concluded that the
top benefits of REST are its mature tooling, widespread knowledge and
its easiness to learn, while the top benefits of GraphQL are reduced over-
and under-fetching, strongly typed protocol language and built-in type
validation [
27
]. Over half of the developers (57%) who participated in the
survey believed that GraphQL will see increased adoption over the next
five years [27].
3.3 gRPC (2016)
In 2016, Google released their RPC framework, gRPC [
28
]. gRPC is built for
connecting services in microservices architecture and connecting clients
to back-end services [
29
]. Microservices is an architectural style where an
application is divided into smaller, independent services that communicate
over a network [30].
gRPC is built on top of HTTP/2.0 and supports four types of client-server
communication: unary, server streaming, client streaming and bidirectional
streaming [
31
]. In unary communication, the client sends a single request
and the server returns a single response. In server streaming, the client
sends a single request and the server returns a stream of responses, mean-
ing that multiple messages are sent from the server. In client streaming
the client sends a stream of requests to the server and the server responds
with a single message. Finally, in bidirectional streaming, the client and
server can send multiple messages between each other.
gRPC utilizes language-neutral Protocol Buffers (protobuf) to serialize
structured data [
32
]. Messages and services are described in
.proto
files,
from which both client and server side code can be generated. The benefit
of using protobufs is the ability to use the same
.proto
files on different
systems, regardless of the programming language. Protobuf messages
are binary encoded, therefore the message size is small and message
transportation is fast.
Figure 3.2 presents a practical example of implementing a gRPC ser-
vice. The
.proto
file is the foundation of a gRPC service. When the
.proto
file is compiled, both server and client code are generated from it. The
MultiplierService
class extends the
MultiplierServiceBase
class, which is auto-
12
Modern web services: From REST to RPC
matically generated from the
.proto
file. The
MultiplierService
has to imple-
ment all methods that the
.proto
file defines. The client can easily call the
multiplyNumbers method that is defined in the MultiplierService class.
// The multiplier service definition.
service Multiplier {
// Method to multiply two numbers
rpc MultiplyNumbers (MultiplyRequest) returns (MultiplyReply) {}
}
// The request containing two numbers to be multiplied.
message MultiplyRequest {
int32 firstNumber = 1;
int32 secondNumber = 2;
}
// The response containing the result
message MultiplyReply {
int32 result = 1;
}
(a) .proto file
// MultiplierServiceBase is generated from the .proto file
class MultiplierService extends MultiplierServiceBase {
@override
Future<MultiplyReply> multiplyNumbers(ServiceCall call, MultiplyRequest req)
async {
return MultiplyReply()..result = req.firstNumber *req.secondNumber;
}
}
(b) Server code
final stub = MultiplierClient(channel);
final response = await stub.multiplyNumbers(MultiplyRequest()
..firstNumber = 2
..secondNumber = 5);
print(’Result of the operation: ${response.result}’);
// Result of the operation: 10
(c) Client code
Figure 3.2. gRPC example written in Dart
3.4 Performance of gRPC versus REST
An application consisting of microservices typically requires high-perfor-
mance transport between nodes. Bolanowski et al. [
33
] investigated the
performance differences between REST and gRPC in different tasks, such
as text cloning, getting integer value, fetching text files and downloading
PDF files. They found out that REST outperformed gRPC in text cloning
13
Modern web services: From REST to RPC
efficiency (REST at 4 ms compared to gRPC at 8 ms). However, the perfor-
mance was nearly identical for encoded text cloning, with REST at 22 ms
and gRPC at 21 ms. Similar results were observed in retrieving integer
values: REST was faster without encryption (4 ms vs gRPC’s 7 ms), but
with encryption, the difference was minimal (REST at 22 ms versus gRPC at
21 ms). Larger differences in performance could be noticed when handling
files. gRPC was quicker in fetching text files, taking 53 ms compared to
the REST service taking 57 ms. The difference was even larger when using
HTTPS; the gRPC service performed the task in 66 ms and REST in 75 ms.
Bolanowski et al. [
33
] note that the observed performance difference could
be caused by the fact that the REST service has to convert the bitstream
of the file into text form before transportation, while the gRPC service can
transfer the file to the client in its original form. Bolanowski et al. [
33
] also
compared the performance when downloading PDF files, and noticed that
gRPC was much faster at 361 ms versus REST at 416 ms. With encrypted
transfer, the performance difference was even larger, with gRPC at 370
ms and REST at 473 ms.
Performance in a high-traffic system consisting of microservices is critical.
When deciding between REST and gRPC for microservices, even small
differences in latency must be taken into consideration. In high-traffic
applications, poor latency can have a large impact on the whole system.
The impressive performance and streaming capabilities makes gRPC a
noteworthy alternative to REST. Some large companies, such as Cisco
and Netflix use gRPC in their services [
29
]. Netflix had problems with
their custom inter-service technology stack, which was based on HTTP/1.1
[
34
]. The stack required developers to write extensive custom code for
client-server interaction, lacked clear API descriptions and was prone to
errors [
34
]. Switching their technology stack to gRPC resulted in improved
latency, much less hand-written code, higher developer productivity, and
fewer bugs [34].
3.5 Typed RPC
TypeScript, a programming language that adds static typing to JavaScript,
has gained a lot of popularity during the last decade. Working with REST
APIs using TypeScript can be cumbersome, as type safety is lost. Data
validation and deserialization must be done in the client, resulting in extra
work for the developer. The need for type safety has resulted in many
14
Modern web services: From REST to RPC
new RPC frameworks for TypeScript, such as tRPC, TwirpScript, TSRPC
and typed-rpc. Table 3.1 compares GitHub metrics, npm installations and
community involvement regarding these frameworks. TwirpScript is an
implementation of Twirp, an RPC framework developed by Twitch [
35
].
TwirpScript utilizes protobufs to generate client and server code [
35
],
similar to gRPC. Typed-rpc is built on to of the JSON-RPC 2.0 protocol and
aims to be as simple and lightweight as possible, and it can be used with
any servers without the need for adapters [
36
]. TSRPC differs from the
rest by providing runtime type-checking [
37
]. As tRPC is the most popular
of the frameworks, this thesis will discuss it in a greater detail.
tRPC TwirpScript TSRPC
typed-
rpc
GitHub stars
32,546
[38]
120 [38]
1,742 [
38
]
96 [38]
npm installa-
tions (7.4.2024)
525,680
[38]
12,788 [38] 58 [38]
1,378 [
38
]
GitHub contrib-
utors
377 [39] 6 [35] 2 [37] 4 [36]
Latest commit
Apr 2024
[39]
Feb 2024 [35]
Dec 2023
[37]
Mar 2024
[36]
Table 3.1. Popularity statistics of TypeScript RPC frameworks as of 17.4.2024
3.6 tRPC (2021)
tRPC was released in 2021 [
40
] and is currently the most popular Type-
Script RPC framework [
38
]. tRPC provides end-to-end type safety by
allowing types to be shared directly between the client and server [
41
].
The server defines query, mutation and subscription procedures, which are
accessible by the client. Changes in the server-side code are immediately
reflected on the client side, which results in reduced type error risk and the
client and server always being in sync. To benefit from the main features
of tRPC, it must be used in a monorepo, which contains both back-end and
front-end code.
Figure 3.3 provides an example of a simple tRPC application. The appli-
cation includes a database of dogs, which the server has access to. The
available procedures are defined in the
appRouter
constant. The type of
procedure is also defined: the
list
procedure is a query procedure and
the
create
procedure is a mutation procedure. The client can call these
15
Modern web services: From REST to RPC
type Dog = {
id: number,
name: string,
owner: string,
}
(a) TypeScript type definition
const appRouter = router({
list: publicProcedure.query(async () => {
return await db.dog.findMany();
}),
create: publicProcedure
.input(z.object({ name: z.string(), owner: z.string()}))
.mutation(async ({ input }) => {
return await db.dog.create(input);
}
});
(b) tRPC server
await trpc.dog.create.mutate({ name: ’Lucy’, owner: ’John’});
await trpc.dog.create.mutate({ name: ’Max’, owner: ’Jane’ });
const dogs: Dog[] = await trpc.dog.list.query();
console.log(’Dogs: , dogs);
const firstDog: Dog | undefined = dogsList.at(0);
if (firstDog) console.log(‘First dog: ${firstDog.name} (id: ${firstDog.id})‘);
// Result:
// Dogs: [
// { id: ’1’, name: ’Lucy’, owner: ’John’},
// { id: ’2’, name: ’Max’, owner: ’Jane’ }
// ]
// Name of first dog: Lucy
(c) tRPC client
Figure 3.3. tRPC example. Server and database setup omitted.
16
Modern web services: From REST to RPC
procedures as if they were local functions. A significant benefit of this
approach is that the return values are typed. The client can directly access
the properties of the dog, without the need for JSON deserialization and
data validation.
While tRPC can significantly streamline the development process and
offer strong type safety, it is not a suitable solution for all applications.
Similar to older RPC tools, it suffers from tight coupling between client and
server. Therefore it is best suited for applications that do not require loose
coupling. Furthermore, tRPC is not recommended for services that have
third-party consumers, as the type information is not transferred outside
of the monorepo.
3.7 Comparison between GraphQL, gRPC, and tRPC
Table 3.2 compares different aspects of gRPC, gRPC, and GraphQL. The
most significant distinction between the RPC frameworks, gRPC, and tRPC,
and GraphQL is their approach to client-server communication. tRPC and
tRPC adopt the method-based communication style, where the client calls
remote functions as if they were local functions. GraphQL, on the other
hand, adopts a query-based strategy, allowing for flexible and declarative
data fetching. The main distinction between GraphQL and the other two
is its client-centric model where the client specifies exactly what data it
needs, as opposed to gRPC and tRPC where the returned data is dictated
by the functions in the server. In this aspect, gRPC and tRPC are closer to
REST than GraphQL.
gRPC and GraphQL have more mature ecosystems and are more widely
adopted than tRPC. Although gRPC can be used for browsers, its ideal use
case is in large-scale systems consisting of microservices. tRPC is intended
for monorepos that contain both server and client code and it only supports
TypeScript, which means that both the front-end and back-end must be
written in TypeScript. GraphQL is a more universal solution than gRPC
and tRPC, as it is language-agnostic and supports flexible queries.
GraphQL can potentially be much more complex than gRPC and tRPC.
The schema is the key aspect in GraphQL, and it can be difficult to design
a schema that is efficient. The schema designers must carefully consider
the relationships between objects to ensure efficient queries, avoiding
overly nested or complex query possibilities that can lead to decreased
performance. In contrast, gRPC and tRPC are simpler in terms of design.
17
Modern web services: From REST to RPC
Feature gRPC tRPC GraphQL
Data format Protobuf [31] JSON [42] JSON
Communication
philosophy
Method-based
[29]
Method-based
[41]
Query-based
[24]
Transport HTTP/2 [33] HTTP [42] Typically HTTP
Caching
Implementable
[43]
Supported [44]
Supported (via
globally unique
identifiers)
Ideal use cases
High-
performance
microservices
[29]
Monorepo ap-
plications with
no third-party
consumers [
45
]
Large APIs with
evolving data
requirements
Adoption
Widely adopted
in microser-
vices [29]
Growing in pop-
ularity [38]
Widely adopted
in web services
[26]
Language sup-
port
C/C++, C#,
Dart, Go, Java,
Kotlin, Node.js,
Objective-C,
PHP, Python,
Ruby [46]
TypeScript [
41
]
Language-
agnostic [24]
Table 3.2. Comparison between gRPC, tRPC, and GraphQL
It is more difficult to do things wrong in RPC when compared to GraphQL.
3.8 RPC-like solutions
Developers have begun to appreciate the many benefits of RPC, such as
type-safety and ease of use. Frameworks and tools have been developed
that incorporate aspects of RPCs, but are not "pure" RPC tools. TS-REST is
a library for building REST APIs with end-to-end type safety and consuming
them in an RPC-like manner on the client [
47
]. A contract must be defined
that contains available operations, as well as relevant information on the
operations, such as the HTTP method, path, response and body. TS-REST
might be a good solution for TypeScript teams with REST APIs wanting to
incrementally improve the type safety of their applications without fully
migrating to e.g. tRPC or GraphQL. Figure 3.4 provides an example of
implementing TS-REST.
The popular front-end framework, React, introduced Server Actions along
with Server Components in 2023 [
48
]. Server Actions are essentially re-
mote procedure calls intended for server-side data mutation. The simplicity
18
Modern web services: From REST to RPC
export const contract = c.router({
listDogs: {
method: ’GET’,
path: ’/dogs’,
responses: { 200: c.type<Dog[]>() },
},
});
(a) Contract
const router = s.router(contract, {
listDogs: async () => ({
status: 200,
body: await db.dog.findMany(),
}),
});
(b) Server
const client = initClient(contract, {
baseUrl: ’https://localhost:3000’,
baseHeaders: {},
});
const dogs: Dog[] = await client.listDogs();
(c) Client
Figure 3.4. TS-REST example
of Server Actions can be seen in Figure 3.5. The file that defines Server Ac-
tions must be marked with
’use server’
, and the function definitions are just
normal JavaScript/TypeScript code. The server functions can be directly
called from the client without the need for an API layer, as the framework
handles all networking and routing. Server Actions are currently supported
in Next.js [48], which is a popular React framework.
"use server"
const createDog = (dog: Dog) => db.dog.create(dog);
export { createDog };
(a) Server Action
"use client"
import { createDog } from "./serverActions"
const dog = await createDog({ name: "Goofy", owner: "Mickey" });
(b) Client program
Figure 3.5. React Server Action
19
4. Discussion
This chapter discusses important aspects regarding the modern RPC frame-
works, such as their suitability and limitations. This chapter also provides
speculation about the future of RPC, and discusses who RPC is for.
4.1 Suitability of modern RPC frameworks
The modern RPC frameworks that are discussed in this thesis are very use-
ful for certain applications. gRPC, with its high performance and diverse
streaming capabilities, is best suitable for systems with inter-service com-
munication, such as microservices. Thanks to the streaming capabilities,
gRPC is also good for real-time applications, such as chat applications. It
is also suitable for connecting devices and applications to back-end ser-
vices. gRPC can be used in web browsers, but it requires an additional
proxy to forward requests to the back-end. Additionally, out of the four
communication modes of gRPC, only unary RPCs and server-streaming are
supported in gRPC-web [49].
As tRPC is developed only for TypeScript, it can fully utilize TypeScript’s
extensive type system. Therefore it is suitable for web applications and
mobile applications where both the front-end and back-end are written
in TypeScript. A requirement in tRPC applications is that the client and
server code must reside in the same repository. Thus it is a great fit for
applications that are built by one team that handles both the front-end
and back-end. In conclusion, tRPC is a convenient framework for building
end-to-end type safe TypeScript applications.
20
Discussion
4.2 Who is RPC for?
I think that anyone, from beginners to professionals, can benefit from
trying out RPC in their projects. It is important to be aware of options
regarding API development, and RPC solutions can bring real value to a
project. Among the RPC frameworks examined in this thesis, tRPC stands
out as a paricularly beginner-friendly way to incorporate RPCs into an
application. It does not require code generation like gRPC does, making it
a straightforward and simple RPC framework for beginners to pick up.
4.3 Community involvement
Both gRPC and tRPC are open-source, which enables anyone to contribute
to their development and improvement. tRPC has 377 contributors on
GitHub [
39
], and the C-based gRPC version has 869 contributors [
50
].
Having a strong community behind a technology is crucial for the tech-
nology to succeed and gain popularity. The large number of contributors
behind tRPC and gRPC increases the probability that they will continue
being supported and developed. In addition, organizations may feel more
confident adopting a new technology if it is backed by a strong open-source
community.
4.4 Future of RPC
The future of RPC appears promising and filled with potential for further
innovation. The modern RPC frameworks will most likely evolve with the
future trends and demands of modern software development. At the time,
RPC seems like a trendy protocol that organizations want to try. However,
I suspect that RPC is not just a fad. Organizations have successfully used
gRPC in production and have noted significant benefits [
34
]. In addition,
there seems to be an interest for organizations to design their own RPC
systems, as Cloudflare has done [
51
]. With increasing adoption, RPC
seems to have secured its place in the web development field. Additionally,
with React Server Actions, an increasing number of web developers are
making remote procedure calls without necessarily realizing that they are
essentially using RPC.
21
Discussion
4.5 Limitations in modern RPC solutions
Although modern RPC solutions are powerful and innovative, they are not
as universally suitable as REST. For example, building an RPC API that is
intended to be consumed by third-party clients is not ideal, as the client
needs type information in tRPC or the
.proto
file in gRPC. tRPC is also
restricted by the programming language, as it supports only JavaScript
and TypeScript. gRPC, on the other hand, supports a wider range of
programming languages, but not all languages.
22
5. Conclusion
In this thesis, I sought to understand why the RPC model has re-emerged
in web development and found out that the main drivers behind this re-
emergence had to do with technological advancements and trends, such
as microservices and TypeScript. Advancements in networking and serial-
ization technologies has resulted in modern RPC implementations being
much more efficient when compared to the old implementations, such as
XML-RPC and SOAP. I investigated the advantages of using gRPC and tRPC
instead of REST, and found out that they can offer faster development time,
fewer errors and higher performance. gRPC is a great solution for the
microservices architecture, as it is efficient and has diverse streaming
capabilities. tRPC, on the other hand, is highly suitable for TypeScript full-
stack development, as it provides end-to-end type safety, which REST APIs
lack. In addition, developing a tRPC application can be more straightfor-
ward than a REST application, as it does not require as much architectural
planning.
One key insight from this thesis is the realization that no communication
model can be considered as universally superior. REST has been the
standard style to build web services for a long time, but modern RPC
solutions offer compelling alternatives. The choice between REST, GraphQL
and RPC ultimately depends on multiple factors, including the specific
requirements of the application, the experience level of the developers,
and the nature of the application. Web developers and organizations should
explore modern RPC frameworks and consider whether they can offer any
benefits for their projects.
23
Conclusion
There are still some interesting research questions open related to mod-
ern RPC solutions:
1.
What challenges do developers face when migrating a service to gRPC?
2.
What are the comparative cost implications of implementing RPC versus
REST in web services?
3. How much can RPC improve productivity when compared to REST?
In the end, it is clear that there most likely are many more reasons why
RPC has re-emerged, but this work has successfully investigated some of
the main factors behind it. It will be interesting to see whether modern
RPC technologies ever become as popular as REST or GraphQL.
24
Bibliography
[1]
Postman, “2023 State of the API Report,” 2023, [Accessed 19.3.2024].
[Online]. Available: https://www.postman.com/state-of-api/api-technologies/
#api-technologies
[2]
npm trends, “gRPC-js npm downloads,” [Accessed 8.2.2024]. [Online].
Available: https://npmtrends.com/@grpc/grpc-js
[3]
Stack Overflow, “Trends - SOAP vs gRPC,” [Accessed 8.2.2024]. [Online].
Available: https://insights.stackoverflow.com/trends?tags=soap%2Cgrpc
[4]
B. J. Nelson, “Remote Procedure Call,” Ph.D. dissertation, Carnegie Mellon
University, Pittsburgh, PA, 1981.
[5]
B. H. Tay and A. L. Ananda, A survey of remote procedure calls,” ACM
SIGOPS Operating Systems Review, vol. 24, no. 3, pp. 68–79, 1990. doi:
10.1145/382244.382832
[6]
R. T. Fielding, Architectural styles and the design of network-based software
architectures,” Ph.D. dissertation, University of California, Irvine, CA, 2000.
[7]
ReadMe, “The History of REST APIs,” 2016, [Accessed 8.2.2024]. [Online].
Available: https://blog.readme.com/the-history-of-rest-apis/
[8]
A. D. Birrell and B. J. Nelson, “Implementing remote procedure calls,” in
Proceedings of the Ninth ACM Symposium on Operating Systems Principles,
ser. SOSP ’83. New York, NY: Association for Computing Machinery, 1983,
p. 3. doi: 10.1145/800217.806609
[9]
S. Vinoski, “Putting the "Web" into Web services. Web services interaction
models.2,” IEEE Internet Computing, vol. 6, no. 4, pp. 90–92, 2002. doi:
10.1109/MIC.2002.1020331
[10]
B. Suda, “SOAP web services,” Master’s thesis, The University of Edinburgh,
Edinburgh, 2003.
[11]
J. E. White, “High-level framework for network-based resource sharing,”
1975. [Online]. Available: https://www.rfc-editor.org/info/rfc707
[12]
J. B. Postel and J. E. White, “Procedure Call Documents: Version 2,” 1974.
[Online]. Available: https://www.rfc-editor.org/info/rfc674
[13]
S. S. Laurent, J. Johnston, E. Wilder-James, and D. Winer, Programming Web
Services with XML-RPC: Creating Web Application Gateways. "O’Reilly
Media, Inc.", 2001. ISBN 978-0596001193
25
Bibliography
[14]
M. Allman, An evaluation of XML-RPC,” ACM SIGMETRICS performance
evaluation review, vol. 30, no. 4, 2003-03. doi: 10.1145/773056.773057
[15]
R. Cover, “Simple Object Access Protocol (SOAP),” 2003, accessed:
23.2.2024. [Online]. Available: https://xml.coverpages.org/soap.html
[16]
J. Snell, D. Tidwell, and P. Kulchenko, Programming web services with SOAP:
building distributed applications. "O’Reilly Media, Inc.", 2001. ISBN 978-
0596000950
[17]
IBM, “What is a REST API?” [Accessed 28.2.2024]. [Online]. Available:
https://www.ibm.com/topics/rest-apis
[18]
X. Feng, J. Shen, and Y. Fan, “REST: An alternative to RPC for Web services
architecture,” in 2009 First International Conference on future information
networks, 2009, pp. 7–10. doi: 10.1109/ICFIN.2009.5339611
[19]
Amazon, “What is the Difference Between SOAP and REST,” [Accessed
25.4.2024]. [Online]. Available: https://aws.amazon.com/compare/the-diffe
rence-between-soap-rest/
[20]
S. Vinoski, “RPC and REST: Dilemma, Disruption, and Displacement,”
IEEE Internet Computing, vol. 12, no. 5, pp. 92–95, 2008. doi:
10.1109/MIC.2008.109
[21]
Google, “Trends - REST vs. RPC,” [Accessed 1.3.2024]. [Online]. Available:
https://trends.google.com/trends/explore?cat=31&date=all&q=rest,rpc&
hl=en
[22]
Postman, “OpenAPI History,” 2024, [Accessed 19.4.2024]. [Online]. Available:
https://learning.postman.com/open-technologies/specifications/openapi/his
tory/
[23]
M. Darrel, J. Whitlock, M. Gardiner, R. Ratovsky, M. Ralphson, S. U,
J. Harmon, and T. Tam, “OpenAPI Specification v3.1.0,” 2021, [Accessed
29.4.2024]. [Online]. Available: https://spec.openapis.org/oas/latest.html
[24]
GraphQL Contributors, “GraphQL Current Working Draft,” 2024, [Accessed
5.3.2024]. [Online]. Available: https://spec.graphql.org/draft/
[25]
npm trends, “GraphQL npm downloads,” 2024, [Accessed 8.3.2024]. [Online].
Available: https://npmtrends.com/graphql
[26]
GraphQL Foundation, “GraphQL Foundation - GraphQL Landscape,” 2024,
[Accessed 8.3.2024]. [Online]. Available: https://landscape.graphql.org
[27]
S. L. Vadlamani, B. Emdon, J. Arts, and O. Baysal, “Can GraphQL replace
REST? a study of their efficiency and viability,” in 2021 IEEE/ACM 8th Inter-
national Workshop on Software Engineering Research and Industrial Practice
(SER&IP). IEEE, 2021, pp. 10–17. doi: 10.1109/SER-IP52554.2021.00009
[28]
V. Talwar, “gRPC: a true internet-scale RPC framework is now 1.0 and ready
for production deployments,” 2016, [Accessed 2.3.2024]. [Online]. Available:
https://cloud.google.com/blog/products/gcp/grpc-a-true-internet-scale-rpc
-framework-is-now-1-and-ready-for-production-deployments
[29]
gRPC Authors, About gRPC,” 2024, [Accessed 2.3.2024]. [Online]. Available:
https://grpc.io/about/
26
Bibliography
[30]
N. Dragoni, S. Giallorenzo, A. L. Lafuente, M. Mazzara, F. Montesi,
R. Mustafin, and L. Safina, “Microservices: yesterday, today, and tomor-
row,” Present and ulterior software engineering, pp. 195–216, 2017. doi:
10.1007/978-3-319-67425-4_12
[31]
gRPC Authors, “Core concepts, architecture and lifecycle,” [Accessed
2.3.2024]. [Online]. Available: https://grpc.io/docs/what-is-grpc/core-conce
pts/
[32]
Google, “Protocol Buffers Documentation,” [Accessed 2.3.2024]. [Online].
Available: https://protobuf.dev/overview/
[33]
M. Bolanowski, K. Żak, A. Paszkiewicz, M. Ganzha, M. Paprzycki, P. Sow-
iński, I. Lacalle, and C. E. Palau, “Eficiency of REST and gRPC realizing
communication tasks in microservice-based ecosystems,” arXiv preprint
arXiv:2208.00682, 2022.
[34]
Cloud Native Computing Foundation, “Case Study: How Netflix increased
developer productivity and defeated the thundering herd with gRPC,” 2018,
[Accessed 3.4.2024]. [Online]. Available: https://www.cncf.io/case-studies/n
etflix/
[35]
tatethurston, “TwirpScript,” 2024, [Accessed 21.3.2024]. [Online]. Available:
https://github.com/tatethurston/TwirpScript
[36]
fgnass, “Typed RPC,” 2024, [Accessed 21.3.2024]. [Online]. Available:
https://github.com/fgnass/typed-rpc
[37]
k8w, “tsrpc,” 2024, [Accessed 21.3.2024]. [Online]. Available: https:
//github.com/k8w/tsrpc
[38]
npm trends, “trpc/client vs trpc/server vs tsrpc vs twirpscript vs typed-rpc
downloads,” 2024, [Accessed 21.3.2024]. [Online]. Available: https://npmtre
nds.com/@trpc/client-vs-@trpc/server-vs-tsrpc-vs-twirpscript-vs-typed-rpc
[39]
tRPC, “trpc,” 2024, [Accessed 17.4.2024]. [Online]. Available: https:
//github.com/trpc/trpc
[40]
A. Johansson, “Introducing tRPC,” 2021, [Accessed 17.4.2024]. [Online].
Available: https://trpc.io/blog/introducing-trpc
[41]
tRPC, “Introduction,” 2024, [Accessed 15.3.2024]. [Online]. Available:
https://trpc.io/docs
[42]
——, “HTTP RPC Specification,” 2024, [Accessed 5.4.2024]. [Online].
Available: https://trpc.io/docs/rpc
[43]
gRPC Authors, “gRPC Documentation: Interceptors,” 2024, [Accessed
5.4.2024]. [Online]. Available: https://grpc.io/docs/guides/interceptors/
[44]
tRPC, “Response Caching,” 2024, [Accessed 5.4.2024]. [Online]. Available:
https://trpc.io/docs/server/caching
[45]
——, “Concepts,” 2024, [Accessed 5.4.2024]. [Online]. Available: https:
//trpc.io/docs/concepts
[46]
gRPC Authors, “gRPC Documentation,” [Accessed 2.3.2024]. [Online].
Available: https://grpc.io/docs/
27
Bibliography
[47]
TS-REST, “Introduction,” 2024, [Accessed 21.3.2024]. [Online]. Available:
https://ts-rest.com/docs/intro
[48]
J. Savona, J. Story, L. Tan, M. Chen, S. Susla, S. Gunasekaran,
S. Markbåge, and A. Clark, “React Labs: What We’ve Been Working
On - March 2023,” 2023, [Accessed 22.3.2024]. [Online]. Available:
https://react.dev/blog/2023/03/22/react-labs-what-we-have-been-working
-on-march-2023#react-server-components
[49]
I. Douglas, “Can gRPC replace REST and WebSockets for Web Application
Communication?” 2023, [Accessed 19.4.2024]. [Online]. Available:
https://grpc.io/blog/postman-grpcweb/
[50]
grpc, “gRPC,” 2024, [Accessed 19.4.2024]. [Online]. Available: https:
//github.com/grpc/grpc
[51]
K. Varda, “We’ve added JavaScript-native RPC to Cloudflare Workers,”
[Accessed 26.4.2024]. [Online]. Available: https://blog.cloudflare.com/javas
cript-native-rpc
28
ResearchGate has not been able to resolve any citations for this publication.
Chapter
Full-text available
The aim of this contribution is to analyse practical aspects of the use of REST APIs and gRPC to realize communication tasks in applications in microservice-based ecosystems. On the basis of performed experiments, classes of communication tasks, for which given technology performs data transfer more efficiently, have been established. This, in turn, allows formulation of criteria for the selection of appropriate communication methods for communication tasks to be performed in an application using microservices-based architecture.
Chapter
Full-text available
Microservices is an architectural style inspired by service-oriented computing that has recently started gaining popularity. Before presenting the current state-of-the-art in the field, this chapter reviews the history of software architecture, the reasons that led to the diffusion of objects and services first, and microservices later. Finally, open problems and future challenges are introduced. This survey primarily addresses newcomers to the discipline, while offering an academic viewpoint on the topic. In addition, we investigate some practical issues and point out some potential solutions.
Article
The Remote Procedure Call (RPC) is a popular paradigm for inter-process communication (IPC) between processes in different computers across the network. It is widely used in various Distributed Systems. Although it is conceptually simple and straightforward to implement, there are a lot of different and subtle issues involved which result different RPC implementations. In this paper, various distinctive RPC implementations are surveyed, analyzed and compared: Xerox Courier RPC, Xerox Cedar RPC, Sun ONC/RPC, Apollo NCA/RPC, Cambridge Mayflower Project RPC, MIT Athena Project RPC, Stanford Modula/V RPC, and Rajdoot RPC are presented. The design objectives, features provided, call semantics, orphan treatment, binding, transport protocols supported, security/authentication, data representation and application programming interface of these RPCs are examined.
Conference Paper
Currently most Web services architectures adopt RPC as their architectural style. But because of the complexity of RPC, there are bottlenecks of RPC-style Web services in Web-scale applications. REST not only can make full use of Web features, but also has the advantage of simplicity. So REST becomes a new alternative to RPC for Web services architecture. In this paper, at first the brief introductions of RPC and REST are provided. Then two kinds of architectural styles are analyzed and compared from the perspectives of scalability, coupling, and security. In the end the development trend of Web services architecture is prospected.
Conference Paper
This paper proposes a high-level, application-independent framework for the construction of distributed systems within a resource sharing computer network. The framework generalizes design techniques in use within the ARPA Computer Network. It eliminates the need for application-specific communication protocols and support software, thus easing the task of the applications programmer and so encouraging the sharing of resources. The framework consists of a network-wide protocol for invoking arbitrary named functions in a remote process, and machine-dependent system software that interfaces one applications program to another via the protocol. The protocol provides mechanisms for supplying arguments to remote functions and for retrieving their results; it also defines a small number of standard data types from which all arguments and results must be modeled. The paper further proposes that remote functions be thought of as remotely callable subroutines or procedures. This model would enable the framework to more gracefully extend the local programming environment to embrace modules on other machines.