GraphQL is a query language for web APIs and a service for carrying out server requeststo interact with the data from the API. Research show that even for simple GraphQL queriesboth the size of the response object and the execution times to retrieve these objects may beprohibitively large and that current implementations of the language suffers from this issue.This thesis explores the implementation of an algorithm for calculating the exact size of theresponse object from a GraphQL query, and the performance based evaluation of the implementation. A proof of concept of a server using the implementation of the algorithm and subsequent tests of thecalculation times for particularly problematic queries sent to the server, show that the implementationscales well and could serve as a way to stop these queries from executing.

Introspected REST ist ein neuer Ansatz für die Entwicklung von Web-APIs, welcher auf REST aufbaut. In der vorliegenden Arbeit wird dieser neue API-Stil mit REST, GraphQL und gRPC hinsichtlich der Performance, Evolvierbarkeit und Komplexität bzw. Benutzbarkeit verglichen. Die Performance der untersuchten Introspected-REST-API liegt dabei im gleichen Bereich wie die der REST-API, welche ihrerseits von gRPC und GraphQL übertroffen wird. Auch die Evolvierbarkeit ist gleich gut im Vergleich zu REST. Die Verwendung von Introspected REST trägt vor allem zu einer besseren Benutzbarkeit der API bei.:1. Einleitung 2. Grundlagen von Web-APIs 2.1. Definition und Einteilung 2.2. Der Architekturstil Representational State Transfer (REST) 2.2.1. Grundlagen des Webs 2.2.2. REST-Prinzipien 2.2.3. Ablauf der Interaktionen zwischen Client und Server 2.3. Die Abfragesprache GraphQL 2.4. Das gRPC-Protokoll 2.5. Zusammenfassung 3. Introspected REST 3.1. Definition und Hauptbestandteile 3.1.1. Datenmodell 3.1.2. Probleme von REST 3.1.3. Das Introspection-Prinzip 3.1.4. Microtypes 3.2. Prototypische Implementierung 3.2.1. Ein Container-Mediatype für Microtypes 3.2.2. Content-Negotiation für Microtypes 3.2.3. Introspection durch HTTP-OPTIONS 3.2.4. Implementierung in ASP.NET Core 3.3. Zusammenfassung 4. Kriterien für den Vergleich der API-Stile 4.1. Performance 4.1.1. Performancemetriken für Web-APIs 4.1.2. Experiment zur Erfassung der Metriken 4.1.3. Validität und Übertragbarkeit der Ergebnisse 4.1.4. Verwandte Arbeiten 4.2. Evolvierbarkeit 4.2.1. Definition und Einteilung für Web-APIs 4.2.2. Durchführung eines Evolvierbarkeit-Vergleichs für API-Stile 4.2.3. Validität und Übertragbarkeit der Ergebnisse 4.2.4. Verwandte Arbeiten 4.3. Komplexität 4.3.1. Arten der Komplexität bei Web-APIs 4.3.2. Bewertung der Benutzbarkeit einer Web-API 4.3.3. Validität und Übertragbarkeit der Ergebnisse 4.3.4. Verwandte Arbeiten 4.4. Zusammenfassung 5. Vergleich der API-Stile 5.1. Performance 5.1.1. Ermittlung von Requestanzahl und Nachrichtengrößen 5.1.2. Ermittlung der Antwortzeiten 5.2. Evolvierbarkeit 5.3. Komplexität 5.3.1. Heuristiken für die Erlernbarkeit 5.3.2. Heuristiken für das Vorbeugen von Fehlern 5.3.3. Heuristiken für Einfachheit 5.3.4. Heuristiken für Konsistenz 5.3.5. Zusammenfassung 6. Diskussion 6.1. Performance 6.2. Evolvierbarkeit 6.3. Komplexität 6.4. Zusammenfassung 7. Fazit und Ausblick Literatur A. Ergebnisse der Performancemessungen B. Codebeispiele / Introspected REST is a new approach to the development of web APIs. It builds upon the REST architectural style. In this thesis, Introspected REST is compared to REST, GraphQL, and gRPC in terms of performance, evolvability, and complexity/usability. The results show that the performance of Introspected REST is in the same order of magnitude as the performance of REST. Both are in turn outperformed by gRPC and GraphQL, respectively. The evolvability rates similarly to REST’s evolvability, too. Using Introspected REST for an API does most notably improve its usability.:1. Einleitung 2. Grundlagen von Web-APIs 2.1. Definition und Einteilung 2.2. Der Architekturstil Representational State Transfer (REST) 2.2.1. Grundlagen des Webs 2.2.2. REST-Prinzipien 2.2.3. Ablauf der Interaktionen zwischen Client und Server 2.3. Die Abfragesprache GraphQL 2.4. Das gRPC-Protokoll 2.5. Zusammenfassung 3. Introspected REST 3.1. Definition und Hauptbestandteile 3.1.1. Datenmodell 3.1.2. Probleme von REST 3.1.3. Das Introspection-Prinzip 3.1.4. Microtypes 3.2. Prototypische Implementierung 3.2.1. Ein Container-Mediatype für Microtypes 3.2.2. Content-Negotiation für Microtypes 3.2.3. Introspection durch HTTP-OPTIONS 3.2.4. Implementierung in ASP.NET Core 3.3. Zusammenfassung 4. Kriterien für den Vergleich der API-Stile 4.1. Performance 4.1.1. Performancemetriken für Web-APIs 4.1.2. Experiment zur Erfassung der Metriken 4.1.3. Validität und Übertragbarkeit der Ergebnisse 4.1.4. Verwandte Arbeiten 4.2. Evolvierbarkeit 4.2.1. Definition und Einteilung für Web-APIs 4.2.2. Durchführung eines Evolvierbarkeit-Vergleichs für API-Stile 4.2.3. Validität und Übertragbarkeit der Ergebnisse 4.2.4. Verwandte Arbeiten 4.3. Komplexität 4.3.1. Arten der Komplexität bei Web-APIs 4.3.2. Bewertung der Benutzbarkeit einer Web-API 4.3.3. Validität und Übertragbarkeit der Ergebnisse 4.3.4. Verwandte Arbeiten 4.4. Zusammenfassung 5. Vergleich der API-Stile 5.1. Performance 5.1.1. Ermittlung von Requestanzahl und Nachrichtengrößen 5.1.2. Ermittlung der Antwortzeiten 5.2. Evolvierbarkeit 5.3. Komplexität 5.3.1. Heuristiken für die Erlernbarkeit 5.3.2. Heuristiken für das Vorbeugen von Fehlern 5.3.3. Heuristiken für Einfachheit 5.3.4. Heuristiken für Konsistenz 5.3.5. Zusammenfassung 6. Diskussion 6.1. Performance 6.2. Evolvierbarkeit 6.3. Komplexität 6.4. Zusammenfassung 7. Fazit und Ausblick Literatur A. Ergebnisse der Performancemessungen B. Codebeispiele

GraphQL is an open source framework for creating adaptable API layers and was developed and released by Facebook in 2015. GraphQL includes both a query language and an execution engine and has quickly gained popularity among developers. However, GraphQL suffers from a problem, certain types of queries can generate huge response objects that grow exponentially in size. A recent research paper proposed a solution to this problem in the form of an algorithm that calculates the result size of a query without executing the query itself. The algorithm enables the possibility to decide if a query should be executed based on the query response size. In an implementation and evaluation of this algorithm, it was found that for simple queries, running the algorithm takes approximately the same time as executing the query, which means that the total query processing time is doubled. This thesis proposes a way to solve that problem by introducing an extended algorithm that combines the result size calculation with query execution. An implementation of the extended algorithm was evaluated and shows that it is a viable option that only has a minor impact on the total query processing time for most queries.

This report explicates the work in this project that has been done at the company Learn2Esport, which has a platform to help educate esport called Gameplan. The goal of this project have been to help the company create a new page on their platform on which administrators can get an overlook of their organizations and teams. The development of this page has been done in React and the code have been written in Typescript. Previously, administrators have had to go into each individual organization or team to find information about how the organization is doing. The work in this project have simplified this by collecting all this information on the same page, where administrators easily can choose an organization and extensive information about all the teams in this organization will be displayed in a table. This table is divided into 5 different parts which displays different areas of the team with both text and implemented charts. The table also shows statistics from a current time span that can be changed by the user. / Denna rapport tar upp det arbete som gjorts under detta projektarbete som har utförts hos företaget Learn2Esport, som har en plattform för utbildning inom esport kallad Gameplan. Målet med detta projekt har varit att hjälpa företaget att skapa en ny sida på plattformen där administratörer kan se statistik över sina organisationer och föreningar. Utvecklingen av detta arbete har gjorts i React och koden som skrivits har skrivits i Typescript. Administratörer har tidigare behövt gå in på varje enskild organisation eller förening för att hitta information om hur det går för respektive organisation. Detta arbete har samlat all denna information på ett och samma ställe där det enkelt går att välja en organisationsgrupp där sedan alla föreningar i denna organisationen visas i sidans tabell. Tabellen består av 5 olika delar som utgör omfattande statistik om varje förening och på ett tydligt sätt visar data för olika områden med både text och grafer. Tabellen visar också statistik från ett utvalt tids spann samt hur denna statistik såg ut och har förändrats från föregående tids spann.

In recent years, GraphQL has become a popular Web API language. Due to GraphQL’spopularity, third-party libraries have also grown steadily alongside it. One such library isGraphQL Tools, which provides tools such as query delegation and schema wrapping. Onecore element of GraphQL is its schema. In part, the schema describes the relations betweendata in a data source. Every GraphQL server needs a schema, which in turn utilizes resolverfunctions that retrieve the data from the data source. Schema wrapping allows developers to create GraphQL schemas that delegate queriesto another remote server. This allows the user to modify the behavior of the remote schema,without modifying its contents. However, some JavaScript knowledge is required to im-plement the schema wrapping. This thesis proposes a declarative approach to wrappingschemas with the help of custom GraphQL directives. The main objective of the approach isto enable less knowledgeable developers to wrap schemas with less effort. The declarative approach was tested by implementing a prototype. The effects on per-formance was tested with a benchmarking tool called Linköping GraphQL Benchmark(LinGBM). The prototype delegated queries to a remote server also created by LinGBM.The benchmarking tool was run against both the wrapper server and the remote server.The results indicated that the overhead of the wrapper server was mostly due to internalfunctions of GraphQL Tools. Therefore, automatically generating a server with the pro-posed declarative approach did not seem to impose significant performance losses. Con-sidering the decreased programming effort by using the declarative approach, the slightperformance loss can be seen as manageable.

Since becoming an open source project in 2015, GraphQL has gained popularity as it is used as a query language from front-end to back-end, ensuring that no over-fetching or under-fetching is performed. While the query language has been openly available for a few years, there has been little academic research in this area. The aim of this thesis is to create an approach for using GraphQL on top of a graph database, as well as evaluate the optimisation techniques available for this approach. This was done by developing logical plans and query executions plans, and the suitable optimisation technique was found to be parallel execution and batching of database calls. The implementation was done in Java by using graph computing framework Apache TinkerPop, which is compatible with a number of graph databases. However, this implementation focuses on graph database management system Neo4j. To evaluate the implementation, query templates and data from Linköping GraphQL Benchmark was used. The logical plans were created by converting a GraphQL query into a tree of logical operators. The query execution plans were based on four different primitives from the Apache TinkerPop framework, and the physical operators were each influenced by one or more logical operators. The performance tests of the implementation showed that the query execution times were largely dependant on the query template as well as the number of database nodes visited. The pattern between execution times and the number of threads used in the parallel execution was concluded as lower execution times (<100 ms) were improved when 4-6 threads are used, while higher execution times were improved for 12-24 threads used. For the very fast query executions (<5 ms), using threading caused more overhead than the time saved by parallel execution, and for these cases it was better to not use any threading.

Inom denna rapport så kommer det gås igenom vilka tekniker och metoder som har används för att skapa en implementation en ny sorts webbaserat API. Det nya API't heter GraphQL och upfyller samma syfte som det mer traditionella REST API som används mycket utav företag och organisationer i dagsläget. Det som skiljer GraphQL mot REST är att GraphQL använder sig av "Query Language" för att kommunicera med API't genom att hämta eller skicka information. Implementationen har utförts inom .NET Framework hos företaget Quicksearch. Utvecklingen har skett inom företagets datasystem och API't kan hämta information från deras databas och skicka det vidare till användaren. Verktygen som har använts för att skapa applikationen är utvecklingsprogrammet Visual Studio tillsammans med programmeringsspråket C\#. Programmet Postman har använts till hjälp för utveckling och testning av API't. Relevanta metoder för att skapa API't inkluderar bibliotek riktat mot GraphQL och sammankoppling mot databasen. Designmönster har varit viktiga i projektet och dessa är "Dependency Injection" och "Model-View-Controller" för att skapa en web applikation. Slutresultatet är ett GraphQL API som kan forma enkla förfrågningar riktat mot en data-modell eller objekt. Även en jämförelse av GraphQL mot REST API har utförts med resultatet att det finns distinkta skillnader mellan de två konceptenför men för att komma fram till en övergripandeslutsats över vilket API som är ett bättre alternativ så behövs ytterligare tester. / This report will walkthrough several techniques and methods that have been used to create a new kind of web-based API. This new kind of API is called GraphQL and fullfils the same purpose as the more traditionally used REST API. What differs between these two types of API is that GraphQL uses a ”Query Language” when the user communicates with the API. The implementation is done in .NET Framework together with a company named Quicksearch. The development has been done within Quicksearch’s computer system and the API can request information from the company’s database and send it back to the user of the API. The tools that have been used to develop the API are Visual Studio as the development enviroment, along with the programming language C#. Postman is a software that have also been used to help develop and test the GraphQL API. Relevant methods used in the development includes libraries directed to create a GraphQL API and libraries used to create the connection to the database. Design patterns have also be important in the development and the most noticeable ones have been ”Dependency Injection” and ”Model-View-Controller” to create the application. The end result is an API that is able to recieve simple queries directed against a simple data-model or object. Aditionally a comparison between GraphQL and REST have been done and the result is that there are distinct differences between the two types of API but there is a lack of scientific reasarch and knowledge to make the conclusion of which is the better alternative and additional tests are required.

This essay is a documentation of the work that was made for the consultancy company GESHDO Now AB in which a solution was built to facilitate content management of the company’s website with modern frontend technologies. The basic requirement was to create a web-based editor, or a JAMstack-based project with a clear separation between the content and the layout. The requirement was to achieve the highest performance possible. The solution should be deployed with the help of a cloud service. A primary goal in this project is to liberate resources at the company, so that employees who lack coding skills can easily manage the content of the website without having to ask for help from the developers. Technologies such as React, Gatsby, GraphQL and TinaCMS have been used to create a user-friendly interface which lives in a protected environment in which it is easy to manage the content of the website in realtime. When the changes are saved, they will be immediately reflected on the website in production. The project has been built based upon the ideas of simplicity, reusability, scalability and easy maintenance, as well as the possibility to extend the solution and customize it for future needs. / Den här uppsatsen handlar om ett arbete som gjordes åt konsultbolaget GESHDO Now AB där en lösning byggdes för att underlätta innehållshanteringen på deras webbplats med moderna frontend-tekniker. Grundkraven var att skapa en form av editor, eller en JAMstack-applikation med en klar separering mellan layouten och innehållet. Dessutom ska prestandan vara så hög som möjligt. Lösningen ska publiceras med hjälp av en molntjänst. Ett huvudsakligt syfte med lösningen är att frigöra resurser på företaget, så att anställda som saknar kodkunskaper ska enkelt kunna hantera webbplatsens innehåll utan att behöva ta hjälp utav utvecklarna. Tekniker som React, Gatsby, GraphQL och TinaCMS har använts för att skapa ett användarvänligt gränssnitt som lever i en skyddad miljö där man enkelt kan hantera webbplatsens innehåll i realtid. När ändringarna sparas, så reflekteras de på webbplatsens liveversion. Projektet har byggts med enkelhet, återanvändbarhet, skalbarhet och enkelt underhåll i åtanke, och det är möjligt att utvidga lösningen och skräddarsy den utifrån framtida behov.

The dynamic query language GraphQL is gaining popularity within the field as more and more software architects choose it as their architectural model of choice when designing an API. The dynamic nature of the GraphQL queries provide a different way of thinking about data fetching, focusing more on the experience for the API consumer. The language provides many exciting features for the field, but not much is known about the implications of implementing them. This thesis analyzes the architecture of GraphQL and explores its attributes in order to understand the tradeoffs and performance implications of implementing a GraphQL architecture in a data-fetching API, as opposed to a conventional REST architecture. The results from the architectural analysis suggests that the GraphQL architecture values the usability and supportability attributes higher than its REST counterpart. A performance experiment was performed, testing the internal performance of GraphQL versus REST in a use-case where its dynamic functionality is not utilized (returning the same static response as its REST equivalent). The results indicate that the performance of GraphQL implementations are lower than that of its REST equivalents in use-cases where the dynamic functionality is not utilized.

The Semantic Web was introduced to bring structure to the Web. The goal is to allow computer agents to be able to traverse the web and carry out tasks for human users. In the Semantic Web, data is stored using the RDF data model. The purpose of this study is to explore the possibility of exposing GraphQL data to the Semantic Web using a data-to-data translation inspired by Ontology Based Data Access (OBDA). This was done by introducing GraphQL2RDF, a proof-of-concept method to materialize GraphQL data as RDF triples. GraphQL2RDF uses two mapping schemas: a GraphQL-mapping schema annotated with directives to filter and select GraphQL data and an RDF-mapping schema to specify which RDF triples to create. GraphQL2RDF supports directives for filtering based on the SQL where-clause used for filtering in SQL. The approach is demonstrated in a library use-case, in which library data exposed in a GraphQL endpoint is mapped into RDF. GraphQL2RDF demonstrates a method for exposing GraphQL data as RDF, while imposing a minimal set of requirements on the GraphQL endpoint. Future work includes improvements of the model and exploring extensions of this translation method towards an OBDA approach that does not require full materialization of the RDF data.