Masaryk University Faculty of Informatics Using GraphQL for Content Delivery in Kentico Cloud Bachelor’s Thesis David Čechák Brno, Fall 2017 Masaryk University Faculty of Informatics Using GraphQL for Content Delivery in Kentico Cloud Bachelor’s Thesis David Čechák Brno, Fall 2017 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. David Čechák Advisor: Bruno Rossi, PhD i Acknowledgement I would like to thank my advisor Ph.D. Bruno Rossi for helpful and proactive suggestions, to Kentico Software company for the opportu- nity work on this thesis with their guidance, especially to Jiří Kusák for advice regarding the practical part of the thesis. I also owe my gratitude to my family and friends for their support. iii Abstract The goal of the thesis is to research GraphQL technology as a possible alternative to Kentico Cloud’s Delivery API. The current API is based on RESTful principles. The thesis is divided into four parts. In the beginning is explained the current state of Delivery API and how Kentico Cloud’s data are structured. The second part compares REST and GraphQL concepts and explores possibilities of incorporating GraphQL API. It considers databases and approaches that could han- dle both. Next chapter describes implementation of proof of concept solution, which is based on the previous analysis. The last chapter breaks down conducted measurement and presents its results. iv Keywords GraphQL, content delivery, JavaScript, Node.js, Kentico Cloud Deliv- ery, cloud-first headless CMS v Contents 1 Introduction 1 2 How Kentico Cloud delivers content 3 2.1 CMS introduction ......................3 2.1.1 Managed cloud hosting . .3 2.1.2 Platform as a Service . .3 2.1.3 Software as a Service . .3 2.1.4 Headless CMS . .4 2.2 Kentico Cloud .........................4 2.3 Data description ........................5 2.4 Current storage ........................6 2.5 Database data structure ....................7 2.5.1 Content item . .7 2.5.2 Content type and taxonomy . .9 2.6 Delivery API ......................... 10 3 Analysis 13 3.1 REST ............................. 13 3.1.1 Six constraints . 13 3.1.2 Limitations . 14 3.2 GraphQL ........................... 14 3.2.1 Schema . 15 3.2.2 Introspection . 16 3.2.3 Operations . 16 3.2.4 Adjustability . 16 3.2.5 GraphiQL . 17 3.3 GraphQL and REST comparison ............... 17 3.3.1 Get the entire entity . 18 3.3.2 Versioning . 18 3.3.3 Endpoints architecture . 19 3.4 Possible database models ................... 20 3.4.1 NoSQL . 20 3.4.2 Graph-based . 21 3.4.3 Multi-model database . 21 3.5 Azure Cosmos DB ...................... 22 vii 3.5.1 DocumentDB . 22 3.5.2 GraphDB . 23 3.5.3 DocumentDB API and Gremlin to query GraphDB 23 3.6 Selected solution ....................... 24 4 Implementation 25 4.1 Description of used technologies ............... 25 4.1.1 Javascript with Node.js . 25 4.1.2 Package manager npm . 25 4.2 How to use the application .................. 26 4.2.1 Prerequisites . 26 4.2.2 Startup instructions . 26 4.2.3 Inline fragments . 27 4.3 Drawbacks ........................... 28 5 Measurement 31 5.1 Selection of measurement metrics and test samples ..... 31 5.2 Results ............................ 32 5.2.1 Batching queries . 33 6 Conclusion 37 6.1 Summarization of the work accomplished .......... 37 6.2 Possible further improvements and steps required for a suc- cessful integration ....................... 37 Bibliography 39 A Attached content 45 viii List of Tables 5.1 Delivery API dataset details. 32 5.2 GraphQL - whole item dataset details. 33 5.3 GraphQL - partial item dataset details. 34 5.4 Test results (columns in ms stand for response time). 34 ix List of Figures 2.1 Top level fields of a content item. 7 2.2 Fields of "elements" field part 1. 8 2.3 Fields of "elements" field part 2. 9 3.1 An example GraphQL query. 17 4.1 A query sent to GraphQL server using Postman application. 27 4.2 A query with inline fragments. 29 4.3 A response to the query with inline fragments. 30 5.1 GraphQL query in disjunctive form. 35 xi 1 Introduction Software development methodologies, as well as software architec- tures are continually evolving. In the modern software development environment emerges a need for more flexible and customer oriented approach. Agile methodologies take over the software development world at the expense of older methods, for example, the waterfall model. Fast pivoting of a product based on new discoveries made during development is necessary to keep up with competition. Another factor is that the Internet is expanding into a wide variety of devices like smartphones, tablets, Internet of Things (IoT) devices and more. And the data flows through diverse network infrastructures. Mobile networks are common and with them a need to minimize the users consumption of data, for financial and performance reasons. In light of these facts an idea for GraphQL emerged. Especially mo- bile applications significantly suffer from a decreasing performance with an increasing complexity. GraphQL development started in Face- book as a solution to increasing complexity of their mobile application and other issues mentioned above [1]. Kentico Cloud is a CMS system. It provides users with its RESTful Delivery API. This thesis aims to examine GraphQL as an alternative to it. Its goal is to find out what adjustments would be necessary for a successful integration of GraphQL. In Chapter 3 is an analysis of possible solutions and approaches to this endeavor with a decision, how a proof of concept solution should be implemented. Chapter 4 breaks down concepts used in implementation and puts together a basic guide explaining how to use it. This solution is tested in last chapter. There is a list of metrics used for the experiment and an explanation why these metrics were selected. Kentico Cloud is used by other applications as a source of con- tent. It is a layer upon which these applications are dependent. Their performance is highly influenced by it. Therefore it is important to optimize it as much as possible. 1 2 How Kentico Cloud delivers content 2.1 CMS introduction A content management system(CMS) is a computer application for developers, marketers, content creators and other people involved in a production of websites, online stores, intranets or community sites. It makes it easier for them to develop it, manage the workflow of content publication and manage user roles and their access levels during the process [2, 3]. As this thesis revolves around Cloud CMS, in the next section are itemized ways how to move CMS functionality into the cloud. 2.1.1 Managed cloud hosting Managed cloud hosting is a CMS installed in the cloud mostly man- aged manually by the provider. It has the same needs. To make the product more appealing, vendor can take care of all the upgrades, hotfixes, security, backup and other issues. This is called managed cloud hosting. It lacks flexibility as typically the user has to contact the vendor and ask for deploying new changes to their production environment [4]. 2.1.2 Platform as a Service These problems can be solved using highly automated environments that with self-service configuration and deployment. It is called Plat- form as a Service (PaaS). Unfortunately, this approach also has its weaknesses. Users do not have full control over the hosting environ- ment. In addition, they still have to test if their website is not broken after every upgrade [4]. 2.1.3 Software as a Service Kentico Cloud CMS is an application built as Software as a Service(SaaS). As such it has some noticeable benefits over the models mentioned be- fore. The application runs on a server and it is completely maintained by the providing company. Users access it through a web browser. 3 2. How Kentico Cloud delivers content They do not have to be worried about updating their CMS applica- tion as with classic CMS installed on their computers. It is also called cloud-first1. Chiefly it runs as a multi-tenant SaaS service meaning all the users run the same version of the application and the provider manages only one standardized environment. This makes the job for the provider a lot easier [4]. 2.1.4 Headless CMS With traditional rigid CMS users often have to rewrite their code into a format defined by CMS. But modifying the code requires users to invest additional time and the application template they have to follow restricts them. It can be solved by using headless CMS(API-first CMS). This architecture cuts off the presentation layer, leaving the front-end part on the user and only provides the content for it through its application programming interface (API). Basically, it is an API to retrieve, work with and display data to populate a website or mobile application with. The API makes the content available on any of the various devices that are used nowadays (smartphones, virtual reality, IoT). Users can write their website or mobile application using any programming language and they can use their own development process. They only have to exchange their static code for the dynamic data obtained using the API. Thus using the CMS does not require to change the structure of their code as it happens in other non-headless models.