Grpc Layer for Content Delivery in Kentico Kontent

Masaryk University Faculty of Informatics

gRPC Layer for Content Delivery in Kentico Kontent

Master’s Thesis

Bc. Petra Rebrošová

Brno, Spring 2021

Masaryk University Faculty of Informatics

gRPC Layer for Content Delivery in Kentico Kontent

Master’s Thesis

Bc. Petra Rebrošová

Brno, Spring 2021

This is where a copy of the official signed thesis assignment and a copy ofthe Statement of an Author is located in the printed version of the document.

Declaration

Hereby I declare that this paper is my original authorial work, which I have worked out on my own. All sources, references, and literature used or excerpted during elaboration of this work are properly cited and listed in complete reference to the due source.

Bc. Petra Rebrošová

Advisor: Bruno Rossi, PhD.

Acknowledgements

First of all, I would like to thank my advisor Bruno Rossi, Ph.D. for his guidance, patience, providing valuable feedback and advice during the writing of this thesis. Secondly, I would like to thank my consultant Petr Švihlík for his advice and help with technical issues. Furthermore, I want to express my gratitude to my family, friends, and colleagues from Kentico for their unconditional support, patience, motivation and always being there for me. Finally, I would like to thank my partner Jakub for his support and always standing by me.

iii Abstract

Remote Procedure Calls (RPCs) have been popular throughout the history of machine-to-machine network communication from its beginning. gRPC protocol is a new concept of RPC invented by Google, which promises more efficient messages and their faster transfer. Ken- tico Kontent, as a Content Management System (CMS), can benefit from the utilization of gRPC in alternative content delivery to its current APIs. Because Kentico Kontent is widely used and it is essential to provide as fast data transfer between client applications and Kontent as possible, it is important always to search for alternative solutions that would improve content delivery. The goals of this thesis are to analyze gRPC in line with relevant studies and documentation and evaluate it using Goal Question Metric (GQM) methodology. The results show that gRPC excels in scenarios where mobile or IoT application acts as a client, that can be also used in the omnichannel content delivery scenarios viable for Kontent. After that, a gRPC content delivery layer was designed and built as an alternative endpoint for Kontent’s Delivery API, within a sample mobile application processing the data from the implemented gRPC API endpoint. Results of the analysis prove that gRPC significantly reduces size of the messages. In scenarios with a large payload the gRPC messages are faster than the originally used HTTP messages, however, it does not apply for messages with a small payload.

iv Keywords

gRPC, Kentico Kontent, Content Management System, Protocol Buffer, API, .NET, REST

Contents

1 Introduction 3 1.1 Problem Statement ...... 3 1.2 Thesis Goals ...... 4 1.3 Thesis Structure ...... 5

2 Delivering Content in Kentico Kontent 7 2.1 Content Management System ...... 7 2.1.1 Headless CMS ...... 7 2.2 Software Delivery ...... 9 2.2.1 Software-as-a-Service Paradigm ...... 9 2.2.2 Content-as-a-Service Paradigm ...... 9 2.3 Omnichannel vs. Multichannel Approach ...... 10 2.3.1 Multichannel approach ...... 10 2.3.2 Omnichannel Approach ...... 10 2.4 Content Delivery in Kentico Kontent ...... 10 2.4.1 APIs ...... 11 2.4.2 SDK ...... 13 2.4.3 Delivered Data Structures ...... 14 2.5 Possible Improvements for Content Delivery ...... 15 2.6 Summary ...... 15

3 Remote Communication 17 3.1 History of Remote Communication ...... 17 3.1.1 Beginnings of Networks and Remote Commu- nication ...... 17 3.1.2 World Wide Web ...... 19 3.1.3 Web 1.0 ...... 20 3.1.4 Web 2.0 ...... 20 3.1.5 Web 3.0 ...... 20 3.1.6 Web 4.0 and the Future of Web ...... 21 3.2 Remote Communication Protocols and Frameworks ..... 21 3.2.1 REST ...... 21 3.2.2 HTTP ...... 21 3.2.3 RPC ...... 23 3.2.4 gRPC ...... 23

vii 3.3 Summary ...... 24

4 gRPC 25 4.1 Comparison of gRPC and REST ...... 25 4.2 Design ...... 25 4.2.1 Network Communication Principle ...... 26 4.2.2 Types of Communication ...... 26 4.2.3 Error Handling ...... 28 4.3 Usability of gRPC ...... 29 4.3.1 Microservices ...... 29 4.3.2 Web Applications and Websites ...... 29 4.3.3 Mobile Applications ...... 30 4.3.4 IoT and Embedded Systems ...... 31 4.4 Requirements and Principles ...... 32 4.5 Performance ...... 33 4.5.1 Battery Consumption ...... 34 4.5.2 Speed of the Requests ...... 34 4.6 Security ...... 35 4.6.1 Authentication ...... 35 4.6.2 Vulnerabilities ...... 36 4.7 Reliability ...... 37 4.8 Developer Experience ...... 37 4.9 gRPC Utilization in Implementation ...... 40 4.9.1 Protocol Buffer ...... 40 4.9.2 Data Serialization and JSON Mapping ...... 41 4.9.3 Network Communication ...... 43 4.10 Summary ...... 43

5 gRPC Analysis 45 5.1 The Goal Question Metric Approach ...... 45 5.2 Stated GQM ...... 45 5.3 Evaluation of the Stated GQMs ...... 47 5.3.1 G1: Analyze and find the most suitable types of applications for gRPC protocol, viable for omnichannel content delivery...... 48 5.3.2 G2: Show performance benefits of using gRPC in comparison with HTTP...... 50 viii 5.3.3 G3: Show Developer experience (DX) benefits of utilizing gRPC ...... 51 51subsection.5.3.4 5.4 Summary ...... 53

6 gRPC Layer for Kentico Kontent 55 6.1 Migration from REST Architecture to gRPC ...... 55 6.2 Design of gRPC Content Delivery Layer in Kentico Kontent 56 6.2.1 Models ...... 56 6.3 API Implementation Details ...... 56 6.4 Server Application Run ...... 57 6.5 Client Application ...... 57 6.6 Experiments ...... 59 6.6.1 Server Device Details ...... 59 6.6.2 Measurements ...... 59 6.7 Analysis of gRPC Integration into Kentico Kontent Deliv- ery API ...... 61 6.7.1 Stated GQM ...... 61 6.7.2 Evaluation of the Stated GQMs ...... 62 6.7.3 Conclusion of the Analysis of the Experimental Work...... 63 6.8 Summary ...... 63

7 Conclusion 65 7.1 Results of the Thesis Goals ...... 65 7.2 Future Work ...... 66

Bibliography 67

A Electronic Attachments 75

B Utilized Tools and Configurations 77 B.1 C# Implementation of gRPC API ...... 77 B.2 Client Android Application ...... 77 B.3 API Testing ...... 78

C Sample Code 79 C.1 items_service.proto ...... 79

ix D Mobile Application Details 81 D.1 Application Screenshots ...... 82

x List of Tables

4.1 REST HTTP API and gRPC API overview (based on comparison from [46]) 39 5.1 Evaluation of GQM metrics for G1 49 5.2 Average times of gRPC and HTTP messages 50 5.3 Evaluation of GQM metrics for G3 52 5.4 Evaluation of GQM metrics for G4 53 6.1 Size of gRPC and HTTP requests and responses containing 10, 100, or 500 items retrieved from GetItems endpoints 60 6.2 Median of the measured speed of responses containing 10, 100, or 500 items retrieved from gRPC and HTTP GetItems endpoints 60

List of Figures

1.1 Thesis structure with highlighted thesis goals 4 2.1 Headless CMS structure, adapted from [5] 8 2.2 Kentico Kontent public APIs structure 12 4.1 Structure of gRPC on HTTP/2 27 5.1 Scheme of GQM approach 46 6.1 Structure of gRPC and HTTP Kentico Kontent Delivery API communicating locally with client mobile application 58 6.2 Comparison of execution times of gRPC and HTTP messages 61 D.1 Main screen of the implemented Android application 82 D.2 Screen of the implemented Android application displaying data from gRPC and HTTP GetItems endpoints 83

xiii

Acronyms

6LoWPAN IPv6 over Low-Power Wireless Personal Area Networks.

ALTS Application Layer Transport Security.

API Application programming interface.

CaaS Content-as-a-Service.

CDN Content delivery network.

CMS Content Management System.

CRM Customer Relationship Management.

CVSS Common Vulnerability Scoring System.

DX Developer experience.

ERP Enterprise Resource Planning.

ESP Extensible Server Proxy.

FTP File Transfer Protocol.

GQM Goal Question Metric. gRPC gRPC Remote Procedure Calls.

HTTP HyperText Transfer Protocol.

IaaS Infrastructure-as-a-Service.

IDL Interface Definition Language.

IoT Internet of Things.

IP Internet Protocol.

IXP Internet exchange point.

1 Acronyms

JWT JSON Web Token.

LWM2M OMA Lightweight M2M.

MQTT Message Queuing Telemetry Transport.

NVD National Vulnerability Database.

PaaS Platform-as-a-Service.

QoS Quality-of-Service.

REST Representational state transfer.

RFID Radio-frequency identification infrastructure.

RPC Remote Procedure Calls.

SaaS Software-as-a-Service.

SDK Software development kit.

SLA Service-level agreement.

SSL/TLS Secure Sockets Layer/Transport Layer Security.

TCP Transmission Control Protocol.

TLS Transport Layer Security.

2 1 Introduction

In today‘s world, the number of electronic devices around us increases every day and a huge amount of data is stored and sent through the network. These devices communicate with us or with each other, they process, share or display the data. When analyzing services and applications according to their toler- ance for data loss, need for high-speed, etc., different kinds of services have different demands. There is also a difference in requirements of web, mobile, or IoT applications. A number of communication frameworks and protocols guaranteeing the fulfillment of the specific demands increase. Redesign of the product architecture or utilization of new protocols and frameworks may bring an opportunity for enhancement, for example in the speed of the message exchange in the communication. Kentico Kontent as Content Management System (CMS) is one of several approaches to managing and providing data. For CMS it is not important only to manage and store data, but also provide data to the various systems and applications reliably and with as minimal network latency as possible [1]. One of new concepts of the old approach known as Remote Pro- cedure Calls (RPC) is gRPC invented by Google [2]. This framework brings a promise of more efficient messages and their faster transfer, that can be an enhancement for the communication between Kentico Kontent APIs and some of the requesting clients.

1.1 Problem Statement

gRPC, as a new concept, may bring an opportunity for enhancement in content delivery. Because the communication between Kentico Kon- tent and client applications must be fast, reliable, and secure, it is important to analyze and have a deeper knowledge of the requirements of an alternative content delivery endpoint. It is also essential to benchmark gRPC API and the original HTTP API to bring an answer, whether it brings expected benefits.

3 1. Introduction 1.2 Thesis Goals

In relation to the discussed problems, the main goal of this thesis is to verify the viability and suitability of gRPC for the integration into the Kentico Kontent‘s Delivery API and to build gRPC layer for alternative content delivery. In order to achieve the main goal, this thesis focuses on 3 analysis and design-oriented sub-goals as follows:

∙ Goal 1: Analyze various aspects of gRPC in view of performance, security, reliability, developer experience for different target channels (web, IoT, mobile, etc.) and show scenarios where gRPC excels.

∙ Goal 2: Propose design and implementation of an alternative content delivery layer for Kentico Kontent Delivery API.

∙ Goal 3: Analyze implemented Kentico Kontent‘s gRPC Delivery API.

The thesis goals and chapters dealing with these goals are highlighted in the diagram of the thesis structure in Figure 1.1.

Figure 1.1: Thesis structure with highlighted thesis goals

4 1. Introduction 1.3 Thesis Structure

This thesis is structured into 7 chapters. Chapter 1 introduces the outline and problem this thesis deals with by giving answers to the thesis goals. Chapter 2 provides an overview of Kentico Kontent, the keywords, paradigms, and various approaches in content delivery. The history of remote communication and the most commonly used communication protocols are described in Chapter 3. Chapter 4 introduces gRPC protocol as a new way of remote communication. The following Chapter 5 analyzes gRPC protocol and also gives an answer to the thesis Goal 1. Utilization of the gRPC protocol in the design and implementation of content delivery in Kentico Kontent is discussed in Chapter 6. Experiments, analysis, and evaluation of the results of the utilization are also included in this chapter. Moreover, the chapter includes evaluation of Goal 2 and Goal 3. The last Chapter 7 concludes this thesis, presents its findings, and proposes further steps inthe future that may improve the current implementation.

2 Delivering Content in Kentico Kontent

Kontent, a product of Kentico company, is a tool allowing people to create, manage and deliver content to their customers in online space, which is assigned to a class of Headless CMS products. This system is designed for better content handling not only for marketers, but also developers, providing multiple Application programming interfaces (APIs) for a more comfortable way of manipulation with the content. Kontent is a web application implemented mostly in C# and Re- act.js, hosted as a cloud-based service, so there is no need to install any application or updates. For deployment and management Azure services are used, furthermore, releases of new features are delivered continually (there are no versions of the product, releases are sim- ply published periodically). This tool allows developers to integrate existing technologies and build sites using various languages, tools, and frameworks of their choice. It also comes with several Software development kits (SDKs), secured access to API, and SLA-guaranteed uptime (Service-level agreement guarantee). This chapter explains in detail the most important keywords and statements describing the product and the options how Kontent delivers desired content to the customers.

2.1 Content Management System

Content Management System (CMS) is a software or a group of related programs for the management of digital content. There are two services provided by CMS - content management application and content delivery application. Main functionality covers searching and data retrieval, content management, revision control, and finally publishing [3].

2.1.1 Headless CMS Headless property of CMS resolves flexibility problems of monolithic CMS systems. The system provides exclusively decoupled content, that is usually provided by a service hosted on a cloud and accessible by REST APIs [4]. The user interface (UI) and tools for its design

7 2. Delivering Content in Kentico Kontent and creation depend only on the user of the CMS service and can be adapted for a variety of device displays. Headless CMS solves only technical limitation, therefore Kentico came up with the idea of using Content-as-a-Service (CaaS), that is described in section 2.2.2. The structure of Headless CMS is illustrated in Figure 2.1, where the bottom part represents headless CMS (Kentico Kontent application) and the upper represents custom client’s side, its code and end application displayed on and adapted for various devices.

Figure 2.1: Headless CMS structure, adapted from [5]

However Kontent is a headless CMS, it has a new feature released in 2020, called Web Spotlight. This new tool enables customers to use all the headless CMS advantages with new features included, such as page preview, their live-editing, and page tree navigation with homepage and its subpages, that reminds of a traditional CMS [6].

8 2. Delivering Content in Kentico Kontent 2.2 Software Delivery

Besides common and essential models of software delivery in the cloud services, such as Platform-as-a-Service (PaaS), Software-as-a- Service (SaaS) and Infrastructure-as-a-Service (IaaS), there was found a new approach, called Content-as-a-Service (CaaS). Kentico Cloud (previous version of Kentico Kontent before rebranding) was defined as a SaaS model, although, Kentico Kontent is defined as CaaS and centralizes work with content.

2.2.1 Software-as-a-Service Paradigm Software-as-a-service (SaaS) is a concept of software delivery, that is also known as a cloud application service. In this approach, the customer uses the application, such as Customer Relationship Man- agement (CRM) or Enterprise Resource Planning (ERP) system, that is usually hosted off-premise and delivered by web, so the application does not require any installations or software maintenance - everything is carried out by SaaS provider [7, 8]. This approach also facilitates subscription payment model (cost is set according to customer’s requirements and the software is rented for some time period), which differs from a traditional buying of a software license [9].

2.2.2 Content-as-a-Service Paradigm Content-as-a-Service (CaaS) is a new more holistic and versatile concept for content management, that extends classic SaaS (Software-as- a-Service) model previously described in section 2.2.1 and focuses on the scaling of content strategy. It provides collaboration (e.g. different teams) and automation of all the operations with the content, from content creation, tracking, management of the whole content lifecycle, to the delivery to the end customer. It represents a solution for users and companies using multiple different CMSs along with ERP, CRM, and other similar systems for their content handling [10, 11]. Unlike the conventional approach of CMSs, CaaS systems are not oriented to web pages, but to the provided content itself, which makes it "portable" - able to be processed by other systems and applications [12]. CaaS allows users to model the content according to their needs

9 2. Delivering Content in Kentico Kontent and makes it possible for them to make changes in their application‘s design, as the content is separated from the user interface solution. It means the user creates one model and reuses it making multiple variants, for example for various languages [13]. All content, no matter what kind of content it is and who has created it, is available in one unified environment. Content is structured in content models. This property allows re- usability and flexibility of content.

2.3 Omnichannel vs. Multichannel Approach

2.3.1 Multichannel approach This approach gives a customer the chance to choose a channel of his preference. Various channels work independently from each other. An example of this approach is a company selling goods on their company website, but also by e-commerce marketplace such as Amazon, Facebook’s store and shoppable Instagrams’s posts [14, 15].

2.3.2 Omnichannel Approach The omnichannel approach, in a view of content delivery, puts the customer to the center, not the product. As the customer switches between multiple channels based on context and convenience, this approach suggests the specific content to specific channels for the user. For the illustration, an example of such an approach is when a customer sends a request on the website, he can check the response received by email in his email box without any need to open the website again. We can call it "single customer experience" [11, 14]. Kentico Kontent is an example of the omnichannel approach. For instance, when a user mentions another user in a comment, the second user receives an email and can see details without any need to open Kontent as an application.

2.4 Content Delivery in Kentico Kontent

As described in previous sections, Kentico Kontent is a headless CMS designed as an omnichannel Content-as-a-Service (CaaS) solution for

10 2. Delivering Content in Kentico Kontent

delivering content by its APIs to the customer. This section focuses on the kind of data stored and provided by Kentico Kontent and the way the data are delivered to a customer.

2.4.1 APIs

As mentioned before, Kontent is a headless CMS, where the user is able to create content and connect it to his own front-end implemented without any restrictions. Except internal APIs managing various kinds of information and delivering data to the application front-end, there are a few APIs providing endpoints for sharing content to the user’s application. The most important for the communication between Kon- tent and user’s application is Delivery API providing structured data [16]. All requests to the API must be secure using HTTPS protocol with Transport Layer Security (TLS) version 1.2. All available Kontent APIs are [17]:

∙ Delivery API - delivers content to the user‘s application.

∙ Management API - allows customers to migrate content a make updating operations.

∙ Custom Elements API - enables creation of own custom elements.

∙ Smart Recommendation API (currently in Beta version) - provides personalized recommendation for users of customer‘s application.

For a better illustration, the structure of public Kentico Kontent Delivery and Content Management API (CM API) is described in the diagram in Figure 2.2.

11 2. Delivering Content in Kentico Kontent

Blue arrows display current Delivery API calls, red arrow displays gRPC Delivery calls implemented in this thesis. Dashed red arrows display possible improvement of gRPC calls using Fastly CDN. Figure 2.2: Kentico Kontent public APIs structure

Delivery API The Delivery API is a REST API accessible in a read-only mode, using HTTP protocol for communication. In delivery API, depending on the request endpoint, both published (also called "live") items for the general audience and unpublished (also called "preview") items can be gathered using the same method, but with different URL base and the request has to be authorized. For better granularity in results, it is possible to use filtering with multiple query parameters. A typical scenario of filtering is using a codename parameter1. A limit and skip number may be specified for pagination of result to specify order result items. There are several SDKs for Delivery API, however, no SDK is required to use this API [16].

1. A codename identifier is initially generated from the object’s name whenthe object is saved for the first time, however, it can be later specified by the user[18].

12 2. Delivering Content in Kentico Kontent

Management API The Management API, currently of version 2, is a secure (using TLS 1.2) REST API, which provides access to Kentico Kontent projects. There is a limit of API calls (by default 10 requests/second, 400 requests/minute, 15000 requests/hour) and the requests are not cached. Compared to the Delivery API, Management API provides read and also write operations, Delivery API provides only data retrieval operations. It also allows users to migrate their own content to the Kontent project. Write operations can be made only on unpublished content items, it is not possible to change published ones - so the user has to create a new version of the content item which can be changed afterward [19]. There is also a SDK to help the user to interact with the Manage- ment API.

CDN Content delivery network (CDN) is a geographically distributed network consisted of servers (also called Internet exchange point (IXP)) which communicate together in order to improve website load times, cache content (such as images, GIFs, and front-end CSS and Javascript code files) and so optimize the amount of data provided by the origin server. Thanks to this technology, the user communicates with the geologically closest node of the CDN network and decreases latency in the communication [20]. In order to make the content quickly available worldwide without latency, Delivery API also caches the data by using CDN.

2.4.2 SDK Software Development Kit (SDK) is a set of tools, such as libraries, documentation, guides, and code samples with an aim to make work with the system more comfortable and user-friendly [21]. In order to help the customers, Kentico developed a few SDKs in various programming languages that are preferred in customers‘ end applications consuming the API‘s endpoints. The SDKs are supported for languages and frameworks such as JavaScript, .NET, PHP, Java, Ruby, and iOS.

13 2. Delivering Content in Kentico Kontent

2.4.3 Delivered Data Structures

In this section, the most used models delivered and managed by APIs are described.

Content Type

Content type is reusable and defines structure of the content of the delivered entity. It can also be modular and composed of more content types - both required and optional in the resulting entity [11]. The structure of content type is defined by distinct parts called content elements.

Content Item

Content item is digital data delivered to the customer. Its structure is based on the content type [11]. Content item object contains required parameters such as id, name, codename (by default generated from item‘s name), language, type, and date-time of the last modification [16].

Content Element

Every content item or content type includes a collection of content elements composing its content. These elements are distinct parts described by type, name, and value properties, moreover, some of them, e.g. assets and taxonomies, are described with more properties. The types of elements can be for example Assets, Multiple choice elements, Rich text elements, Taxonomy elements, etc [16].

Taxonomy

Taxonomy groups are terms representing categorization, that can be used also for the classification of content items. They connect an item with specific metadata, such as a specific tag for the given content item [16, 11].

14 2. Delivering Content in Kentico Kontent 2.5 Possible Improvements for Content Delivery

A possible improvement for content delivery API is to find and use new frameworks and protocols convenient for particular scenarios. One of the common reasons customers choose Kontent as their CMS is a possibility of managing content and serving it to their mobile application. An enhancement for Kentico Kontent Delivery API may be an alternative gRPC framework endpoint, that would optimize delivering content to mobile applications and would coexist with the current De- livery API endpoints. gRPC utilization promises faster communication and more efficient messages. gRPC utilization in the client application may have also an influence on the battery consumption of the mobile phone. Properties of the mentioned framework are described in detail later in Chapter 4.

2.6 Summary

In this chapter, various content delivery approaches and paradigms of CMS were described. An emphasis was placed on Kentico Kontent, its APIs, and also key terms describing content delivery. The following Chapter 3 summarizes history of the remote communication and describes the most used protocols nowadays.

3 Remote Communication

In this chapter, history of the remote communication pointing to its importance and evolution is discussed. The most used protocols of the application layer with their characteristics are discussed and gRPC - a key framework of this thesis - is introduced. Looking at the highest - application - ISO/OSI model layer, there are many protocols, systems, frameworks, and query languages providing client-server based interaction with a variety of properties suitable for various scenarios. Besides traditional HyperText Transfer Protocol (HTTP) and RPC, there have been invented new systems according to specific needs of large companies, such as Facebook, Google, and Microsoft. Examples of such systems are GraphQL (originated by the Facebook community) and gRPC (originated by Google in cooperation with Microsoft).

3.1 History of Remote Communication

3.1.1 Beginnings of Networks and Remote Communication

A new era started with Advanced Research Projects Agency (ARPA, today’s DARPA) created in The Pentagon the US in 1957 for the purpose of executing research and development projects for military requirements (anti-missile weapons and satellites). One of ARPA’s re- searchers was also J.C.R. Licklider (scientist at Massachusetts Institute of Technology (MIT), originally psychologist), who was engaged in human-computer interactions [22, 23]. In 1962, he and W. Clark pointed to the fact, that there is much more development required before effective and intuitive online communication between human and computer is established. In this time, computers became much cheaper, time-sharing schemes appeared in hardware and people started to see the importance of thinking and problem solving [24]. They came with an idea of Galactic Network concept that depicts distributed interactions between interconnected computers where each of them can access data and programs from any site. This concept is similar to today’s Internet [25].

17 3. Remote Communication

A theory of using packet-switching instead of circuits was firstly published by Leonard Kleinrock (MIT) in 1961 [25]. Lawrence (Larry) Roberts, who created the first wide-area computer network ever built, however it was small, confirmed Kleinrock’s theory and advantages of packet-switching . In 1967 in ARPA, he released a design paper ("Multiple Computer Networks and Intercomputer Communication") and managed project ARPANET1, that aimed to create a pioneer of US nationwide packet-switching computer network [25]. The first protocols on ARPANET were telnet FTP (File Transfer Protocol) [25]. The ARPANET network spread quickly and there was a need to define a functionally complete host-to-host protocol. The initial host- to-host protocol released in 1970 was called NCP (Network Control Protocol) and meant an initial point for development of network using applications [25]. That year also the first US cross-country link was installed by AT&T between UCLA (University of California, Los Angeles) and BBN (Bolt Beranek and Newman, Inc.). One of the first application protocols was Telnet, that was specified in 1972. The protocol represented a minimal mechanism permitting basic interaction between two communicating machines. It was con- ceived in order to overcome small differences of communicating mechanisms, e.g. establishing a connection and determining what character set to use [23]. In 1973, one year after specification of Telnet, another important application layer protocol appeared. As a major initial motivation for the network (ARPANET) was resource sharing, File Transfer Pro- tocol (FTP) made it possible to share files between communicating machines. FTP was the first application permitting two machines to cooperate in peer-to-peer communication instead of treating one as a superior to the other (today’s client-server communication) [23]. Vint Cerf cooperated with Bob Kahn and in 1974 they described in detail the design of the TCP (Transmission Control Protocol) protocol based on their fundamental knowledge of the original NCP design and interfacing to existing operating systems. This initial version of the protocol provided all the transport and forwarding services in the network, but after some time the authors made it clear that not all

1. Successors to the ARPANET are MILNET (Military Network) and today’s Inter- net [26].

18 3. Remote Communication packet losses should be corrected by TCP and the application should be left to deal with the loss. This led in 1978 to a split of the original version of the TCP (today known as TCP/IP protocol) into two protocols, the Internet Protocol (IP) which is responsible for addressing and packet forwarding, and the TCP, with new service features (flow control, recovery from lost packets) added to. For cases with no need for such a reliable communication, there was added a new alternative to TCP protocol called UDP (User Datagram Protocol)[25].

3.1.2 World Wide Web

However the internet spread and developed quickly, it was still not available to public until the 1990s, the breaking change was carried out by introduction of web browsers. World Wide Web (WWW) is a system of linked hypertext documents accessed by the Internet, that was introduced in 1991. This system was released by CERN’s (the European Organization for Nuclear Research) computer scientist Tim Berners-Lee. His initial proposal for WWW made in 1989 became WWW, however it was meant to be used only for more effective internal CERN’s communication system, as the communication was not ideal because of many incompatibilities of the platforms and tools [27]. He proposed an implementation of a simple scheme to connect several different servers, that were available at CERN, with an analysis of the requirements for information access included. The ambitions of this project were to bring in a protocol for requesting human readable information, so that the a format of the information would be common for the both communicating sides. Searching by a keyword in documents was also included as a goal of the project. A software including all the mentioned features was intended to be free of charge [28]. HyperText is a way to link with references (also called hyperlinks) and access a variety of information on the Internet. An access to this information was meant to be provided by a program called a browser [28]. The first search engines came a few years later - in 1995.

19 3. Remote Communication

3.1.3 Web 1.0 The first implementation of the web is referred to as Web 1.0 (also called Static Web) and was in use between 1996 and early 2000s (some resources allege 2004). This time was an era of static pages without machine compatible format and its only purpose was a content delivery, as the web was considered to be read-only [27, 28]. In order to promote wide adoption of Web 1.0, the core protocols technologies were UDI (now URI - Uniform Resource Identifier), HyperText Markup Language (HTML) and HyperText Transfer Protocol (HTTP) [29].

3.1.4 Web 2.0 The next generation of the web is Web 2.0 (also called Social Web) as a concept of a read-write approach, dated from early 2000s (2004) to 2016. Principal features of this generation of web were more scal- able services, flexible web design with lightweight UI (user interface), ability to collaborate on content creation and modification - which means harnessing of collective intelligence. Web also became a software above the level of a single device - applications such as wikis, blogs and RSS feeds appeared [27, 30].

3.1.5 Web 3.0 The third generation of web - Web 3.0 - was an executable approach dated from 2016. It is also called Semantic Web, because of addition of meaning. This concept was thought up by WWW’s inventor Tim Berners-Lee. In this approach, multiple services (such as web browsers) share data resources instead of owning them, show different views of the same web or the same data because of the personalization and focus on the context. Other major characteristics are approach of developers’ open-source software platform, resource pooling, the importance of mobile devices and their connection to the Internet and more in- telligent web (importance of semantic web technologies, distributed databases and applications using natural language processing, machine learning etc.) [27, 31].

20 3. Remote Communication

3.1.6 Web 4.0 and the Future of Web There is a number of studies published, dealing with Web 4.0, however, the concept of Web 4.0 is not currently totally clear. Most of studies state possible approaches such as to become truly ubiquitous by bringing together all aspects of Web 2.0 and Web 3.0; association with the concept of IoT (Internet of Things) or to become the IoT. Some of the studies place the personalization to the center and claim that Web 4.0 will provide personalized data to the user according to a universal web personality of each user, where no anonymity will be possible [32]. Another opinion mentions symbiotic Web 4.0 with interactions between humans and machines [27].

3.2 Remote Communication Protocols and Frameworks

3.2.1 REST Representational State Transfer (REST) is the most common architectural system among web services and APIs, that relies on sharing and merging data of multiple sources. It was introduced in the doc- toral dissertation thesis by Roy Fielding in 2000. It defines constraints for web services, using interaction in a stateless manner with textual resource representation and a standardized approach to web APIs. REST supports hypermedia by its first design. Client and server are loosely coupled and are not constrained in resource manipulation, which supports server evolution, rapid iteration, resource provision elasticity, and other advantages. The other great features of the REST are its layered architecture, efficient caching, and high scalability [33].

3.2.2 HTTP HTTP (HyperText Transfer Protocol) is a generic, stateless, and wildly successful protocol that belongs to a family of application-level protocols, that are designed for distributed, collaborative, and hypermedia information systems. To mention other significant properties, HTTP has typing and negotiation of data representation, that does not bind the implementation to the transferred data [34].

21 3. Remote Communication

It started with the first simple version HTTP/0.9 for transmission of payload as raw data, the next generation HTTP/1.0 was improved and supported also MIME type (Multipurpose Internet Mail Exten- sions, media types, such as images, audio, text, etc.) of messages and contained metadata about data. HTTP/1.0 allowed only one request a time on a given TCP connection [35]. In order to ensure reliable implementation of HTTP’s features, the HTTP/1.1 version includes more stringent requirements than HTTP/1.0 [34]. HTTP/1.1 included also pipelining, but there is only partially addressed request concurrency. As a result for the both HTTP/1.0 and HTTP/1.1, it is needed to make many requests through multiple connections to the server to achieve concurrency and reduce latency [35]. HTTP/2 introduces an efficient compression of header field andal- lows multiple concurrent request and response messages (also called frames) creating concurrent streams on a single TCP connection. As a result, fewer TCP connections must be established to transfer the same amount of data then in previous versions of HTTP, so cost of large scale networks is significantly reduced. It also supports a priori- tization of requests, that allows another performance improvement. HTTP/2 enables processing of messages through the use of binary message framing. Flow control helps to protect endpoints with source constraints to transmit only data that can be used by a receiver [35]. HTTP/3, also known as "HTTP/2 over QUIC", is the proposed suc- cessor to HTTP/2, which is already in use on the web (used by default in latest macOS). This protocol supports the same semantics over as HTTP/2, but over a new QUIC transport protocol. HTTP/3 is using UDP (User Datagram Protocol) instead of TCP (Transmission Control Protocol). The QUIC transport protocol was designed in Google (early called gQUIC) and specified in 2012, in order to improve performance in applications currently using TCP. That time the binary syntax was packed into QUIC packets and sent by UDP instead of TCP [36, 37].

HTTP in general uses request methods to indicate a desired action to a server. The mostly used methods are GET, POST, PUT and DELETE. The response contains a status code that represents the state of the performed operation, for instance 2XX codes represent success, client

22 3. Remote Communication

side error is represented by 4XX codes and server side error by 5XX codes.

3.2.3 RPC The first idea of remote calls acting just like local calls enabling communication for distributed systems comes from 1960s, theoretical solutions come from 1970s and practical solution dates to 1980s. The most important design decisions, desired properties and vulnerabilities description - such as uniform call semantics, binding and configuration, strong type-checking, parameter functionality, and concurrency and exception control - of then RPC (Remote Procedure Calls) implementation were described in 1981 by Bruce J. Nelson [38]. In RPC communication, one connection logically serves two pro- cesses - a client and a server process. The client process sends a request message to the server process and then it is blocked and waits for a response message. Then the server sends a response computed according to the parameters sent in the request. Once the replying message is received, the client’s execution is resumed [39]. In this protocol version, there is only one process active on a one connection at a given time. The ONC RPC protocol makes no restrictions on the concurrency model and allows users to use asynchronous version of the RPC, so the client is not blocked while waiting for the response [39].

3.2.4 gRPC Google was using for over a decade its own RPC infrastructure called Stubby, but it was not based on any standard and was too tightly coupled with Google’s internal infrastructure [40]. Thanks to the advantages of RPC, such as efficiency due to its binary format, well-defined communication interface, there came the idea to create a similar protocol. Google came with a new approach with promising properties, called gRPC (gRPC Remote Procedure Calls), that was officially released as an open-source in August 2016 2 [41]. This new approach

2. Details of the first release can be found at https://github.com/grpc/grpc/ releases/tag/v1.0.0

23 3. Remote Communication should also support applicability to IoT (Internet of Things), mobile, and cloud-based use-cases. gRPC is a modern open-source, high performance and multi-platform approach to RPC framework, which uses protocol buffers as Interface Definition Language (IDL) by default. This framework supports multiple programming languages and is suitable for client-server, as well as for bidirectional communication. An advantage of this technology is efficient connecting of services between data centres, inside themor between the services, but also client-server connection of an application to a back-end service, mainly in a situation of disparate services and APIs [2]. The other features are high scalability and low latency. gRPC, its properties, and comparison with the most commonly used HTTP are described in detail in Chapter 4.

3.3 Summary

This chapter described the history of remote communication, as well as the most used client-server communication protocols nowadays. It also brought a brief introduction to the gRPC protocol as a new way of communication, which is described in detail in the following Chapter 4.

24 4 gRPC

In this chapter, at first, gRPC is compared with the most used communication protocol - HTTP. In the following sections, the design, usability, and properties of gRPC framework in general will be described. Later on in this chapter, various kinds of applications as possible solutions for the usage of gRPC will be considered and aspects as performance, security for each of the solutions will be discussed.

4.1 Comparison of gRPC and REST

Comparing REST (Representational State Transfer), which is suitable for data transfer in stateless architecture, and gRPC, we find a key difference in teh definition of the communication. By gRPC, there are RPC functions defined by a contract with defined negotiation, restricted by the client-server relationship, not by the architecture itself. gRPC puts the accent on the client for execution and on the server for computation and sources, therefore gRPC is suitable for extremely low-power scenarios, such as IoT [33]. However, there is still one issue, where REST still scores - browser support. REST is fully supported by all the browsers, gRPC usage is limited and requires gRPC-web with a proxy layer in order to convert to various HTTP versions, as gRPC heavily uses HTTP/2 features [42]. gRPC-web enables browsers to utilize features of high-performance and low network usage. An overview of properties of gRPC and HTTP utilized in APIs is described in Table 4.1.

4.2 Design

Each of the languages supported by gRPC is composed of several layers, that allow users customization of their applications. There are two groups of the languages - implementations using the pure language itself (for example Java, Go, C#) and implementations based on C-core. Most of the languages, such as Python, Ruby are built as a layer over the C-core base. In the C-core based languages, the application calls a stub of the current language, then the calls are

25 4. gRPC passed through an interceptor and to a library, that translates the calls into C language calls, then encodes RPC calls as HTTP/2, encrypts and sends them to the network [43].

4.2.1 Network Communication Principle Moreover, gRPC uses HTTP/2 (described in detail in section 3.2.2) as the default underlying protocol, which has ability to multiplex the calls and it is efficient and compact for sending and receiving messages [44]. The key of this concept is a channel - it represents a virtual connection to the endpoint. This entity is backed by multiple concurrent HTTP/2 connections, where each connection enables many concurrent RPC streams. RPC represents plain HTTP/2 stream - each RPC message is sent as HTTP/2 data frame. A single data frame can contain multiple small gRPC messages, or in the opposite case, one larger gRPC message can cover more data frames [45]. This structure is displayed on a diagram in Figure 4.1.

4.2.2 Types of Communication There are 4 high-level types of communication in the gRPC. The following examples are on the assumption of the declaration of messages CoordinateRequest, PlaceResponse, RouteSummaryResponse, and RouteNote. The first one is called Unary (also called Simple RPC) and consists of a client sending a single request to the server and it responses with a single response. This approach is very similar to HTTP REST and also is used in the implementation part of this thesis. Example: rpc GetPlace(CoordinateRequest) returns( PlaceResponse){} The second type is Client streaming. In this scenario, a client sends a stream of multiple messages and expects a single response from the server. Example: rpc RecordRoute(stream CoordinateRequest) returns(RouteSummaryResponse){}

26 4. gRPC

Figure 4.1: Structure of gRPC on HTTP/2

Server streaming is the third type, where a client sends a single response and expects a stream of multiple messages from the server. Example: rpc ListRoutes(CoordinateRequest) returns( stream RouteSummaryResponse){}

The last but not least, there is the fourth type - Bidirectional streaming, which personalizes a great feature of gRPC. Using this type of communication, both a client and a server keep sending a stream of messages to each other in parallel. The communication is flexible and without blocking (waiting for messages), that makes gRPC an excellent protocol for point-to-point real-time communication without polling[33, 46]. Example:

27 4. gRPC rpc RouteChat(stream RouteNote) returns(stream RouteNote){}

To sum up, gRPC brings a new approach to bidirectional communication between a client and a server, which may be interesting for real-time communication. It also supports polygot environments, which allows developers to use popular development languages of their choice [46].

4.2.3 Error Handling

Each error is associated with a particular status code (similar solution as HTTP status codes). The errors can be caused by both client and server side - such as network failures, protocol errors, request cancellation, etc. The successful request ends with OK status returned to the client, in another case the error model is returned, which is available in all supported languages [47]. There are two types of errors originating in failed connection - clean failures, when the error is communicated to the user, and less- clean failures, when the gRPC endpoint dies without providing any information to the client. The first easy-to-observe type is a result of closed connection ortime limit exceeding. When the connection closes clearly, it is followed by HTTP/2 closed connection, which ends gRPC connection. In the second case - less-clean failure - the great feature of HTTP/2 shows up. Without HTTP/2 semantics, TCP would retry the connection for 10 minutes to declare the connection is dead. With HTTP/2 using KeepAlive, gRPC frames are sent periodically and no PING response on time means a loss of connection, so the connection is closed and the act of re-connection begins [45]. In the gRPC code best practices there is no rule where to include custom errors and statuses. Google provides predefined message type Status and the location of this message depends on the developer.

28 4. gRPC 4.3 Usability of gRPC

gRPC was designed to fully support not only web applications, but also IoT and mobile use-cases. The current implementation of gRPC is not used only in Google’s products and external APIs, but also by such significant companies and large products as Netflix, Cisco, CocroachDB, Spotify and Dropbox [48].

4.3.1 Microservices One of the substantial principles of gRPC philosophy is to promote microservice architecture. It is also the most common reason to choose the mentioned framework. The origin of the gRPC is also associated with microservices, as the original Google’s framework - Stubby - connected a large number of microservices communicating within and across many data centers and this design had to stay unchanged [40]. Microservices constitutes a software architectural approach built on the concept of modularization with emphasis on technical bound- aries. Each microservice operates as a single independent unit of development, operations, scaling, and deployment with its own versioning, that provides an access to its data and logic through a well-defined interface. Because of the small size of the units, software agility is increased and new features of the system based on the microservices can be introduced in parallel. Other important benefits of the microservices approach are increased speed of delivery, improved scalability, and greater autonomy [49]. Because of gRPC’s design for low-latency and high throughput communication, gRPC is a great solution for microservice systems where efficiency is critical.

4.3.2 Web Applications and Websites Websites and web applications are the most used entities communicating as a client with the server by the network, mostly via HTTP protocol. Theoretically, utilization of gRPC in the communication may introduce a faster way of the request and response message exchange, as show the performance studies mentioned in Section 4.5.

29 4. gRPC

However, as gRPC utilizes HTTP/2 features, it is still not possible to call a gRPC service from a browser directly. There are 2 solutions solving this problem. The first one is to use gRPC-Web1, which is additional JavaScript technology enabling direct gRPC calls from the browser, with a proxy layer in order to convert to various HTTP versions [42]. The second option is to create a RESTful JSON API by annotating .proto file with HTTP metadata [46]. At the time of writing this thesis, there are no comparisons and benchmarking of gRPC-Web and standard HTTP communication available.

4.3.3 Mobile Applications Nowadays, people prefer to own a mobile device with the maximum size of display possible with new features and sensors, but in conclusion, all of these new properties result in need for more energy and higher battery consumption. In this section, only mobile applications communicating through the network are considered. To improve overall execution time, there are 2 ways of the computation. The first way is to process everything locally and then share the data through the network. The battery consumes more energy on the computation, but only a small amount of data is sent through the network. The second way is used in order to save energy and lower battery consumption on mobile devices. One of the most used techniques is to transfer the tasks to remote servers and compute them offloadly. The computation is usually completed on devices with higher level of performance than the original one. Factors influencing the offload execution are the network profile (e.g. different wireless flavors -3G, 4G, 5G, and WiFi), an amount of data for transmission and a number of tasks to be computed. Also, various communication protocols and architectural styles have an impact on the length of the remote computation. Approximately, maximum of 3% of methods used in mobile applications are enabled to be directly migrated offload. After refactoring, up to 47% of the methods can run offloadly [50]. However, the time

1. https://github.com/grpc/grpc-web

30 4. gRPC

spent on the communication and sharing data for the computation offloadly may reduce the time benefit gained from the computation on more capable devices, therefore increase overall execution time. The utilization of gRPC can represent an enhancement in mobile applications in network-constrained environments that compute the tasks offloadly. gRPC’s lightweight message format may speedup the communication and so the overall execution time, while offload computation lowers battery consumption itself [33]. Several studies are analyzing gRPC performance in mobile applications in comparison with other communication protocols and frameworks. These studies are described later in Section 4.5. For mobile application development, it is possible to build the applications with programming languages such as Kotlin/JVM and Java for Android operating system, and Objective-C for iOS development.

4.3.4 IoT and Embedded Systems Internet of Things (IoT) represents a highly distributed network of smart devices embedded with sensors, processors, or other technology, communicating, collecting, and exchanging data via its connection to the network. Collected data are sent and analyzed by the cloud or locally. Nowadays this technology is utilized by industry, such as man- ufacturing, finance. This era of development of the smart technology included in the production is called Industry 4.0. The IoT devices are also part of our everyday life, e.g. as wearables, a part of smart homes (thermostats, security systems, lighting, smart energy applications, etc.), or smart transport. The requirements of this technology include low response time and low battery consumption. The idea of IoT started at the Massachusetts Institute of Technology (MIT) in 2010 on devices interconnected into Radio-frequency identification infrastructure (RFID). The evolution came from machine-to- machine (M2M) communication, which is the connection of machines through a network without human interaction. The technology has moved forward and the term IoT is usually connected with an advanced network of services interconnected by the Internet protocols. The devices generally do not need human intervention for their work, except for setting up, giving instructions, or accessing the data or results.

31 4. gRPC

Nowadays, we consider a connection and communication using IPv6 over Low-Power Wireless Personal Area Networks (6LoWPAN) to be a standard. The application layer communication protocol between a client and server is defined by OMA Lightweight M2M (LWM2M) protocol, which is also instrumental to service enabling and device management. Another notable protocol is Message Queuing Teleme- try Transport (MQTT), providing lightweight data transport with queuing. In order to reduce time spent on communication for remote computation and so a time of overall execution, IoT devices can also use computation offload, such as mobile applications described before in Section 4.3.4. On these devices, the battery consumption and performance can be enhanced by using efficient storing and serialization. These features are also provided by gRPC’s Protobuf. gRPC is applicable in a resource- jealous or nimble and lightweight system, mainly when the system requests a set of data or the data are processed routinely. All these properties make gRPC a suitable tool for communication between IoT devices [33]. Many languages, that are interesting for the development of the IoT applications, such as C++, Go, Python, etc., are also supported by gRPC. However, gRPC is missing some of the key features common for current technology. For instance, gRPC does not support a possibility to queue the messages, as MQTT does. In conclusion, the possible improvement of IoT devices using gRPC for communication depends on the type of messages. The greatest feature of the mentioned framework are its efficient messages -in the case where the data are represented by great objects with sparse data (many properties have default or undefined value) and there is no need for message queuing, gRPC would represent a profitable solution.

4.4 Requirements and Principles

Several requirements are imposed for services utilizing gRPC. This section describes a list of some of the most important principles.

32 4. gRPC

It is fundamental for the communication to choose a protocol capable of surviving traversal over internet infrastructure. By design, gRPC works over HTTP/2, which brings a requirement to use coop- erative technology with this protocol. The operations through the network may be long-lived and therefore expensive, so it is important to support mechanisms that allow cancellation. As there are different types of messages, encoding, payload, and compression needed (protocol buffers, JSON, XML) for various services, the protocol and implementations must fulfill this requirement. In order to avoid problems with scaling and handling streams on used platforms, both synchronous and asynchronous processing of the sequence of messages exchanged between communication participants should be supported. Servers must have the ability to gracefully shut down and reject new requests from clients while continuing to process in-flight requests. As it is conventional in the communication based on HTTP, gRPC has also status codes associated with particular errors. It is important to keep the status codes constrained, to make error handling decisions clearer on the client’s side. To provide more information about the error, it is possible to include it in the message metadata [40]. However, there is no strict convention where to include the information about the error.

4.5 Performance

gRPC messages are serialized by a protocol buffer, a mechanism described later in Section 4.9.1, that serializes very fast on both the client and the server side. Thanks to a smaller size of the binary message payload (in comparison with large JSON messages used in classic REST APIs), the communication is much more efficient and suitable also for environments with limited bandwidth. Therefore there is an expectation of much faster gRPC communication than HTTP REST. The measurements and benchmarks were made on gRPC unary calls, as HTTP has no equivalent for streaming because it is HTTP/2 specific feature.

33 4. gRPC

4.5.1 Battery Consumption

There is a study described in [51] made on various input data size, number types (integer and float type), and small object types (objects with 4 properties - of string and integer type) on sorting algorithms with various complexities. They used Android application run on a mobile phone with Android 6.0.1 (Marshmallow) operating system, that communicated with a server run on Windows 7 by standard WiFi. The results show that the best solution for the lowest battery consumption is to execute the tasks locally. In a remote way of execution, the most economic choice is the communication by REST (followed by Socket). gRPC configuration is economic in very rare occasions. According to our assumptions, a great advantage of gRPC was not considered - the efficient messages formatting, the result of which would appear in computations on bigger data, as the study used only numbers and simple data objects. This explanation is also supported by a study [52] - the serialization is in the sorting application quite simple, so the benefits of gRPC are not utilized.

4.5.2 Speed of the Requests

Other benchmarking studies, such as [53, 54, 55] do all agree on the same affirmation, that gRPC is in the comparison with HTTPREST calls much faster. The studies did not track the duration of the creation of clients and servers to the total duration and none of the benchmarking applications accessed a database or other services. Results from the study [53] of benchmarking of gRPC and REST show, that only one scenario where REST had a better result was getting a large payload (gRPC sent it as a stream of objects, REST sent enumerable data collection). gRPC is roughly 7 times faster than REST when receiving data and roughly 10 times faster when sending data. The second study [54] made on concurrent communication shows, that gRPC is capable of making 48 requests/second (1 request per 20.81 ms), while HTTP REST only 4 requests/second (1 request per 260 ms). The results claim that gRPC has approximately more than 10x higher throughput than HTTP REST. Moreover, gRPC uses much less CPU time to process each message. At gRPC, total communication CPU time was 832.00 ms/s, 48 requests were made per second, that results in

34 4. gRPC

17.33 ms per 1 request. In the case of the HTTP REST communication, 404.00 ms lasted the whole communication with 4 requests, which results in 101 ms per a single request. The last mentioned study [55] compared gRPC and HTTP REST communication with different kinds of loads and showed an expected result, that communication made by concurrent calls connected to a single server with small or normal load is faster by HTTP REST (1 request per 3.023 ms) than gRPC (1 request per 4.196 ms). The heavy load was approximately 1.5x faster in gRPC connection (1 request per 2.579 ms) than in HTTP (1 request per 4.0195 ms).

In conclusion, the results of all the studies do agree on a claim, that gRPC communication is faster than HTTP REST communication as the expectations were stated. In addition, a higher throughput of gRPC connection was declared.

4.6 Security

As gRPC-based applications communicate through the network and expose their entry points (services) to others, they run a risk of being attacked. This risk is increasing with the higher number of publicly accessible endpoints. Therefore it is essential for all public endpoints to handle and support authentication and encryption of the messages [56].

4.6.1 Authentication In order to provide secure communication to the other systems, gRPC is designed to cooperate with many authentication mechanisms. The gRPC built-in authentication mechanisms are the following ones [57]: ∙ Secure Sockets Layer/Transport Layer Security (SSL/TLS) - for server authentication and communication encryption ∙ Application Layer Transport Security (ALTS) - mutual (service- to-service) authentication and transport encryption system developed by Google, because older versions of TLS did not sat- isfy Google‘s minimum standards. Better maintainable and bug monitoring, due to simple design [58]

35 4. gRPC

∙ Token-based authentication with Google - generic mechanism to add metadata to response and request, this mechanism has to be used along with SSL/TLS There is a possibility to plug an own authentication system via the Credentials plugin API. gRPC has also built-in support for OAuth 2.0 and JSON Web Token (JWT) [56].

4.6.2 Vulnerabilities As mentioned in Section 4.2, there are two types of implementation according to the base language. The languages that are actually wrap- pers over C-core (such as Python and Ruby) enable the translation of calls in different languages into C language calls. In these cases, there is a chance that a developer may introduce a vulnerability to the system when meeting memory management. As entry points for vulnerabilities may serve also misconfigura- tions in the environment, that may result in unauthorized access. Con- tent validation and detection of a malicious payload are also essential for secure remote communication. The last but not least, monitoring the status of a service, enforcing authentication and authorization is important to keep the data secure.

Known Vulnerabilities According to the National Vulnerability Database (NVD)2, there were 5 vulnerabilities revealed until April 2021. Most of them were published in 2017 and a single one in 2020. 4 of the vulnerabilities were classified as critical (with Common Vulnerability Scoring System (CVSS) v3 score of 9.0-10.0 from 10.0). All the critical vulnerabilities were published in 2017 and they were caused by out-of-bounds write because of a heap-based buffer overflow. A single vulnerability was classified as high (with CVSS v3 score of 7.0-8.9 from 10.0) published in 2020 and it was caused by gRPC’s vulnerability to Prototype Pollution. The statistics show, that the vulnerabilities are exposed rarely - 5 vulnerabilities per 5 years of gRPC’s public existence (2016-2021),

2. https://nvd.nist.gov/vuln/search/results?form_type=Basic&results_ type=overview&query=grpc&search_type=all 36 4. gRPC

but the majority of them is very highly scored, 20% is marked as high and 80% as critical. There are also vulnerabilities from other vendors utilizing gRPC, such as improper handling of gRPC requests, that may result in unauthenticated access and allows a remote attacker to cause a Denial of Service (DoS).

4.7 Reliability

In the network communication failures may occur - such as a loss of the messages, duplicated or reordered messages, error on the client or server side. For the majority of web communication, it is important to have a guarantee of reliable communication provided by the protocol. According to the requirements mentioned in the specification [59], a reliable messaging protocol should guarantee the following Quality- of-Service (QoS) objectives:

∙ The possibility to authenticate the sending and receiving services.

∙ Messages should be traceable.

∙ Communication protocol should provide a delivery assurance so that there is a guarantee the messages were sent and delivered.

∙ Messages are sent and received only once and also received in the same order they were sent.

∙ At least one of the communicating sides is notified about the failure in the communication

Since Transmission Control Protocol (TCP) - underlying protocol of HTTP/2 - is defined as reliable protocol, we can also define gRPC framework utilizing properties of HTTP/2 as reliable.

4.8 Developer Experience

A good DX is nowadays one of the key properties of systems, applications, websites, and other kinds of software. The better experience

37 4. gRPC developers have the more time they are willing to spend with the software. Aspects such as the function, stability, ease of use, clarity, related libraries, documentation of the software can be considered to evaluate DX. gRPC is an open-source solution of RPC framework with a repository hosted on GitHub3, which is the first key property of this framework. When support is needed, it is possible to create an issue at GitHub and the authors and responsible people are active in these conversations. Also, it is possible to create a pull request with missing useful functionality, that is thereafter reviewed and merged to the framework library. At the time of writing this thesis, gRPC supports and provides libraries in 11 programming languages, such as C++, C#, Python, Java, Kotlin, Node.js, etc. There are two groups of the languages - implementations using the pure language itself (for example Java, Go, C#) and implementations based on C-core. Most of the languages, such as Python, Ruby are built as a layer over the C-core base [43]. All of the languages are covered by examples and basic "getting started" tutorials. One of the advantages of gRPC protocol buffer files is their language independence. These files are available for all the supported languages and then compiled and a code is generated according to the specific language. For more advanced use of the framework, there is API reference available, but with no sample code. Proto definition and its types are well described in multiple tutorials, but there are missing examples of more advance usage of the framework - for example, asynchronous communication between client and server. Any notice of best practices is also omitted, for instance where the errors should be included in the response (should they be included in the metadata or an own response object with properties should be made according to the traditional HTTP response).

3. Repository available at https://github.com/grpc/.

38 4. gRPC ) a gRPC API Required (.proto definition) HTTP/2 Binary (potentially small, optionally also JSON) Faster (by Protocol Buffer) Strict (type-safe) Unary, streaming Client, server, bidirectional No (grpc-web required) Transport (TLS/SSL), but also ALTS or token-based Yes (Protocol Buffer) According to the endpointmentation imple- Cross-language (languages sup- Needed Faster (7-10 times than REST API Slower (message definitions, etc.) ported by Protocol Buffer) REST HTTP API Optional HTTP (usually HTTP/1.1) JSON (potentially large) Slower Loose (any HTTP is valid, noresponse strict message format) Request-response model (unary) No Yes Transport (TLS/SSL) Third party tools (e.g. OpenAPI) Traditional REST (GET, PUT, POST, DELETE, etc.) Cross-language Not needed Slower Faster Table 4.1: REST HTTP API and gRPC API overview (based on comparison from [46]) Feature Contract Communication protocol Payload Message (de)serialization Specification Communication Streaming Native browser support Security Code generation Endpoints API Implementation Specific client setup Transmission speed Implementation

39 4. gRPC 4.9 gRPC Utilization in Implementation

4.9.1 Protocol Buffer Protocol Buffer is serializing mechanism for structured data, resulting in messages. This mechanism is language and platform neutral. Proto- col Buffer is the default option for serialization, but the response can also be encoded in JSON format. The structure of messages has to be defined in the .proto file, described in detail later in this section [60].

Protobuf File A protobuf file (with an extension .proto) defines an interface of the communication between a client and the server and all methods, requests and responses must be included. According to this file, the objects representing the client-server communication are generated into the source code [61]. This file defines an interface of the communication between a client and the server and all methods, request, and responses must be defined. The code (message) generators coexist in two versions - an older proto2 and a newer proto3. proto3 version introduces implementation of further languages, such as C#, Ruby, Go, Objective-C and Dart, and has a simplified syntax. This standard is recommended while using C#. These standards are not completely compatible and developers have to be careful while defining data types in messages - for instance, the newer proto3 version does not support an extension of message types, however, proto2 enables this option [62, 60]. There is a possibility to include optional parameters in the .proto file, such as the creation of a separate file for each of generated classes or a name of the outer object covering all the generated classes defined in the .proto file. A sample .proto file is included in Appendix C.

Format of the Messages The attributes of the message are represented by key-value pairs. The key is the so-called field number, a unique identifier of the attribute. In case the format of the message was changed, it is important to keep the field number. It is needed to use new unused identifiers (alsonot used by previously deleted fields) in case the field was newly added.

40 4. gRPC

If the field was not changed, the identifier stays unchanged. In case the binary contains fields not recognized by the parser because the binary versions differ, the result binary fields contain unknown value in fields not contained in the parser‘s binary. These fields are discarded in proto3 messages, but from version 3.5 they are included in serialized result messages [60].

Protobuf Compiler and Source Code Generating There are 2 ways how to generate objects in a specific programming language from the messages defined in the .proto file. The first way is a compilation of .proto files by calling the Protocol buffer compiler using command protoc, where it is needed to specify a directory containing .proto files defining all used types, output directory, and .proto file meant for code generating. protoc command is called according to the following pattern4:

protoc –proto_path=IMPORT_PATH –cpp_out=DST_DIR –java_out=DST_DIR –python_out=DST_DIR –go_out=DST_DIR –ruby_out=DST_DIR –objc_out=DST_DIR –csharp_out=DST_DIR path/to/file.proto

The second one is by language-specific libraries also internally using protoc, where it is needed to define important properties of code generating in configuration files, such as .csproj and build.gradle files. Classes are generated by building the project.

4.9.2 Data Serialization and JSON Mapping

When comparing serialization of protobuf and JSON messages, gRPC protobuf was consistently about 3x faster for serializing than JSON. In terms of deserialization, JSON is 1.5x faster than protobuf when deserializing messages smaller than 1 kb. However, for messages larger than 15 kb, protobuf’s deserializing mechanism is 2x faster [63].

4. Further details of the command are described at https://developers.google. com/protocol-buffers/docs/proto3#generating

41 4. gRPC

Mapping Messages to JSON Mapping to JSON is possible while using proto3. It makes it easier to share the data between various systems. In case the value of the incoming JSON message to the parser contains a null field, the parser translates this field to the default value. All fields with default values are omitted from the resulting message in order to make the message shorter [60]. The communication is still more efficient, however, the smaller default binary format is not used.

Mapping of gRPC API to HTTP REST API In case the gRPC API is structured like a traditional HTTP REST API in a resource-oriented way with a small number of methods corre- sponding to HTTP verbs (such as GET, POST, PUT, DELETE) that operate on the service’s resources, it is possible to map HTTP/JSON request to gRPC API endpoints by defining option in the service definition shown on the following example (with a precondition messages CreateTripRequest and TripResponse are defined): service TripService { rpc CreateTrip(CreateTripRequest) returns TripResponse { option (google.api.http) = { post: "/trip", body: "trip" }; } } The translation from HTTP/JSON calls to calls receivable by gRPC services is also possible through Extensible Server Proxy (ESP)5, but only for Python and Java languages. This mapping brings an advantage of a single API serving more types of messages. The most common use-case is allowing browser clients to talk to gRPC servers without special support from gRPC client libraries, such as gRPC-Web.

5. https://cloud.google.com/endpoints/docs/frameworks/ frameworks-extensible-service-proxy

42 4. gRPC

4.9.3 Network Communication On the client side, there is a local object called stub, that implements the same methods as the service defining the communication interface. It enables the client to call the method on the local object with parameters wrapped in a message defined by protocol buffer message type (defined in a .proto file in an implementation). Then, a request is sent to the server by gRPC and the protocol buffer response is returned [64]. From the client side a method on the stub object is called by ./.

Server Reflection Server reflection is an optional server extension, where the server as- sists client construction of the requests in the runtime, so the client does not have to have the information about the communication interface. It means both communication sides do not share the .proto files.

4.10 Summary

This chapter described gRPC protocol and compared it with the most used communication protocol - HTTP. Various kinds of applications were proposed as possible solutions utilizing gRPC, and aspects as performance, security, and DX were discussed. Analysis and evaluation of gRPC properties are described in the following Chapter 5.

5 gRPC Analysis

This chapter introduces Goal Question Metric (GQM) approach as a methodology for evaluation and analysis of gRPC‘s properties and also brings answers to the thesis Goal 1 stated in Section 1.2.

5.1 The Goal Question Metric Approach

The GQM is a metrics-oriented approach used for improvement and measurement of the software quality. Firstly, the conceptual level (the goal) must be specified. The goal is defined, including the purpose of measurement, object to be measured, issue to be measured, and viewpoint of the measurement. Secondly, on the operational level, the questions breaking down the goal into several parts are defined. These questions suggest how to achieve the stated goal. Then, the questions are refined into metrics on the quantitative level, which can be both objective or subjective and they answer the questions. The objects of the metrics must be measurable and one metric can bring the evaluation to more questions [65]. Goal, questions and metrics are forming a hierarchical structure. The goal is divided into several parts defined by the questions, each of the questions is evaluated according to several metrics. A scheme of GQM is displayed in Figure 5.1.

5.2 Stated GQM

Goal 1: Analyze and find the most suitable types of applications for gRPC protocol, viable for omnichannel content delivery.

Q1: What is the impact of gRPC adoption for web applications? Q2: What is the impact of gRPC adoption for mobile applications? Q3: What is the impact of gRPC adoption for IoT applications? Q4: Which of the application types is viable for omnichannel content delivery scenarios?

45 5. gRPC Analysis

Figure 5.1: Scheme of GQM approach

M1: It is suggested by the community and authors to use gRPC in the specific scenario.yes/no ( ) M2: It brings an enhancement in the specific scenario to communicate via gRPC instead of traditional HTTP. (yes/no) M3: The specific scenario is suitable for omnichannel content delivery. (yes/no)

Goal 2: Show performance benefits of using gRPC in comparison with HTTP.

Q1: What speed do gRPC requests have? Q2: Are gRPC messages faster than HTTP REST?

M1: Speed of gRPC requests (time of a single request in ms) M2: Speed of HTTP requests (time of a single request in ms) M3: Ratio of the gRPC over HTTP speed (a ratio of gRPC/HTTP times)

46 5. gRPC Analysis

Goal 3: Show DX benefits of utilizing gRPC.

Q1: Do the supported languages cover the whole range of the use? Q2: Easy start with the implementation? Q3: Well prepared for the developers?

M1: Sample code is included in the tutorials. (yes/no) M2: Sample codes for more advanced communication are included in the documentation. (yes/no) M3: Forums for the questions with an active community. (yes/no) M4: Each supported group of usage (mobile, web development, etc.) is covered by some language. (yes/no) M5: The most common models are already included in the libraries (such as messages, errors, etc.). (yes/no)

Goal 4: Show security benefits of utilizing gRPC.

Q1: Is it safe to use gRPC for network communication? Q2: Is there a possibility to choose an authentication mechanism? Q3: Does the utilization of gRPC brings any vulnerabilities to the software?

M1: Number of supported authentication mechanisms. (number) M2: Option to plug in own security mechanisms. (yes/no) M3: Number of vulnerabilities collected in the National Vulnerability Database (NVD). (total number of vulnerabilities, number of vulnerabilities/year) M4: Percentage of vulnerabilities classified as critical or high by NVD. (in %) M5: Vulnerabilities in other vendors’ products caused by improper handling of gRPC. (yes/no)

5.3 Evaluation of the Stated GQMs

In previous Section 5.2, GQM methodology was established. In this section, the methodology is used for the evaluation of the gRPC frame-

47 5. gRPC Analysis work properties. Firstly, the questions are answered according to the stated metrics. After that, the questions suggest how to achieve the stated goal.

5.3.1 G1: Analyze and find the most suitable types of applications for gRPC protocol, viable for omnichannel content delivery.

It is possible to achieve the stated goal by answering the questions by metrics evaluated in Table 5.1. The metrics are evaluated according to current and related literature, which is summarised in Section 4.3.

Q1: What is the impact of gRPC adoption for web applications? - It is needed to use the gRPC-Web for the calls made in the browser and until the time of writing this thesis, there are no studies comparing the speed of the communication utilizing gRPC and classic HTTP.

Q2: What is the impact of gRPC adoption for mobile applications? - Mobile applications match the requirements of viable communication via gRPC protocol.

Q3: What is the impact of gRPC adoption for IoT applications? - IoT applications without the need for message queuing seem to be a suitable type of gRPC client application.

Q4: Which of the application types is viable for omnichannel content delivery scenarios? - Mobile, web, and some scenarios of IoT applications are considered to be viable for omnichannel content delivery.

Finding: Mobile applications match all the requirements of omnichannel content delivery and the adoption of gRPC. The other types have some constraints or the enhancement is not clear.

48 5. gRPC Analysis

Table 5.1: Evaluation of GQM metrics for G1

Type Metrics Evaluation It is suggested by the community and Unknown Web authors to use gRPC in the specific sce- application nario. Unknown It brings an enhancement in the specific (needed to use scenario to communicate via gRPC in- gRPC-Web) stead of traditional HTTP. The specific scenario is suitable for om- Yes nichannel content delivery. It is suggested by the community and Yes Mobile authors to use gRPC in the specific sce- application nario. It brings an enhancement in the specific Yes scenario to communicate via gRPC instead of traditional HTTP. The specific scenario is suitable for om- Yes nichannel content delivery. Yes It is suggested by the community and (when no need for IoT authors to use gRPC in the specific sce- queuing) application nario. It brings an enhancement in the specific Yes scenario to communicate via gRPC instead of traditional HTTP. Yes The specific scenario is suitable for om- (some scenarios nichannel content delivery. only) Blue cells represent the cases where gRPC evaluation is answered positively, red cells represent negative answers, the unknown answers are represented by white cells.

49 5. gRPC Analysis

5.3.2 G2: Show performance benefits of using gRPC in comparison with HTTP.

To achieve the stated goal, question Q1 has to be evaluated according to the metrics M1, M2, and M3 - speed of the gRPC and HTTP messages and their ratio. These metrics are evaluated in Table 5.2, where the last column presents the ratio of the measured values. gRPC was faster in the cases where the ratio is smaller than 1.0 (blue coloured cells). The metrics are evaluated according to current relevant sources, which is summarised in Section 4.5.

Table 5.2: Average times of gRPC and HTTP messages

Research gRPC HTTP Ratio messages messages gRPC/HTTP [53] - Windows 18.67 ms 18.04 ms 1.035 small loads large loads 139.90 ms 1086.70 ms 0.129 [53] - Linux 9.790 ms 11.832 ms 0.827 small loads large loads 150.992 ms 1151.514 ms 0.131 [54] 20.81 ms 260 ms 0.08 [55] 4.196 ms 3.023 ms 1.388 small loads large loads 2.579 ms 4.0195 ms 0.642 Blue cells represent the cases where the ratio gRPC/HTTP is smaller than 1.0 (gRPC calls were faster).

Q1: What speed do gRPC messages have? - Speed of the gRPC messages is evaluated in the second column of Table 5.2.

Q2: Are gRPC messages faster than HTTP REST? - gRPC messages are in the majority of the measured scenarios faster

50 5. gRPC Analysis

than the HTTP messages. The only exception is small messages, that can be faster in HTTP communication.

Finding: Due to the binary serialization, the biggest gRPC’s performance benefit shows up in the communication with large loaded messages. These messages can be 7-12x faster than the HTTP messages.

5.3.3 G3: Show DX benefits of utilizing gRPC To achieve the stated goal, stated questions have to be answered according to the metrics M1-M5, that are evaluated in Table 5.3.

Q1: Do the supported languages cover the whole range of the use? - Yes - according to M4 in Table 5.3.

Q2: Easy start with the implementation? - Yes - the basics are well described for all of the covered languages and there is an active gRPC community.

Q3: Well prepared for the developers? - Yes - besides specific advanced scenarios.

Finding: DX is very good from all of the views - language support, community and authors communication, sample codes and documentation.

5.3.4 G4: Show security benefits of utilizing gRPC.1 To achieve the stated goal, stated questions have to be answered according to the metrics M1-M5, that are evaluated in Table 5.4.

1. Security details of gRPC are described in detail in Section 4.6

51 5. gRPC Analysis

Table 5.3: Evaluation of GQM metrics for G3

Metrics Evaluation M1: Sample code is included in Yes the tutorials M2: Sample codes for more ad- No - also best practices such as vanced communication included status and error handling are in the documentation. missing M3: Forums for the questions Yes - Stack Overflow (tags grpc, with an active community. protoc), GitHub (Pull request, issues etc.) M4: Each supported group of us- Yes - gRPC is currently covered age (mobile, web development by 11 programming languages etc.) is covered by some lan- languages for mobile app (Kotlin, guage. Java, Objective-C etc.), web app (C#, Node.js) and IoT (C/C++, Python, etc.) development M5: The most common models Yes - CommonProtos library by are already included in the li- Google braries (such as messages, errors etc.). Blue cells represent the cases where metric evaluation is answered positively, red cells represent negative answers, the unknown answers are represented by white cells.

Q1: Is it safe to use gRPC for network communication? - Yes, there are many types of authentication options.

Q2: Is there a possibility to choose an authentication mechanism? - Yes.

Q3: Does the utilization of gRPC brings any vulnerabilities to the software?

52 5. gRPC Analysis

Table 5.4: Evaluation of GQM metrics for G4

Metrics Evaluation M1: Number of supported au- 3 thentication mechanisms. SSL/TLS, ALTS, Token-based authentication, as well as built-in support for OAuth 2.0 and JWT M2: Option to plug in own secu- Yes rity mechanisms. (via the Credentials plugin API). M3: Number of vulnerabilities Overall 5 vulnerabilities in 5 collected in the National Vulner- years, 1 vulnerability per year on ability Database (NVD). average M4: Percentage of vulnerabilities 20% of the vulnerabilities with classified as critical or high by high and 80% of the vulnerabili- NVD. ties with critical score M5: Vulnerabilities in other ven- Yes dors’ products caused by im- may result in unauthenticated ac- proper handling of gRPC. cess

- Only improper handling may cause unauthenticated access of an attacker, vulnerabilities are not revealed very often in the gRPC itself.

Finding: gRPC allows a developer to use one of 3 authentication mechanism, besides the option to use an own mechanism and plugins. Vul- nerabilities of the protocol are not revealed very often, but they may be caused in the applications by improper handling of the messages.

5.4 Summary

This chapter evaluated gRPC according to GQM methodology and also gave results to Goal 1 stated in Section 1.2. The findings show gRPC to be a secure protocol with satisfying DX and promising en- hancements for mobile or IoT applications, where the communication messages contain large data loads. Mobile and some IoT applications do also fulfill the requirements of the omnichannel content deliv-

53 5. gRPC Analysis ery, for example, they can be target devices for communication with Kentico Kontent APIs. Analyze various aspects of gRPC in view of performance, security, reliability, developer experience for different target channels (web, IoT, mobile, etc.) and show scenarios in which gRPC is above the traditional HTTP approach. The following Chapter 6 introduces a design and implementation of such gRPC API, that would be an appropriate alternative to Kentico Kontent Delivery API. After that, the chapter analyzes the properties of the implemented solution.

54 6 gRPC Layer for Kentico Kontent

This chapter brings an overview of published API migrations from REST to gRPC and the suggestions they provide. Design and implementation of gRPC API, which would be an appropriate alternative for Kentico Kontent Delivery API is described. After that, a client application communicating with the implemented gRPC API is designed and built. This chapter also analyses utilizing gRPC in the client-server communication with Kentico Kon- tent Delivery API, within comparison to the currently used HTTP REST API.

6.1 Migration from REST Architecture to gRPC

Many significant companies, such as Dropbox and Spotify, havemi- grated their REST services to gRPC. For Dropbox, the reason for migration was a promise of multiplexing, HTTP/2 transport and bidirectional streaming [66]. Spotify was utilizing RPC similar framework with protobuf, then they decided to migrate to Kubernetes (system for automated application deployment, scaling, and management main- tained by Cloud Native Computing Foundation), then they decided to migrate to gRPC and their CPU utilization improved 2-3 times [67]. One approach for the migration is utilizing of gRPC-Gateway protocol buffer compiler (protoc) plugin. Firstly, the gRPC application has to be implemented and then the plugin generates a reverse-proxy server, that translates REST API into gRPC. The server is generated according to the google.api.http annotations in the service definitions [68]. The advantage of the plugin utilization is a coexistence of the original REST the new gRPC calls, which allows all communications to be gradually migrated to gRPC, maintaining of backward compati- bility and support of languages that are not supported by gRPC [69, 68]. Another approach, that was chosen by WePay company, is running the gRPC server as a new application that uses the original REST framework [69].

55 6. gRPC Layer for Kentico Kontent 6.2 Design of gRPC Content Delivery Layer in Kentico Kontent

From the server point of view, it is important to keep the existing functionality. The top layer of the tiered back-end application is substituted by a layer communicating by gRPC protocol. Newly created .proto files have to include all endpoint methods as services and all request and response objects as messages. The new gRPC feature is included in the diagram of the Kentico Kontent APIs structure in Figure 2.2 marked with red color.

6.2.1 Models It is needed to create alternative protobuf models for all objects sent by the original HTTP REST API. As most of the original objects have JObject type, which represents a JSON object and it is not strictly typed, new gRPC models have to be designed with a knowledge of the content of the original API responses and to imitate their structure. Because of the differences between gRPC generated models and models returned from services in the original REST API, a converter between types returned from lower services to types used by gRPC API has to be implemented. Also, some objects have to be altered - mostly objects created as an extension of another object in the original code, as the proto3 standard does not support object extensions. There is also an option of utilizing response and request message metadata to include a variety of information, for example information usually contained in the traditional HTTP REST URL, such as item‘s id or codename.

6.3 API Implementation Details

Since the implementation of Kentico Kontent back-end is written in C#, this language is also used as an implementation language of gRPC API. Currently, Delivery API uses .NET Framework, however, gRPC services are supported only in .NET Core. In order to keep the previous functionality, e.g. gathering data from the Cosmos DB client, a part of the original files had to be rewrit-

56 6. gRPC Layer for Kentico Kontent

ten into code using .NET Core libraries instead of .NET Framework ones (for example Microsoft.Azure.DocumentDB.Core instead of Mi- crosoft.Azure.DocumentDB). As it is planned to rewrite the whole solution of the API to the .NET Core in the near future, the future solution will be unified again using the .NET Core libraries.

There are two implementations of gRPC libraries for using gRPC in .NET and C#. The older one - gRPC core-library (also known as gRPC for C#) and newer - gRPC for .NET. The implementations coexist next to each other without any future plans to replace one implementation with the other one. For frameworks that do not support gRPC for .NET, it is recommended to use the older gRPC for C# library. In the implementation of new gRPC services gRPC for C# was utilized.

The structure of the original HTTP and newly created gRPC API is displayed in Figure 6.1.

6.4 Server Application Run

gRPC alternative content delivery services run for now locally, until they will be included in the production version of the application. gRPC API runs on Kestrel Web Server - event-driven, asynchronous, multi-platform, I/O-based server used to host ASP.NET applications.

6.5 Client Application

From the intersection of the previous analysis of gRPC usability, performance, and the other key gRPC properties described in Chapter 5 and the concept of omnichannel content delivery, the mobile application seems to be a domain where it would be an enhancement to use gRPC for the communication between client and the server. In order to prove the real communication of the gRPC server with a client, a sample Android mobile application was implemented to communicate with Kentico Kontent server by both HTTP and gRPC calls. The application is designed to run on Android system version Oreo 8.0 (API level 26) or higher. For calls directed to the original REST

57 6. gRPC Layer for Kentico Kontent

API, the application utilizes Kontent Delivery Java SDK 1. Screenshots of the mobile application are included in Appendix D. The .proto files have to be the same as the server’s file, sothe communicating sides have the same contract. The essential libraries utilized for the gRPC part of the implementation are listed in Appendix B. The bottom layer of the mobile application is created by gRPC and HTTP repositories. Moreover, thw gRPC repository is connected to the Stub object, which represents a connection to the server’s service defined by the same .proto file. The repositories provide data gathered from the API endpoints to the rest of the application functionality. This structure is depicted in Figure 6.1.

Figure 6.1: Structure of gRPC and HTTP Kentico Kontent Delivery API communicating locally with client mobile application

1. https://github.com/Kentico/kontent-java-packages/tree/master/ kontent-delivery

58 6. gRPC Layer for Kentico Kontent 6.6 Experiments

Delivery API communicates with Fastly CND in order to improve the load times of the user application. The CDN was omitted in the communication of both gRPC and HTTP REST API in order to monitor the differences in the speed of the communication without any cashing. In order to have execution times spent only for end-to-end communication between the client and the server and not for database connection and data serialization, communicated data were mocked on the server side. Also, the application runs locally, so the network latency and possible communication problems are eliminated. For requesting and measuring message size and execution time of HTTP REST API, Postman2 tool was used. As this program does not support gRPC-based calls, Kreya3 was chosen for testing gRPC API. On the other hand, Kreya does not support other than gRPC calls, so it was not possible to use a single tool for testing both APIs.

6.6.1 Server Device Details Server Device for API Measurements The server side runs locally on the computer with 64-bit operating system, x64-based processor - Windows 10, with Intel Core i7-7700 CPU @ 3.60GHz and 32.0 GB RAM.

6.6.2 Measurements Both APIs were requested and the time of the communication was compared. The endpoints of both APIs return mocked data and they run locally. No additional time is included in the total time, such as database calls, network latency, models converting, etc. Firstly, both gRPC (requested from Kreya) and original HTTP server (requested from Postman) were called 100 times with the same requests and the overall execution time of the request-response com-

2. https://www.postman.com/ 3. https://kreya.app/

59 6. gRPC Layer for Kentico Kontent munication was calculated. Also, request and response message size were measured. The benchmarked endpoint GetItems was requested and 3 scenarios of response size were tested - the responses containing 10, 100, and 500 items. HTTP variant returned ItemsModel (extending ResponseModel) model and ResponseModel (including ItemsModel) was returned by gRPC variant. Median results of message execution times in the 3 measured scenarios are displayed in Table 6.2, a comparison of the measured execution times is pictured in the graph in Figure 6.2. Sizes of the request and response messages are summarised in Table 6.1.

Table 6.1: Size of gRPC and HTTP requests and responses containing 10, 100, or 500 items retrieved from GetItems endpoints

Measurement gRPC HTTP Request size 38 B 244 B (only headers) Response size (10 items) 8 160 B 14 560 B (13 912 B body, 648 B headers) Response size (100 items) 77 590 B 138 670 B (138 022 B body, 648 B headers) Response size (500 items) 386 160 B 706 793 B (706 145 B body, 648 B headers) Blue cells represent cases where the gRPC messages have a smaller size than HTTP messages.

Table 6.2: Median of the measured speed of responses containing 10, 100, or 500 items retrieved from gRPC and HTTP GetItems endpoints

Message payload gRPC HTTP 10 items 10 ms/request 6 ms/request 100 items 20 ms/request 18 ms/request 500 items 51 ms/request 74.5 ms/request Blue cells represent cases where the gRPC messages are faster than HTTP ones, red cells represent slower cases.

60 6. gRPC Layer for Kentico Kontent

Figure 6.2: Comparison of execution times of gRPC and HTTP messages

6.7 Analysis of gRPC Integration into Kentico Kontent Delivery API

For analysis of gRPC integration into Kentico Kontent Delivery API, the methodology of GQM was used. This approach is described in detail in Section 5.1.

6.7.1 Stated GQM Goal 1: Show performance benefits of using gRPC in comparison with HTTP in Delivery API.

Q1: Are gRPC messages faster than HTTP REST? Q2: Are gRPC messages more efficient than REST HTTP?

61 6. gRPC Layer for Kentico Kontent

M1: Speed of the request-response exchange using gRPC to the gRPC Delivery API (in ms) M2: Speed of the request-response exchange using HTTP to the original Delivery API (in ms) M3: Size of the response and request messages in gRPC communication (in B) M4: Size of the response and request messages in HTTP communication (in B)

6.7.2 Evaluation of the Stated GQMs

G1: Show performance benefits of using gRPC in comparison with HTTP in Delivery API.

Metrics M1 and M2 evaluating the speed of the requests are displayed in Table 6.2 and the graph displayed in Figure 6.2. Size-oriented metrics M3 and M4 are evaluated in Table 6.1.

Q1: Are gRPC messages faster than HTTP REST? - According to Table 6.2, the gRPC request-response exchange was slower for small messages containing 10 items. Speed of gRPC messages approached the speed of HTTP messages when their load contained 100 items. With the increasing size of the payload (for example 500 items), gRPC reached better speed results than HTTP.

Q2: Are gRPC messages more efficient than REST HTTP? - Comparing the size of messages (especially responses) containing the same data, Table 6.1 shows that there is a big difference between gRPC and the original HTTP messages. Thanks to the binary serialization, gRPC messages are much more efficient in size, they have approximately a half-size of HTTP responses in all of the measured scenarios.

62 6. gRPC Layer for Kentico Kontent

Finding: Measurements of gRPC and HTTP messages with the same payload showed, that gRPC messages are more size efficient than HTTP messages. HTTP messages were faster in scenarios with a smaller payload, however, the speed of gRPC messages was higher in scenarios with larger payload (500 items included in the payload).

6.7.3 Conclusion of the Analysis of the Experimental Work gRPC as a new alternative of the existing Kentico Kontent API did confirm the assumptions of faster messages in the client-server communication, that were presented before in Section 4.5. The benefit of gRPC‘s higher speed shows up with the increasing size of the payload. The gRPC messages were significantly size efficient in comparison with the HTTP messages, which confirmed the previous assumptions.

6.8 Summary

Details of gRPC Delivery API design and .NET Core implementation were described in this chapter. Also, a procedure of new gRPC models defined by .proto files was introduced. In addition, this chapter gave an answer to Goal 2 of this thesis stated in Section 1.2. A sample application which communicates with endpoints of both the newly implemented gRPC API and the original HTTP API was designed and implemented. After that, the experimental work was evaluated according to GQM methodology and properties of the newly created and original APIs were compared. The last part of this chapter answered Goal 3 stated in Section 1.2.

7 Conclusion

The thesis focused on an alternative content delivery layer for the CMS system Kentico Kontent utilizing gRPC as a message exchange protocol. The theoretical part of this thesis described headless CMS Kentico Kontent and its capabilities of content delivery. After that gRPC was analyzed from the view of various scenarios, such as API, mobile, web, and IoT application development, and its properties, e.g. design, performance, developer experience, reliability. The biggest strengths of gRPC are its efficient messages and speed of the message exchange, but also the given option of bidirectional streaming communication. From the intersection of Kentico Kontent content delivery demands and gRPC properties from the previous analysis, mobile applications seem like an ideal client for utilizing gRPC from the view of omnichannel content delivery. Then, the gRPC layer for Kentico Kontent Delivery API was designed and implemented as an alternative endpoint to the existing REST API. A mobile application was built as an example of an application exchanging gRPC messages with the implemented API. Properties of the implemented gRPC endpoint, such as size and speed of the messages, were analyzed and compared to the original HTTP endpoint. The results of the analysis confirmed previous statements about gRPC advantages.

7.1 Results of the Thesis Goals

The following goals were stated in the introduction of this thesis in Section 1.2.

Goal 1: Analyze various aspects of gRPC from the view of performance, security, reliability, and developer experience for different target channels (web, IoT, mobile, etc.) and show scenarios where gRPC excels.

This goal was reached in Chapter 5 according to the relevant studies and documentations. The most viable scenario is represented by

65 7. Conclusion mobile and IoT applications communicating with gRPC messages with the server and they promise more efficient messages and faster communication.

Goal 2: Propose design and implementation of an alternative content delivery layer for Kentico Kontent Delivery API.

Design of gRPC Kentico Kontent API was proposed and implementation was described in Chapter 6. The gRPC API keeps the functionality of the original HTTP API. The key point of the gRPC development is the design of .proto files including messages and services, as they define a contract of the whole communication. These files have tobe shared between communicating sides.

Goal 3: Analyze implemented Kentico Kontent‘s gRPC Delivery API.

The newly added gRPC layer for content delivery in Kentico Kon- tent was analyzed in Chapter 6, Section 6.7. A prototype of a client application communicating with the gRPC API was implemented and also utilized for the analysis. gRPC communication brings a benefit in the speed of the communication with larger message loads. In all cases, the messages have a smaller size than the original HTTP messages.

7.2 Future Work

An interesting future improvement of the gRPC API would be the utilization of streaming communication, which is a unique feature of gRPC. The next step of the implementation can be the usage of a server reflection, so the client applications do not have to have a knowledge of the used .proto files, because they would be provided by the server. Also, a measurement of battery consumption in mobile devices while using gRPC and HTTP Delivery API would be an interesting subject. After production deployment of the gRPC Delivery API, Fastly CDN may be included in the communication between the server and a client to decrease latency in the communication. This improvement is marked in Figure 2.2 with a red dashed line.

66 Bibliography

1. KONEČNÝ, Roman. Building a Cloud - first Headless CMS [online]. Kentico Software [visited on 2020-07-11]. Available from: https: //kontent.ai/blog/building-cloud-first-headless-cms. 2. About gRPC [online]. gRPC Authors [visited on 2020-07-11]. Available from: https://grpc.io/about/. 3. Content management system (CMS) [online]. TechTarget [visited on 2020-09-05]. Available from: https://searchcontentmanagement. techtarget.com/definition/content- management- system- CMS. 4. KARLÍK, Radoslav. Blogging Platform utilizing Kentico Cloud Jekyll Static Site Generator [online]. 2020. Master’s thesis. Masaryk Uni- versity, Faculty of Informatics, Brno. Supervised by Bruno ROSSI. 5. PALAS, Petr. What Is a Cloud-first Headless CMS? [online]. Ken- tico Kontent [visited on 2020-11-17]. Available from: https:// kontent.ai/blog/what-is-headless-cms. 6. NOSEK, Tomáš. Web Spotlight [online]. Kontent Docs [visited on 2020-11-17]. Available from: https://docs.kontent.ai/ tutorials / set - up - kontent / set - up - your - project / web - spotlight. 7. CHAPEL, Jay. SaaS vs. PaaS vs. IaaS — Where the Market is Going [online]. Medium [visited on 2020-11-11]. Available from: https: //jaychapel.medium.com/saas-vs-paas-vs-iaas-where-the- market-is-going-fcc46771731d. 8. GODSE, Manish; MULIK, Shrikant. An approach for selecting software-as-a-service (SaaS) product. In: 2009 IEEE International Conference on Cloud Computing. 2009, pp. 155–158. 9. ZHU, Yangpeng; ZHANG, Jing. Research on key technology for SaaS. In: 2012 7th International Conference on Computer Science & Education (ICCSE). 2012, pp. 207–210.

67 BIBLIOGRAPHY

10. PALAS, Petr. Moving to Content as a Service with Kentico Kontent [online]. Kentico Software [visited on 2020-07-11]. Available from: https : / / kontent . ai / blog / moving - to - caas - with - kentico-kontent. 11. Content Strategy Glossary [online]. Kentico Kontent [visited on 2020-10-10]. Available from: https://kontent.ai/glossary. 12. ANDREWS, Michael. How Is CaaS Different from Conventional Web Content Management? [online]. Kentico Software [visited on 2020- 07-13]. Available from: https://kontent.ai/blog/how- is- caas-different-from-conventional-wcm. 13. ANDREWS, Michael. The Importance of the Content-as-a-Service Mindset [online]. Kentico Software [visited on 2020-07-11]. Avail- able from: https://kontent.ai/blog/the- importance- of- the-content-as-a-service-mindset. 14. WINKLER, Nick. Omnichannel vs Multichannel: What is the Differ- ence and Why Does It Matter? [online]. Shopify [visited on 2020- 11-09]. Available from: https://www.shopify.com/enterprise/ omni-channel-vs-multi-channel. 15. Multi-Channel Marketing: Definition, Data, and a Strategy to Sell Anywhere [online]. Shopify [visited on 2020-11-10]. Available from: https://www.shopify.com/enterprise/multi-channel- marketing. 16. Delivery API [online]. Kentico Kontent [visited on 2020-10-04]. Available from: https://docs.kontent.ai/reference/deliveryapi. 17. Kentico Kontent APIs overview [online]. Kentico Kontent [visited on 2020-11-13]. Available from: https://docs.kontent.ai/ reference/kentico-kontent-apis-overview. 18. Get Content Items [online]. Kentico Docs [visited on 2020-08- 31]. Available from: https://docs.kontent.ai/tutorials/ develop - apps / get - content / get - content - items ? tech = dotnet. 19. Management API v2 [online]. Kentico Kontent [visited on 2020- 11-13]. Available from: https://docs.kontent.ai/reference/ management-api-v2.

68 BIBLIOGRAPHY

20. CDN Performance [online]. Cloudflare, Inc. [visited on 2021-02- 25]. Available from: https://www.cloudflare.com/learning/ cdn/performance/. 21. What is the Difference Between an API and an SDK? [online]. Nordic APIs AB [visited on 2020-09-05]. Available from: https://searchcontentmanagement. techtarget.com/definition/content- management- system- CMS. 22. GILLIES, James M; GILLIES, James; CAILLIAU, R, et al. How the Web was born: The story of the World Wide Web. Oxford University Press, USA, 2000. 23. HAFNER, Katie; LYON, Matthew. Where wizards stay up late: The origins of the Internet. Simon and Schuster, 1998. 24. LICKLIDER, Joseph Carl Robnett; CLARK, Welden E. On-line man-computer communication. In: Proceedings of the May 1-3, 1962, spring joint computer conference. 1962, pp. 113–128. 25. LEINER, Barry M; CERF, Vinton G; CLARK, David D; KAHN, Robert E; KLEINROCK, Leonard; LYNCH, Daniel C; POSTEL, Jon; ROBERTS, Larry G; WOLFF, Stephen. A brief history of the Internet. ACM SIGCOMM Computer Communication Review. 2009, vol. 39, no. 5, pp. 22–31. 26. FROEHLICH, Fritz E; KENT, Allen. The Froehlich/Kent Encyclo- pedia of Telecommunications: Volume 10 - Introduction to Computer Networking to Methods for Usability Engineering in Equipment De- sign. CRC Press, 1995. 27. CHOUDHURY, Nupur. World wide web and its journey from web 1.0 to web 4.0. International Journal of Computer Science and Information Technologies. 2014, vol. 5, no. 6, pp. 8096–8100. 28. BERNERS-LEE, Timothy J; CAILLIAU, Robert. WorldWideWeb: Proposal for a HyperText project. 1990. Available also from: https: //www.w3.org/Proposal.html. 29. BERNERS-LEE, Tim. The World Wide Web: A very short personal history. 1998. Available also from: https://www.w3.org/People/ Berners-Lee/ShortHistory.html. 30. O’REILLY, Tim. What is web 2.0. O’Reilly Media, Inc., 2009.

69 BIBLIOGRAPHY

31. SPIVACK, Nova. Web 3.0: The Third Generation Web is Coming [online] [visited on 2020-11-23]. Available from: https://lifeboat. com/ex/web.3.0. 32. ALMEIDA, Fernando Luis. Concept and dimensions of web 4.0. International Journal of Computers & Technology. 2017, vol. 16, no. 7, pp. 7040–7046. 33. When to Use What: REST, GraphQL, Webhooks, gRPC [online]. gRPC Authors [visited on 2020-11-27]. Available from: https:// nordicapis.com/when-to-use-what-rest-graphql-webhooks- grpc/. 34. FIELDING, Roy; GETTYS, Jim; MOGUL, Jeffrey; FRYSTYK, Hen- rik; MASINTER, Larry; LEACH, Paul; BERNERS-LEE, Tim. Hy- pertext transfer protocol–HTTP/1.1. RFC 2616, 1999. 35. BELSHE, Mike; PEON, Roberto; THOMSON, Martin. Hypertext transfer protocol version 2 (http/2). RFC 7540, 2015. 36. GHEDINI, Alessandro; LALKAKA, Rustam. HTTP/3: the past, the present, and the future [online]. Cloudfare [visited on 2020- 11-26]. Available from: https://blog.cloudflare.com/http3- the-past-present-and-future/. 37. BISHOP, Mike et al. Hypertext transfer protocol version 3 (HTTP/3). Internet Engineering Task Force, Internet-Draft draft-ietf-quic-http- 24. 2019. 38. NELSON, Bruce Jay. Remote Procedure Call. Carnegie Mellon Uni- versity, 1981. PhD thesis. 39. HEINDEL, Lee E; KASTEN, Vincent A. Highly reliable synchronous and asynchronous remote procedure calls. In: Conference Proceed- ings of the 1996 IEEE Fifteenth Annual International Phoenix Con- ference on Computers and Communications. 1996, pp. 103–107. 40. RYAN, Louis. gRPC Motivation and Design Principles [online]. gRPC Authors [visited on 2020-07-11]. Available from: https: //grpc.io/blog/principles/. 41. gRPC Project is now 1.0 and ready for production deployments [online]. gRPC [visited on 2020-11-12]. Available from: https:// grpc.io/blog/ga-announcement/.

70 BIBLIOGRAPHY

42. Is gRPC better than REST? Where to use it? [online]. DEV COm- munity [visited on 2020-11-27]. Available from: https://dev. to/techschoolguru/is-grpc-better-than-rest-where-to- use-it-3blg. 43. MASTRANGELO, Carl. Visualizing gRPC Language Stacks [online]. gRPC [visited on 2020-12-07]. Available from: https:// grpc.io/blog/grpc-stacks/. 44. NEWTON-KING, James. Compare gRPC services with HTTP APIs [online]. Microsoft [visited on 2020-07-11]. Available from: https: //docs.microsoft.com/en-us/aspnet/core/grpc/comparison? view=aspnetcore-3.0. 45. JEAN, de Klerk. gRPC on HTTP/2 Engineering a Robust, High- performance Protocol [online]. gRPC [visited on 2021-02-23]. Avail- able from: https://grpc.io/blog/grpc-on-http2/. 46. Compare gRPC services with HTTP APIs [online]. Microsoft [visited on 2021-03-08]. Available from: https://docs.microsoft. com/en-us/aspnet/core/grpc/comparison?view=aspnetcore- 5.0. 47. Error handling [online]. gRPC Authors [visited on 2020-11-27]. Available from: https://grpc.io/docs/guides/error/. 48. FAQ - Who’s using this and why? [online]. gRPC Authors [visited on 2020-11-12]. Available from: https://grpc.io/faq/#whos- using-this-and-why. 49. JAMSHIDI, Pooyan; PAHL,Claus; MENDONÇA, Nabor C; LEWIS, James; TILKOV, Stefan. Microservices: The journey so far and challenges ahead. IEEE Software. 2018, vol. 35, no. 3, pp. 24–35. 50. SAARINEN, Aki; SIEKKINEN, Matti; XIAO, Yu; NURMINEN, Jukka K; KEMPPAINEN, Matti; HUI, Pan. Can offloading save energy for popular apps? In: Proceedings of the seventh ACM international workshop on Mobility in the evolving internet architecture. 2012, pp. 3–10.

71 BIBLIOGRAPHY

51. CHAMAS, C. L.; CORDEIRO, D.; ELER, M. M. Comparing REST, SOAP, Socket and gRPC in computation offloading of mobile applications: An energy cost analysis. In: 2017 IEEE 9th Latin- American Conference on Communications (LATINCOM). 2017, pp. 1– 6. Available from DOI: 10.1109/LATINCOM.2017.8240185. 52. ARAÚJO, Mateus; MAIA, Marcio; REGO, Paulo; SOUZA, Jose de. Performance analysis of computational offloading on embedded platforms using the gRPC framework. In: 8th International Workshop on ADVANCEs in ICT Infrastructures and Services (AD- VANCE 2020). 2020, pp. 1–8. 53. RUWAN, Fernando. Evaluating Performance of REST vs. gRPC [online]. Medium [visited on 2021-03-09]. Available from: https: / / medium . com / @EmperorRXF / evaluating - performance - of - rest-vs-grpc-1b8bdf0b22da. 54. LEUNG, Matthew. gRPC vs REST — performance comparison [online]. Medium [visited on 2021-04-14]. Available from: https:// medium.com/analytics-vidhya/grpc-vs-rest-performance- comparison-1fe5fb14a01c. 55. YONEGO. Why milliseconds matter [online] [visited on 2021-04- 14]. Available from: https://www.yonego.com/nl/blogs/why- milliseconds-matter/. 56. INDRASIRI, kasun; KURUPPU, Danesh. gRPC: Up and Running. O’Reilly Media, 2020. ISBN 978-1-492-05833-5. 57. Authentication [online]. gRPC Authors [visited on 2020-10-17]. Available from: https://grpc.io/docs/guides/auth/. 58. GHALI, Cesar; STUBBLEFIELD, Adam; KNAPP, Ed; JIANG- TAO, Li; SCHMIDT, Benedikt; BOEUF, Julien. Application Layer Transport Security [online]. Google Cloud [visited on 2020-10- 17]. Available from: https://cloud.google.com/security/ encryption - in - transit / application - layer - transport - security. 59. DAVIS,Doug et al. Web services reliable messaging (WS-ReliableMessaging) Version 1.1. Technical report, OASIS. 2008.

72 BIBLIOGRAPHY

60. DEVELOPERS, Google. Protocol Buffers - Language Guide (proto3) [online]. Google Developers [visited on 2020-08-05]. Available from: https://developers.google.com/protocol-buffers/ docs/proto3. 61. Introduction to gRPC [online]. gRPC Authors [visited on 2020-08- 05]. Available from: https://grpc.io/docs/what-is-grpc/ introduction/. 62. DEVELOPERS, Google. Protocol Buffers - Language Guide [online]. Google Developers [visited on 2020-08-05]. Available from: https: //developers.google.com/protocol-buffers/docs/proto. 63. CAO, David. Mobile Benchmarks [online] [visited on 2021-04-16]. Available from: https://grpc.io/blog/mobile-benchmarks/. 64. Core concepts, architecture and lifecycle [online]. gRPC Authors [visited on 2020-11-27]. Available from: https : / / grpc . io / docs/what-is-grpc/core-concepts/. 65. BASILI, Victor R.; CALDIERA, Gianluigi; ROMBACH, H Dieter. The goal question metric approach. Encyclopedia of software engineering. 1994, pp. 528–532. 66. Courier: Dropbox migration to gRPC [online]. Dropbox [visited on 2020-11-13]. Available from: https://dropbox.tech/infrastructure/ courier-dropbox-migration-to-grpc. 67. An early adopter of containers, Spotify is migrating from homegrown orchestration to Kubernetes [online]. Cloud Native Computing Foun- dation [visited on 2020-11-13]. Available from: https://www. cncf.io/case-studies/spotify/. 68. gRPC-Gateway [online]. GitHub [visited on 2021-05-11]. Avail- able from: https://github.com/grpc-ecosystem/grpc-gateway. 69. REZAEI, Mohsen; SUBRAMANI, Dinesh. Migrating APIs from REST to gRPC at WePay [online] [visited on 2021-05-11]. Avail- able from: https : / / wecode . wepay . com / posts / migrating - apis-from-rest-to-grpc-at-wepay.

A Electronic Attachments

The following files are attached as electronic attachments:

∙ DeliveryApi.Grpc - important parts of the gRPC Kentico Kontent Delivery API1

∙ MobileApp - Android mobile application utilizing both gRPC and HTTP connection to the Delivery API

∙ ProtoTypes directory - .proto files defining the communication via gRPC

∙ README.txt - description of the provided attachments in detail

1. Only a newly added project files without configurations are included, as therest is a part of the production code of Kentico Kontent.

B Utilized Tools and Configurations

This chapter describes programs, tools and configurations that were used in the implementation part of this thesis.

B.1 C# Implementation of gRPC API

However the Kontent Delivery API is currently implemented in .NET Framework, it was needed to use .NET Core (.NET5) for the implementation of the gRPC service. The gRPC libraries work well with .NET Framework, but the endpoint service is not supported in .NET Framework. .NET Core service works well with the rest of the Delivery API solution. NuGet packages necessary for gRPC API implementation: ∙ gRPC - gRPC library for C# framework

∙ Grpc.Tools - contains protoc and protobuf binaries required for C# code generation according to .proto files and also allows au- tomatic code generation through the integration with MSBuild

∙ Google.Protobuf - Protocol buffer from Google for serializing structured data

∙ Google.Apis.CommonProtos - includes definition of the most common messages used in the API implementation

B.2 Client Android Application

Client Android mobile application communicating with the Delivery API is implemented in Kotlin. This application supports both gRPC and HTTP calls. For calls directed to the original REST API, it uses Kon- tent Delivery Java SDK 1. Classes are generated from .proto definition after building the project. Dependencies necessary for the gRPC part of the implementation:

1. https://github.com/Kentico/kontent-java-packages/tree/master/ kontent-delivery

77 B. Utilized Tools and Configurations

∙ grpc-protobuf-lite

∙ protobuf-javalite

∙ grpc-stub

Protobuf compiler was used in the lite mode, which is more suitable for applications run on resource-constrained systems, such as mobile phones. This mode enables protoc to generate smaller and high performance-classes.

B.3 API Testing

For requesting existing HTTP REST API, Postman2 tool was used. As this program does not support gRPC-based calls, Kreya3 was chosen for testing gRPC API. On the other hand, Kreya does not support anything other than gRPC calls, so it was not possible to use a single tool for testing APIs.

2. https://www.postman.com/ 3. https://kreya.app/

78 C Sample Code

C.1 items_service.proto syntax = "proto3";

package deliveryApi.grpc;

option csharp_namespace = "deliveryApi.grpc";

import "models/response_model.proto";

service ItemsService { rpc GetItem(.deliveryApi.grpc.ItemsServiceRequest) returns (ResponseModel); rpc GetItems(.deliveryApi.grpc.ItemsServiceRequest) returns (ResponseModel); rpc GetItemsFeed(.deliveryApi.grpc.ItemsServiceRequest) returns (ResponseModel); }

message ItemsServiceRequest { string project_id = 1; string codename = 2; }

D Mobile Application Details

A sample Android mobile application was implemented to communicate with the Kentico Kontent server by both HTTP and gRPC calls. The application is designed to run on Android system version Oreo 8.0 (API level 26) or higher. The main menu provides 2 options:

∙ Connect to the Delivery API, gather and display the items. Id of the project has to be defined in the Constants class asa PROD_PROJECT_ID variable.

∙ Connect to the gRPC Delivery API running locally, gather and display the items. Id of the project has to be defined in the Constants class as a GRPC_PROJECT_ID variable.

81 D. Mobile Application Details D.1 Application Screenshots

Figure D.1: Main screen of the implemented Android application

82 D. Mobile Application Details

(a) HTTP (b) gRPC

Figure D.2: Screen of the implemented Android application displaying data from gRPC and HTTP GetItems endpoints