En implementation av GraphQL i .NET Framework med inslag av en jämförelse mot REST API

Kandidatuppsats

Examensarbetet i datateknik, 15 hp

En implementation av GraphQL i .NET

Framework med inslag av en jämförelse mot

REST API

Datateknik 15 hp

Halmstad 2020-09-02

Acknowledgements

Vi har f˚att starkt st¨od under arbetets g˚ang och vi vill h¨armed ge ett stort tack till ett antal personer som har hj¨alpt oss genom att tillf¨ora v¨agledning och st¨od i alla l¨agen f¨or att kunna lyckas fullf¨olja v˚art examensarbete. Vi vill framf¨ora ett stort tack till v˚ar huvudansvariga handledare Magnus Olander, som har givit oss mycket tid och st¨od under detta arbetet genom att bidra med l¨arorik fakta och diskussioner d¨ar vi har f˚att information om hur system och teknik fungerar p˚a f¨oretaget. Detta har gjort det m¨ojligt att djupg˚aende f¨orst˚a hur teknik anv¨ands idag och har varit mycket viktig vid sidan om annan information och fakta.

Vi vill framf¨ora ett stort tack till Magnus G¨oransson som har varit v˚ar specialiserade tekniska handledare och har bidragit till ett tekniskt st¨od p˚a en bred front. Detta har underl¨attat v˚ar arbetsprocess och har gjort att faktainh¨amtning och utvecklingen har varit s˚a effektiv som har varit m¨ojligt och vi skulle verkligen inte ha klarat oss utan hans engagemang. Vi vill ocks˚a tacka f¨oretaget Quicksearch som har erbjudit sitt kontor som arbetsplats under arbetet och har bjudit p˚a kaffe och dryck som har underl¨attat genom hela v˚art arbete.

Contents

1 Inledning 1

1.1 Uppgiften . . . 1

1.2 Hur ska resultatet analyseras . . . 1

1.3 M˚al, Syfte och Fokus . . . 2

1.4 Problemformulering . . . 2

1.5 Kravspecifikation . . . 3

1.6 Avgr¨ansning . . . 3

2 Bakgrund och teori 5 2.1 Quicksearch . . . 5

2.1.1 Analytics . . . 5

2.1.2 Filter, Fr˚agor och Resultatk¨allor . . . 6

2.2 Endpoint f¨or API . . . 6

2.3 Javascript Object Notation . . . 6

2.4 Dependency injection . . . 6 2.5 Inversion of Control . . . 7 2.6 Model-View-Controller . . . 7 2.6.1 Model . . . 7 2.6.2 View . . . 8 2.6.3 Controller . . . 8 2.7 .NET Framework . . . 8 2.8 GraphQL . . . 8 2.8.1 Schema . . . 10 2.8.2 Type . . . 10 2.8.3 Query . . . 10 2.8.4 Mutation . . . 11 2.8.5 Fragment . . . 11

2.8.6 Nackdelar med GraphQL . . . 11

2.9 REST API . . . 11

2.9.1 Nackdelar med REST . . . 13

3 Metod och genomf¨orande 15 3.1 Fakta och forskning . . . 15

3.2 Val av utvecklarmilj¨o . . . 15

3.2.1 .NET . . . 15

3.2.2 Model View Controller applikation . . . 16

3.2.3 Dependency Injection . . . 16

3.3 GraphQL . . . 16

3.3.1 Schema . . . 16

3.4 Integration med databasen . . . 17

3.5 Val av verktyg . . . 17

3.5.1 Postman som valideringsverktyg . . . 17

3.6 Testmetoder . . . 17

3.6.1 Testmetod: datorkapacitet . . . 17

3.6.2 Testmetod: responstid och genomstr¨omning . . . 18

4 Resultat 19 4.1 Implementation . . . 19

4.1.1 Resultat utefter specifikation . . . 20

4.2 Studie . . . 20

4.3 Funktionalitet . . . 21

4.3.1 REST . . . 21

4.3.2 GraphQL . . . 21

4.4 J¨amf¨orelse . . . 21

5 Diskussion och Slutsatser 23 5.1 Diskussion . . . 23 5.1.1 .NET . . . 23 5.1.2 GraphQL . . . 24 5.2 Slutsats . . . 24 5.2.1 Praktiskt arbete . . . 25 5.2.2 Teoretiskt . . . 25 5.2.3 Prestandatester . . . 26 5.3 Framtida arbete . . . 26 5.3.1 Testning . . . 26 Appendices 29 A 31

List of Acronyms

REST REpresentational State Transfer

API Application Programming Interface HTTP HyperText Transfer Protocol

IDE Integrated Development Environment

UI User Interface

SQL Structured Query Language

JSON JavaScript Object Notation CRUD Create, Read, Update, Delete

BP Best Practice

DBMS DataBase Management System MVC Model-View-Controller

IoC Inversion of Control

Abstract

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 Quick-search.

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 devel-opment 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.

Sammanfattning

Inom denna rapport s˚a kommer det g˚as igenom vilka tekniker och metoder som har anv¨ands f¨or 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¨ands mycket utav f¨oretag och organisationer i dagsl¨aget. Det som skiljer GraphQL mot REST ¨ar att GraphQL anv¨ander sig av ”Query Language” f¨or att kommunicera med API’t genom att h¨amta eller skicka information. Implementationen har utf¨orts inom .NET Framework hos f¨oretaget Quicksearch.

Utvecklingen har skett inom f¨oretagets datasystem och API’t kan h¨amta information fr˚an deras databas och skicka det vidare till anv¨andaren. Verktygen som har anv¨ants f¨or att skapa applikationen ¨ar utvecklingsprogrammet Visual Studio tillsammans med programmer-ingsspr˚aket C#. Programmet Postman har anv¨ants till hj¨alp f¨or utveckling och testning av API’t. Relevanta metoder f¨or att skapa API’t inkluderar bibliotek riktat mot GraphQL och sammankoppling mot databasen. Designm¨onster har varit viktiga i projektet och dessa ¨ar ”Dependency Injection” och ”Model-View-Controller” f¨or att skapa en web applikation.

Slutresultatet ¨ar ett GraphQL API som kan forma enkla f¨orfr˚agningar riktat mot en data-modell eller objekt. ¨Aven en j¨amf¨orelse av GraphQL mot REST API har utf¨orts med resul-tatet att det finns distinkta skillnader mellan de tv˚a konceptenf¨or men f¨or att komma fram till en ¨overgripandeslutsats ¨over vilket API som ¨ar ett b¨attre alternativ s˚a beh¨ovs ytterligare tester.

Chapter 1

Inledning

1.1

Uppgiften

Uppgiften i detta arbetet handlar om att unders¨oka m¨ojligheterna av att utveckla en ver-sion av GraphQL[2] i .NET Framework i programmeringsspr˚aket C#. GraphQL ¨ar en nytt koncept f¨or hur ett webb baserat API kan byggas f¨or att kommunicera med serversidan i ett projekt. Det uppfyller samma syfte som det mer traditionella REST API’t som ¨ar den nuvarande industri standarden. Det som skiljer GraphQL mot REST ¨ar att anv¨andaren kommunicerar med API’t genom ett ”Query Language”. GraphQL var ursprungligen ett koncept som utvecklades av Facebook. Det existerar idag flera olika ”open source” l¨osningar om GraphQL som kan anv¨andas till implementation.

Projektet involverar att unders¨oka om GraphQL kan fungera p˚a plattformen .NET Frame-work Version 4.5. Projektet best˚ar av tv˚a delar, d¨ar den f¨orsta delen handlar om implemen-tationen av GraphQL. Den andra delen ¨ar en enkel j¨amf¨orelse av GraphQL mot REST. Kravspecifikationen har tagits fram tillsammans med Magnus Olander, utvecklingschef p˚a f¨oretaget Quicksearch. N˚agra huvudsakliga f¨oruts¨attningar ¨ar att GraphQL ska implementeras vid sidan om deras MVC applikation (QS.Reportal system). Deras applikation ¨ar imple-menterad i och anv¨ander sig utav .NET Framework, version 4.5, vilket ¨ar vad Quicksearch framf¨or allt vill kunna unders¨oka f¨or GraphQL. MVC applikationen ¨ar Quicksearch system som samlar data ang˚aende kundunders¨okningar som skickas ut ˚at deras kunder. Ut¨over im-plementation s˚a ¨ar det faktorer som s¨akerhet och authentisering, f¨or att kunna anv¨anda sig av GraphQLs API, som spelar en viktig roll. Det ¨ar p˚a grund av att en kund enbart skall kunna komma ˚at data som dom har ¨agander¨att till. J¨amf¨orelse skall vara en unders¨okning av GraphQL och skall motivera om det ¨ar b¨attre att anv¨anda sig av GraphQL i f¨orh˚allande till REST API i Quicksearch situation. J¨amf¨orelsen skall vara faktabaserad och styrkas av relevanta k¨allor.

1.2

Hur ska resultatet analyseras

Det f¨ardiga resultatet skall analyseras hur vida implementationen uppfyller Quicksearch krav p˚a funktionalitet, s¨akerhet och vara fri fr˚an buggar och problem.

2 CHAPTER 1. INLEDNING

J¨amf¨orelsen som skall utf¨oras skall inneh˚alla det resultat som inte ¨ar m¨atbart men ¨and˚a viktiga f¨or att kunna bilda sig en uppfattning om funktionalitet och bygga sig en f¨orst˚aelse ur ett utvecklingsperspektiv. Rapporten ska inneh˚alla information och feedback fr˚an Quick-search. Detta anses viktigt f¨or att kunna presentera en helhetsbild av resultatet. Rapporten skall inneh˚alla faktabaserad information om GraphQL med m˚alet att bygga en god f¨orst˚aelse f¨or GraphQL.

1.3

M˚

al, Syfte och Fokus

M˚alet ¨ar att implementera en version av GraphQL enligt v˚ar kravspecifikation som riktar sig mot Quicksearch. Samt g¨ora en observation ¨over vilka resurser som kr¨avs f¨or att ¨overg˚a fr˚an ett existerande REST applikation till GraphQL fr˚an Quicksearch perspektiv.

Projektet hoppas p˚a att ge l¨asaren en utf¨orlig f¨orst˚aelse bakom hur GraphQL fungerar. N¨ar man l¨aser beskrivning om hur GraphQL funkar s˚a verkar det som det bara ¨ar f¨ordelar. Pro-jektet skall d¨arf¨or g˚a igenom hur implementation av GraphQL fungerar fr˚an b¨orjan till slut. Dessutom hur det ¨ar att jobba med en f¨ardig implementation av GraphQL. Rapporten skall inneh˚alla en informativ j¨amf¨orelse ang˚aende hur GraphQL skiljer sig j¨amf¨ort med REST.

Fokus i detta arbete kommer ligga i att utveckla m¨ojligheterna f¨or att anv¨anda GraphQL f¨or att erbjuda anv¨andare ett API att sj¨alv kunna h¨amta ut data ur Quicksearch datasamling. Detta kan hypotetiskt sett underl¨atta lagringkapacitet och datorkapacitet att lagra och filtr-era data. Samtidigt kanske det kan orsaka ”denial of service” om Quicksearch databas blir ¨

overbelastad med f¨orfr˚agningar och d¨arf¨or tillf¨alligt ¨ar oanv¨andbar.

1.4

Problemformulering

GraphQL ¨ar som tidigare n¨amnt ett alternativ till REST som har en chans att bli en ny industristandard(’best practice’). Det anv¨ands idag av flera olika organisationer. Utveck-lingen sker ocks˚a p˚a m˚anga h˚all f¨or att implementera ny funktionalitet som ¨annu inte finns tillg¨angliga i GraphQL.

Problemfr˚agor:

• G˚ar det att implementera GraphQL i .NET Framework version 4.5 hos Quicksearch? • Hur skapar man funktionalitet f¨or att genomf¨ora f¨orfr˚agningar (query data) i GraphQL?

• Vilka delar beh¨ovs f¨or att implementera GraphQL hos Quicksearch? • Vad finns det f¨or skillnader mellan GraphQL och REST?

• GraphQL j¨amf¨ort med REST: G˚ar det att bevisa vad som ¨ar ett b¨attre alternativ f¨or Quicksearch?

1.5. KRAVSPECIFIKATION 3

1.5

Kravspecifikation

Quicksearch ¨onskar att inom detta arbete skall det utforskas m¨ojligheterna till att utveckla ett verktyg f¨or att kunna h¨amta ut en specificerad m¨angd data ur deras datasamling med koppling till deras SQL databas. Arbete ska f¨olja ”Best practice” och d¨arf¨or anv¨anda s˚a mycket som redan ¨ar implementerat, som ¨ar m¨ojligt, f¨or att underl¨atta arbetet. Arbetet ska kunna anv¨anda sig av redan existerande s¨akerhetsprincip (hos f¨oretaget) f¨or att underl¨atta f¨or b˚ada parter. Arbetet ska enbart l¨agga fokus p˚a att utveckla ett GraphQL som till˚ater kunder att g¨ora f¨orfr˚agningar (quereis) och bortse d¨arf¨or helt fr˚an funktionalitet kring att kunna manipulera(Mutation) data. Arbetet hoppas kunna resultera i en prototyp/applikation som kan genomf¨ora olika f¨orfr˚agningar f¨or att h¨amta ut listorna: filter, fr˚agor och resultatk¨allor f¨or anv¨andaren. Man efter detta unders¨oka m¨ojligheterna att genom att anv¨andaren med urvalen: filter, fr˚agor, resultatk¨allor samt datum och tid ska kunna g¨ora en f¨orfr˚agan f¨or att h¨amta en m¨angd data (som kallas f¨or en ’Round’). F¨orhoppningar (skillt fr˚an krav) ¨ar att utveckling genomf¨oras i .NET Framework i version 4.5 f¨or att underl¨atta och ˚ateranv¨anda existerande material fr˚an Quicksearch.

1.6

Avgr¨

ansning

Ett anv¨andargr¨anssnitt (User Interface) f¨or GraphQL kommer inte utvecklas eller vara en del av utvecklingsmilj¨oerna i detta arbete. Det skall inte utvecklas eller designa en databas utan kommer anv¨anda den redan existerande hos Quicksearch. Under genomf¨orandet kommer det inte l¨aggas n˚agon fokus p˚a funktionalitet kring manipulering (Mutations) av GraphQL datan.

Chapter 2

Bakgrund och teori

Inom detta kapitlet skall det ges en f¨orklaring p˚a kunskapsomr˚adet. Detta involverar fakta och terminologi som kommer beh¨ovas f¨or att f˚a en b¨attre f¨orst˚aelse f¨or vad som anv¨ands f¨or att skapa GraphQL applikationen. Detta kommer b˚ade g¨oras p˚a en basniv˚a s˚av¨al som djupare niv˚a, fr˚an vetenskapliga k¨allor f¨or att ge kandidatarbetet ett l¨ampligt djup. Kapitlets uppgift ¨ar att ge en bred inblick i bakomliggande fakta till omr˚adet och framh¨ava ett rel-evant kunskapsomr˚ade. Nedanf¨or beskrivs och presenteras Quicksearch samt begrepp som: endpoint, JSON, dependency injection, IoC, MVC, GraphQL, REST API.

2.1

Quicksearch

I detta examensarbete har man, som tidigare konstaterat, arbetat tillsammans med f¨oretaget Quicksearch. Quicksearch ¨ar ett f¨oretag som erbjuder kunder en m¨ojlighet att g¨ora aff¨ ars-beslut utifr˚an anv¨andares synpunkter p˚a och av upplevelser i form av kundunders¨okningar. Detta betyder att Quicksearch sammanst¨aller data fr˚an unders¨okningar som dom har skickat ut p˚a beg¨aran av deras kunder och sammanst¨aller det p˚a ett attraktivt s¨att s˚a att infor-mationen kan anv¨andas av kunderna. All data sammanst¨alls i deras MVC applikation som anv¨ander sig av Microsoft SQL databas och .NET Framework (med C#). I detta arbetet har vi f˚att grundf¨oruts¨attningar fr˚an Quicksearch i form av ett antal f¨orhoppningar och behov som bildar en behovspecifikation och detta ¨ar grunden f¨or detta arbete (forskningen) och utvecklingen av GraphQL.

F¨orhoppningar ang˚aende resultat inkluderar f¨orst˚aelse f¨or GraphQL, som ¨ar byggt p˚a veten-skapligt material. En lokal demostrations version av GraphQL ¨ar byggd. Demo. versionen in-neh˚aller modeller och Schemas som man har skapat p˚a egen hand. Denna versionen ska funka som konceptbevis (”proof of concept”) f¨or att fullst¨andigt kunna implementera GraphQL i Quicksearch MVC applikation och ge det ¨okad funktionalitet.

2.1.1 Analytics

Analytics ¨ar ett system som Quicksearch anv¨ander till att lagra och sammanst¨alla data som f¨oretaget samlar in fr˚an sina unders¨okningar som skickas ut p˚a beg¨aran av deras kunder. Systemet ¨ar byggt i .NET Framework och inneh˚aller databaser och API’s f¨or att lagra och

6 CHAPTER 2. BAKGRUND OCH TEORI

kommunicera data. Analytics ¨ar ¨aven v¨ard f¨or deras webplatform som till˚ater f¨oretagets kunder att logga in och granska resultatet fr˚an unders¨okningar som Quicksearch har utf¨ort.

2.1.2 Filter, Fr˚agor och Resultatk¨allor

Filter, Fr˚agor och Resultatk¨allor ¨ar namn p˚a olika objekt. Dessa objekt ¨ar en samling olika urval som f¨oretaget vill tillhandah˚alla till anv¨andaren f¨or att dem skall kunna h¨amta data ur databasen genom att g¨ora en f¨orfr˚agan med dessa som argument. Dessa har redan tidigare anv¨ands av deras REST API p˚a samma s¨att, f¨or att ge anv¨andaren information om valbara m¨ojligheter p˚a vilka kategorier av data som kan h¨amtas.

2.2

Endpoint f¨

or API

Endpoints ¨ar b˚ade en central och viktig del n¨ar man utvecklar, diskuterar eller anv¨ander API:er. Endpoint ¨ar den delen av ett API (application program interface) d¨ar det specificeras vilka resurser som kan kommas ˚at och h¨amtas ut ur API’t. Endpoints har d¨arf¨or en stor betydelse p˚a hur API’t upplevs av anv¨andaren. Endpoint hj¨alper samtidigt till att kontrollera att all funktionalitet av mjukvaran uppr¨atth˚alls.

2.3

Javascript Object Notation

Javascript object notation (JSON) ¨ar ett text format som ursprungligen b¨orjade anv¨andas inom JavaScript. JSON ¨ar ett s¨att att strukturera data genom att efterlikna objekt och arrayer. Det har idag blivit ett utav de popul¨ara s¨atten att kommunicera med data mellan serverar och webbtj¨anster[12].

2.4

Dependency injection

Dependency Injection[11] (DI) ¨ar ett designm¨onster som till˚ater att att man ¨overl¨amnar ansvaret av att skapa en klass till en s˚a kallad injector.

Detta ¨ar enklare att f¨orst˚a genom ett exempel enligt Figur 3.1. I bilden s˚a finns det tv˚a klasser som heter ”Client” och ”Service”. Ist¨allet f¨or att l˚ata beroendet skapas mel-lan ”Client” och ”Service”, s˚a kan man genom injectorn skapa ”Service” klassen och injicera den i ”Client”. P˚a ett s˚adant s¨att s˚a beh¨over bara injectorn ha kunskap om och ”Service” och andra klasser kan anv¨anda sig av den ”Service” klassen genom att f˚a den injicerad i sin egna projekt.

N¨ar man injicerar ett objekt (exempelvis ”Service”) i en annan klass s˚a l˚ater man den klassen veta att det h¨ar objektet existerar och att klassen kan anv¨anda sig av detta objekt. Det finns flera situationer d˚a detta ¨ar applicerbart. Till exempel i ett projekt d¨ar flera klasser beh¨over referera till samma objekt.

2.5. INVERSION OF CONTROL 7

Figure 2.1: Exempel p˚a Dependency Injection och hur det anv¨ands f¨or att l¨osa vad som annars ¨ar en d˚alig relation mellan Client och Server.

2.5

Inversion of Control

Inversion of Control (IoC) ¨ar en designprincip f¨or att kunna skapa en frikopplad l¨osning som ¨

ar l¨atthanterlig. Detta g¨ors genom att man tar bort alla n¨ara relationer mellan klasser. Syftet ¨

ar att genom detta g¨ora systemet mer frikopplat och d¨arf¨or l¨attare att hantera. IoC’s de-signm¨onster delegera kontrolfl¨odet till exempelvis: observer pattern, events, Dependency inje-cion och liknande tekniker. Moderna webb applikationer med ’Model-view-control’ arkitektur ¨

ar beroende av IoC-Container f¨or att genomf¨ora URL-v¨agledning och att s¨att kontrollers p˚a plats f¨or ge ramverket kommunikation m¨ojligheter.

2.6

Model-View-Controller

MVC[9] ¨ar ett designm¨onster som vanligen ¨ar f¨orekommande i alla typer av program som inneh˚aller n˚agon form av grafiskt anv¨andargr¨anssnitt eller grafisk representation. Grundkon-ceptet med MVC ¨ar att man separerar koden f¨or klassen f¨or M (som ¨ar data modellen) fr˚an de milj¨oer som anv¨andaren interagera med (V och C). Ut¨over detta s˚a definierar modell, vy och kontroll, hur dem kommer att interagera mellan varandra.

Nedan iFigur 3.2visas samspelet mellan modellen, vyn, kontrollen samt anv¨andaren (user). Ur anv¨andarens perspektiv s˚a har man enbart uppfattning om Vyn som man g¨or inputs utefter.

2.6.1 Model

Modellen (Model) ¨ar ett objekt som en MVC applikation interagerar med. N¨ar det kommer till ett webb API s˚a kan det handla om ett objekt med data som h¨amtas genom en API

8 CHAPTER 2. BAKGRUND OCH TEORI

Figure 2.2: MVC’s designm¨onster.

f¨orfr˚agan. Modellen anv¨ands ocks˚a f¨or att lagra data i som kan till exempel i sin tur h¨amtas fr˚an en databas eller andra datak¨allor.

2.6.2 View

En vy[5] (View) beskriver delar av modellen f¨or anv¨andaren genom sitt anv¨andar gr¨anssnitt. Vyn kan exempelvis vara en: text, graf, ljud och/eller video.

2.6.3 Controller

Kontrollen (Controller) ¨ar klassen som styr applikationen. N¨ar en anv¨andare interagerar med applikationen kan det ske direkt med kontrollen eller kontakta kontrollen genom en ”view”. Kontrollen ¨ar klassen som tar besluten ¨over n¨asta steg som ska utf¨oras inom applikationen.

2.7

.NET Framework

.NET Framework ¨ar ett ramverk f¨or bygga system och applikationer. Ramverket har st¨od f¨or att flera olika programmeringsspr˚ak ska kunna interagera med varandra. .NET Framework har ett klassbibliotek med mallar och f¨ardiga l¨osningar.

2.8

GraphQL

GraphQL b¨orjade utvecklas av Facebook i ett f¨ors¨ok att underl¨atta data h¨amtning och kom-munikation till serverar av mobil applikationer p˚a grund av den v¨axande aktiviteten och

2.8. GRAPHQL 9

behovet kring 2012[10]. Ett GraphQL API har i grund och botten inte en specifikation f¨or hur det ska implementeras. GraphQL ¨ar snarare en konceptuell modell f¨or vad som ska finnas med, men som inte ger tydliga riktlinjer p˚a hur API’t ska implementeras. Det ¨ar prim¨art p˚a grund av detta som m˚anga nya utvecklare/programmerare ofta har sv˚arigheter att utveckla GraphQL i j¨amf¨orelse med REST, som har betydligt mer konkreta krav och riktlinjer. I kon-ferensuppsatsen ”Migrating to GraphQL: A Practical Assessment” [7] skrivs det att GraphQL inte kommer leda till en marginal skillnad av antalet anrop/f¨orfr˚agningar som m˚aste utf¨ors j¨amtemot antalet endpoint anrop f¨or REST API. Samtidigt kunde de konstatera att det finns en betydande marginell skillnad i m¨angden data som lagras. Deras studie drog slutsatsen att GraphQL har m¨ojlighet att minimera m¨angden data i bytes som lagras med 94%.

GraphQL j¨amtemot REST API, som ¨ar ett mycket vanligt s¨att att h¨amta data p˚a, ¨ar att GraphQL enbart beh¨over ta hj¨alp av en enda endpoint medans REST m˚aste anv¨anda m˚anga olika endpoints vilket bidrar till s¨amre flexibilitet. En GraphQL f¨orfr˚agan (query and muta-tion) kan liknas med en ’CRUD’ f¨orfr˚aga inom SQL och detta ¨ar anledningen till att GraphQL kallas ett ’query language’. GraphQL ¨ar, trots detta, inte direkt kopplat till en databas och ¨

ar d¨arf¨or inte begr¨ansat till varken SQL eller NOSQL databaser[8].

IFigur 4.1 h¨ar under, kan man se hur ett GraphQL API fungerar p˚a en enkel konceptuell niv˚a f¨or att kunna ge en inblick i hur den fungerar. I figuren ser man hur GraphQL genom att enbart g¨ora en enda f¨orfr˚agan (query) kan h¨amta exakt den informationen som f¨orfr˚agas, fr˚an flertalet olika datasamlingar.

10 CHAPTER 2. BAKGRUND OCH TEORI

2.8.1 Schema

Schema ¨ar den absolut mest centrala delen i GraphQL applikationen och ¨ar direkt ihop-kopplad med databasen och/eller datasamlingen. I flertalet f¨orklaringar brukar Schemat beskrivas som en graf, d¨ar man med olika Types (som kan liknas med noder i en graf) sam-mankopplar all data j¨amtemot databasen. I teorin ska ett Schema g¨ora att det ¨ar enklare f¨or ’backend’ utvecklare (utvecklare som arbetar p˚a serverniv˚a) att f¨orst˚a vilken data som finns, hur den ska hanteras och skickas. P˚a samma s¨att har ’frontend’ utvecklare, som arbetar med det grafiska anv¨andargr¨anssnittet, enklare att f¨orst˚a vilka resurser som g˚ar att h¨amta f¨or att kunna utveckla ett bra grafiskt anv¨andargr¨anssnitt (GUI)[10]. SDL ¨ar en term som m¨ojligen kan uppkomma i dessa kretsar och st˚ar f¨or ’Schema definition language’ och vilket enbart betyder att man bygger upp ett schema som matchar databasen och datasamlingen.

2.8.2 Type

Types kan liknas med objekt eller f¨orem˚al som direkt kan identifieras som ett f¨orem˚al i databasen. En Type kan refereras som en attribut hos ett annat Type, f¨or att ˚astadkomma en koppling, vilket kan liknas med en ’b˚age’ eller ’kant’ inom grafteori. Viktigt ¨ar att Type objekten ¨ar v¨alutformade d˚a de analyseras av utvecklare f¨or att de skall kunna f¨orst˚a vilken data som lagras. Det ¨ar p˚a samma s¨att som GraphQL har erh˚allit sitt namn utefter att vara ett ’query language’ som det har f˚att sitt graf (graph) baserade namn som bygger p˚a att dess Schema och Types bygger en graf liknande datastruktur.

I appendix A.1 visar hur ett enkelt GraphQL Schema kan se ut med olika Types. Man f˚ar ¨aven se ett exempel p˚a hur Types bygger upp ett samband som liknar det utav en graf, genom att en Type refereras i en annan Type. Man kan h¨ar notera att Schemat ¨ar en viktig del f¨or hur b˚ade mutations och queries utformas och skrivs.

2.8.3 Query

GraphQL ¨ar som sitt namn beskriver ett ’query language’ och har m¨ojlighet att utf¨ora f¨orfr˚agningar. En f¨orfr˚aga[3] (query) inom GraphQL ¨ar en operation eller ett kommando f¨or att kunna h¨amta data ur en databas. En f¨orfr˚aga inom GraphQL anv¨ands p˚a s˚a s¨att att man specificerar vilka objekt man vill h¨amta och vilken attribut man vill h¨amta om ett objekt eller objekten. Resultatet av en godk¨and f¨orfr˚aga blir en respons i JSON format som matchar den f¨orfr˚agan som gjorts. Man f˚ar ocks˚a en HTTP status kod, som signalerar att allt har skett korrekt. En felaktig f¨orfr˚agan kommer d¨aremot att returnera en JSON respons som best˚ar av felinformation och en HTTP status kod. F¨or att kunna h¨amta ett f¨orem˚al och dess attribut genom en GraphQL f¨orfr˚agan(query) kr¨avs att f¨alt (field) redan ¨ar skapat och deklarerat i APIs Schema och samspelar med databasen[10].

Kodstycket appendix A.2 visar hur man genom ett GraphQL API kan h¨amta data, fr˚an en databas som inneh˚aller fakta kring Starwars , genom att specificera den attribut man vill h¨amta om personen med personID: 1. Detta sker i JSON format.

2.9. REST API 11

och h¨ar f˚as en output (i JSON format) som inneh˚aller en attribut som sj¨alv inneh˚aller en lista ¨over namn p˚a filmer, som karakt¨aren har n¨arvarat i.

2.8.4 Mutation

Mutation ¨ar likt en f¨orfr˚aga(Query) ett nyckelord som kan utf¨ora operationer inom GraphQL applikationer. Mutationer ¨ar huvudsakligen en operation som skapar, ¨andrar eller tar bort data ur datasamlingen som ¨ar ansluten till GraphQL[3]. Mutationer kan liknas med kom-mandon som ’UPDATE’ och ’DELETE’ ifr˚an SQL, d¨ar man vill kunna ¨andra redan redan befintlig data eller l¨agga till ny information. Just som f¨or Queries m˚aste dess attribut och f¨alt vara vara deklarerade i API Schema.t f¨or GraphQL, f¨or att kunna genomf¨oras.

Man kan i appendix A.4 se hur man kan g¨or en mutation som skapar ett objekt (todos) som lagras i en datasamling. Detta g¨ors genom ett anrop till ”insert todos” med argument ”title”.

2.8.5 Fragment

Fragment ¨ar ett kommando som kan anv¨andas inom GraphQL f¨orfr˚agningar f¨or att minimera upprepningar som sker i koden. Fragments anv¨andas d¨arf¨or till att man definierar en samling attribut, som finns f¨or ett objekt och sedan anv¨ander de genom ett nyckelord. I appendix A.5 visas ett exempel p˚a hur man kan anv¨anda sig av fragments f¨or att definiera en attribut till ett nyckelord.

2.8.6 Nackdelar med GraphQL ¨

Aven GraphQL har brister. Graphql ¨ar ett betydligt sv˚are koncept att utveckla ¨an den mycket enkla designen av ett REST API. GraphQL kr¨aver mycket arbete och tydligt strukturerad implementation f¨or att matcha datasamlingen. GraphQL har genom sin f¨orm˚aga att g¨ora en f¨orfr˚aga (query), m¨ojlighet att v¨alja ut vilken information som ska h¨amtas. Detta har sin nackdel i att varje g˚ang data f¨orfr˚agas s˚a kommer resultatet bli olika stort. Detta kan bli ett problem d˚a applikationer och databaser inte ¨ar optimerade f¨or att arbeta i milj¨oer som varierar kraven p˚a systemet.

2.9

REST API

REST ben¨amns som Representational State Transfer och utvecklades av Roy Fielding kring ˚ar 2000. REST API ¨ar en arkitektur struktur, ¨over data h¨amtning ¨over HTTP, som till˚ater utvecklare att skapa ’data modeller’ med en m¨angd olika endpoints, vilket f¨or sin tid var en enklare och effektivare l¨osning ¨an tidigare existerande webb API. REST vanligaste anv¨ and-ning ¨ar att h¨amta data genom de existerande endpoints. I samband med att JSON formatet utvecklades och standardiserades s˚a blev REST’s anv¨andarm¨ojligheter genombrytande[10]. Utifr˚an den vetenskaplig k¨allan ”Performance Analysis of GraphQL and RESTful in SIM LP2M of the Hasanuddin University”[8] fr˚an November 2018 presenteras att RESTful API ¨

12 CHAPTER 2. BAKGRUND OCH TEORI

kan m¨ojligen bidra till s¨amre prestanda hos webb applikationen. Samtidigt visar deras tester att RESTful ¨ar ¨overl¨agsen n¨ar det g¨aller konsekvent stabilitet vid test av responstid och genomstr¨omning. Bra att veta h¨ar ¨ar att, RESTful[6] skiljer sig fr˚an REST vilket inte ¨ar helt uppenbart. Den n˚agot komplicerade och bokstavligt skillnaden mellan REST och RESTful ¨

ar att RESTful f¨oljer samtliga krav som var utformade av skaparen Roy Fielding vilket inte ¨

ar givet f¨or ett REST API idag.

I Figur 4.2 ges en representation av hur man med REST API g¨or f¨orfr˚agningar p˚a den data man vill h¨amta eller ¨andra. Man kan h¨ar se att det kr¨avs flera olika f¨orfr˚agningar f¨or att h¨amta data fr˚an olika k¨allor. Detta kan bland annat leda till ’endpoint overload’ som orsakas av att man anv¨ander f¨or m˚anga ’endpoints’, vilket g¨or det sv˚art att hinna uppdatera och underh˚alla dem

Figure 2.4: REST arkitektur (perspektiv att j¨amf¨ora med Graphql. REST beh¨over fler endpoints).

2.9. REST API 13

2.9.1 Nackdelar med REST ¨

Overskott vid datah¨amtning[10] (Overfetching) ¨ar ett vanligt f¨orekommande problem n¨ar man anv¨ander REST API. Det uppkommer n¨ar det g¨ors en f¨orfr˚agan till en endpoint, ¨over ett HTTP anrop. Den data men vill h¨amta kan d˚a ej specificeras och d¨arf¨or blir resultatet b˚ade en st¨orre datam¨angd och m¨ojligtvis tar l¨angre tid. Detta leder till att datan oftast m˚aste sorteras och bearbetas f¨or att kunna anv¨andas.

Appendix A.6 ges ett tydligt exempel p˚a hur man genom en GET f¨orfr˚agan inte har n˚agra valbara m¨ojligheter att v¨alja ut vad man vill h¨amta (kring en karakt¨ar). Resultatet ges allts˚a av allt som ing˚ar/tillh¨or det objekt som efterfr˚agas (vid Get f¨orfr˚agan: ”/api/people/1”).

P˚a samma s¨att som ” ¨Overskott vid datah¨amtning” ¨ar underskott vid datah¨amtning (Un-derfetching) ett vanligt f¨orekommande utfall n¨ar man f¨orfr˚agar data ifr˚an ett REST API. Underskott vid datah¨amtning handlar om att man inte f˚ar exakt den data man vill fr˚an ett enda endpoint utan missar viktig och relevant data som g˚ar att h¨amta genom samma endpoint.

Chapter 3

Metod och genomf¨

orande

Detta kapitlet g˚ar ¨over vilka generella metoder som anv¨ands f¨or utf¨orandet/implementationen av GraphQL. Kunskaper som har varit n¨odv¨andiga f¨or utf¨orandet av projektet. Detta in-volverar beskrivning av fakta, metod och bibliotek som har anv¨ants i det praktiska arbetet.

3.1

Fakta och forskning

Projektet har dels haft fokus p˚a att hitta relevanta k¨allor med information som kan bidra till det slutgiltiga resultatet och implementationen av GraphQL. Det har varit viktigt f¨or att utforska vilka alternativ som finns tillg¨angliga i utf¨orandet av examensarbetet och hitta de b¨asta utf¨orandet i situationen f¨or detta projekt.

3.2

Val av utvecklarmilj¨

o

3.2.1 .NET

Quicksearch har som krav att Graphql API:t ska implementeras i .NET Framework 4.5 och vara skrivet i C#. D¨aremot har det valts att g˚a ifr˚an .NET Framework 4.5, n˚agot som uppt¨acktes var att implementera GraphQL i .NET framework 4.5 hade resulterat i att GraphQL biblioteket hade tappat st¨od f¨or framtida uppdateringar. Ist¨allets valdes det att skapa en l¨osning som anv¨ander sig av .NET Framework 4.7.2 som har st¨od av Quicksearch existerande klass bibliotek. Ett annat alternativ som utforskades var .NET Core som har in-byggt st¨od f¨or ”dependency injection”. D¨aremot skapade .NET Core kompabilitets problem mot Quicksearch datasystem.

Inom utvecklingen av projektet anv¨ands utvecklings verktyget Visual Studio. Visual Stu-dio har st¨od f¨or .NET Framework och bidrar med ett klass bibliotek f¨or att bygga olika system och applikationer. Det som anses som b¨asta utf¨orande n¨ar man ska skapa ett webb baserat API ¨ar att anv¨anda sig av det f¨ardiga klass biblioteket och skapa en webb applikation som anv¨ander sig av MVC design m¨onstret (design pattern).

16 CHAPTER 3. METOD OCH GENOMF ¨ORANDE

3.2.2 Model View Controller applikation

F¨or att skapa en webb applikation s˚a finns det f¨ardiga mallar att anv¨anda i Visual Studio. En av dessa mallar g¨aller f¨or att skapa en MVC webb applikation. Denna mallen har anv¨ants och den s¨atter upp ett exempel projekt med en endpoint som g˚ar det g˚ar att k¨ora en eller flera kontroller igenom.

GraphQL kontrollen som k¨ors via MVC applikationen tar in en formaterad f¨orfr˚agan (query) och skickar vidare den till de relevanta klasserna som hanterar schemas och types. Dessa klasserna har injicerats i MVC applikationen via design m¨onstret ”Dependency Injection”. Kontrollen och klasserna som anv¨ands till att forma GraphQL API’t i applikationen anv¨ander sig av ett GraphQL bibliotek som heter ”graphql-dotnet”.

3.2.3 Dependency Injection

Dependency Injection anv¨ands i projektet f¨or att skapa instanser av klasser som ¨ar globala inom hela applikationen. Detta har anv¨ands f¨or klasser som anv¨ander sig av GraphQL bib-lioteket och uppkopplingar till databasen f¨or att man inte ska beh¨ova passera samma instans av ett objekt till flera olika klasser. Det ¨ar en effektiv l¨osning som anses vara standard inom utveckling i .NET.

3.3

GraphQL

Utf¨orandet f¨or att skapa ett GraphQL API fr˚an grunden ¨ar ett v¨aldigt stort projekt. D¨arf¨or har man beslutat i detta projektet att det b¨asta s¨attet att utf¨ora detta p˚a ¨ar att anv¨anda sig utav ¨oppen k¨allkod (open source) bibliotek. Det finns en organisation som kallar sig GraphQL Foundation, som listar ¨oppen k¨allkod (open source) bibliotek f¨or olika plattformar. Det var ett utav dessa biblioteken som m¨otte behoven f¨or f¨oretaget.

Biblioteket heter ”graphql-dotnet” och finns p˚a github. Det ¨ar dokumenterat och det finns mycket information och exempel ang˚aende just det biblioteket. Det m¨oter ¨aven behoven med att det st¨odjer .NET Framework. N¨ar man importerar biblioteket och anv¨ander det p˚a r¨att s¨att s˚a kan det ta in argument och genom schemas som utvecklaren har byggt s˚a kan biblioteket extrahera r¨att data.

3.3.1 Schema

F¨or att p˚ab¨orja att utveckla schemat f¨or GraphQL applikationen var det n¨odv¨andigt att ta en n¨armare titt och studera hur F¨oretagets databas/datasamling ¨ar strukturerad. Det genomf¨ordes samtal med f¨oretagets utvecklare f¨or att f˚a en tydlig bild av vad som skulle fungera och vad som borde utvecklas och f˚a funktionalitet. F¨or att dela upp uppgiften valde man att dela in arbetet i steg, varav det f¨orsta var att skapa funktionalitet f¨or filter, resultat-k¨allor och fr˚agor. Man valde att skapa en klass FilterType som anv¨ander sig av Filter, som ¨ar klass skapad av f¨oretaget f¨or att v¨alja/sortera data. FilterType definierar med hj¨alp av GraphQL-operationen ”Field” i samspel med ett lambda uttryck v¨aljer en variabel

3.4. INTEGRATION MED DATABASEN 17

som kan anv¨andas vid f¨orfr˚agningar (query). Detta gjordes ¨aven f¨or ’ResultSourceType’ och ’QuestionType’.

3.4

Integration med databasen

GraphQL API’t kommunicerar med en relations databas som ¨ar baserad p˚a Microsoft SQL server. Kopplingen till databasen skapas genom ett bibliotek som kallas f¨or NHibernation och ¨

ar ett vanligt s¨att inom .NET Framework att kommunicera med en databas. NHibernation anv¨ands f¨or att skicka SQL-queries och ta emot respons fr˚an databasen.

Biblioteket anv¨ander sig med hj¨alp av n˚agot som heter ”connectionstrings” inom .NET, f¨or att skapa en s¨aker uppkoppling mot databasen. Connectionstrings inneh˚aller authentisierings uppgifter som godk¨anner uppkopplingen. Det finns olika klasser som beh¨over anv¨anda sig av uppkopplingen till databasen f¨or att kunna h¨amta information, d¨arf¨or har man injicerat uppkopplingen via ”Dependency Injection”.

3.5

Val av verktyg

3.5.1 Postman som valideringsverktyg

I projektet har det inte skrivits n˚agra unit-tester. D¨aremot s˚a har verktyget ”Postman” anv¨ants f¨or testning av GraphQL API’t. Postman anv¨ands i allm¨anhet f¨or utveckling och testning av olika typer av API d¨ar ¨aven GraphQL inkluderas. I syftet av detta projekt s˚a har det anv¨ands till att skicka f¨orfr˚agningar till GraphQL API’t. Genom brytpunkter i koden och analys av http statuskoder s˚a har det varit m¨ojligt att debugga koden och se till att varje del av applikationen funkar som f¨orv¨antat.

3.6

Testmetoder

F¨oljande metoder har utforskats och anses relevanta f¨or detta projektet som utf¨ors. Det ¨ar meningen att adaptera dessa koncept och utf¨ora dessa p˚a en f¨orenklad skala ¨an vad som har gjorts i de refererade vetenskapliga k¨allorna.

3.6.1 Testmetod: datorkapacitet

F¨or att m¨ata datorkapacitet mellan GraphQL och REST API kommer projektet att sikta mot att j¨amf¨ora om man kan reducera data¨overf¨oringen genom att granska det urval av popul¨ara klienter, som anv¨ander sig av Githubs API. Genom att d˚a ers¨atta REST API f¨orfr˚agningar med GraphQL f¨orfr˚agningar s˚a kommer det att unders¨okas/konstateras om det finns en trend med m¨ojligheten att minimera data som ¨overf¨ors med ett GraphQL API. Detta ¨ar en teknik som g˚ar i linje med den vetenskapliga k¨allan ”Migrating to GraphQL: A Practical Assessment”[7] anv¨ander.

18 CHAPTER 3. METOD OCH GENOMF ¨ORANDE

3.6.2 Testmetod: responstid och genomstr¨omning

F¨or att kunna m¨ata skillnaden mellan GraphQL och REST API ansers att tester f¨or respon-stid (3.1) och genomstr¨omning (3.2) ¨ar godtyckliga m˚att. Detta ¨ar en teknik redan anv¨and i den vetenskapliga k¨allan: ”Performance Analysis of GraphQL and RESTful in SIM LP2M of the Hasanuddin University”[8]. Det fokuserar p˚a att analysera responstiden och hur m˚anga f¨orfr˚agningar ett GraphQL API kan hantera j¨amtemot serversidan, vid en given tidpunkt.

Analys av responstid g¨ors med formel:

Respons tid = exikverings tid + data¨overf ¨oring tid (3.1)

Genomstr¨omning av data m¨ats/analyseras med tester utifr˚an formel:

Genomstr¨omning = max antal f ¨orf r˚agningar

tid (3.2)

Chapter 4

Resultat

Inom detta kapitlet kommer det g˚as igenom och beskriva resultatet av implementationen. Detta inkluderar stor fokus p˚a att beskriva implementation/utveckling av GraphQL p˚a f¨ ore-taget.

Projektet har lyckats skapa en GraphQL applikation inom .NET 4.7, vilket ¨ar en version skapad f¨or att implementeras i Quicksearch system med vis funktionalitet. Integrationen i Quicksearch system lyckades, men efter olika of¨orutsedda omst¨andigheter s˚a implementerades API’t ej med full funktionalitet utefter Quicksearch specifikation.

J¨amf¨orelsen/analysen mot REST har utforskats och det resultatet ¨ar att det inte finns en tydlig standard d¨ar det g˚ar att j¨amf¨ora REST mot GraphQL. Rapporten kommer h¨ar att h¨anvisa till alternativ f¨or hur funktionaliteten av de tv˚a API’n j¨amf¨ors och hur man p˚a d˚a kan dra slutsatser om f¨ordelar och nackdelar utefter Quicksearch behov.

4.1

Implementation

Implementationen av GraphQL har m¨otts av b˚ade framg˚angar och motg˚angar. Resultatet ¨

ar en lyckad implementation av att skapa en GraphQL applikation i Quicksearch datasystem. Projektet har lyckats med att skapa en webb applikation som anv¨ander sig av ”MVC” design m¨onstret i .NET Framework 4.7.2. Webbapplikationen ¨ar ett GraphQL API som anv¨ander sig av ”graphql-dotnet” biblioteket som ¨ar det mest anv¨anda biblioteket f¨or GraphQL inom .NET. Eftersom projektet anv¨ander sig av ”MVC” s˚a har det skapats kontroller (A.8) och modeller, kontrollen anv¨ands f¨or att styra applikationen och modellerna definierar objekten man h¨amtar fr˚an databasen som GraphQL sedan kan anv¨anda sig av f¨or att skicka tillbaka till anv¨andaren. Man har ¨aven anv¨ant sig av ”dependency injection” (A.7) f¨or att injicera diverse olika klasser bland annat f¨or att kunna komma ˚at Quicksearch’s databas men ¨aven det separata klassbibliotekets som har skapats f¨or GraphQL.

Klassbibliotek definerar ”Queries”, ”Schema” och ”Types” som anv¨ands av GraphQL bib-lioteket f¨or att kommunicera och h¨amta data fr˚an Quicksearch databas. Utifr˚an en f¨ardig formaterad ”query” kan GraphQL tolka vilket objekt API’t ska titta p˚a och vilka variabler

20 CHAPTER 4. RESULTAT

fr˚an objektet som ska h¨amtas. En f¨orfr˚agan kommer att slutligen g¨ora metodanrop till Quick-search databas f¨or att h¨amta data som sedan formateras om till JSON data, som skickas till klienten.

Implementationen som har skapats ˚at Quicksearch kan anv¨anda sig av ett objekt som kallas f¨or ”Filter”. Filter ¨ar ett vanligt objekt som inneh˚aller variabler med information. Alla dessa variabler g˚ar att h¨amta genom implementationen av GraphQL.

4.1.1 Resultat utefter specifikation

Implementationen av GraphQL har till en viss punkt utf¨orts utefter specifikationen som har Quicksearch har givit. D¨aremot har inte all funktionalitets kunnat utf¨oras p˚a grund av of¨orutsedda problem. Medans GraphQL funkar s˚a har man f˚att byta fr˚an .NET Frame-work 4.5 till .NET FrameFrame-work 4.7.2. ¨Aven vissa f¨orfr˚agningar som skall ha g˚att att utf¨ora i GraphQL har inte implementerats. Detta ¨ar p˚a grund av att deras existerande system och klassbibliotek ¨ar inte kompatibelt med .NET Framework 4.7.2 och d¨arf¨or har man beh¨ovt skapa funktionalitet och klasser som kan komma ¨over den tidigare icke existerande funktion-aliteten. Detta har ¨aven orsakat att implementeringen av funktionalitet f¨or authentiseringen inte har utf¨orts. Annu ett resultat p˚¨ a grund av inkompatibilitets problemen ¨ar att web applikationen f˚ar k¨oras j¨amsides andra applikationer inom samma system ist¨allet som en integrerad del av deras web plattform.

4.2

Studie

Studien g˚ar ut p˚a att j¨amf¨ora REST mot GraphQL. D¨aremot har studien har g˚att ¨over till en fallstudie eftersom det inte finns n˚agon standard f¨or att j¨amf¨ora REST mot GraphQL. Eftersom REST ¨ar en arkitektur skiljer detta sig d˚a GraphQL uppfattas mer som ett koncept som utvecklas p˚a m˚anga olika h˚all, f¨or olika spr˚ak med funktionaliteten som en gemensam faktor. Detta har lett till slutsatsen att i det h¨ar scenariot s˚a ¨ar en fallstudie utifr˚an vad som passar Quicksearch’s perspektiv b¨ast utifr˚an att j¨amf¨ora funktionaliteten av GraphQL gentemot hur deras existerande l¨osning f¨or REST API.

4.3. FUNKTIONALITET 21

4.3

Funktionalitet

Denna sektionen f¨ortydligar de funktionaliteten och hur dom skiljer sig mellan REST och GraphQL.

4.3.1 REST

• Kommunicerar ¨over HTTP.

• Anv¨ander sig av fler olika typer av endpoints: GET, POST, PUT, DELETE.

• F¨or att kommunicera med flera olika datak¨allor kr¨avs flera endpoints av samma typ. • Datan som g˚ar att h¨amtar eller manipulerar ¨ar f¨ordefinerad av en endpoint.

• REST inom .NET har st¨od f¨or b˚ade JSON och XML. • REST ¨ar en f¨ardig arkitektur som ¨ar bepr¨ovad.

• Finns st¨od f¨or i .NET Framework 4.0 och upp˚at och i .NET Standard 1.0 och upp˚at.

4.3.2 GraphQL

• Kommunikationen kan ske ¨over vilken kanal som helst d˚a det inte finns n˚agon standard f¨or GraphQL. Vanligaste implementationen sker ¨over HTTP.

• Anv¨ander bara av en endpoint POST

• Anv¨ander sig av av ett Query language genom en endpoint f¨or att kommunicera med flera olika datak¨allor.

• Datan som g˚ar att h¨amta eller manipulera genom en endpoint ¨ar dynamisk. • GraphQL inom .NET har st¨od f¨or b˚ade JSON och XML.

• GraphQL utvecklas fortfarande som ¨oppen k¨allkod och v¨axer snabbt.

• Utvecklas f¨or .NET standard 2.0 och upp˚at. Tidigare versioner har ¨aven st¨od f¨or .NET Framework 4.5.

4.4

J¨

amf¨

orelse

Det g˚ar att se att GraphQL och REST API har m˚anga funktioner som st¨ammer ¨overens med varandra. Det finns ocks˚a distinkta skillnader mellan GraphQL och REST. Framf¨orallt den st¨orsta skillnaden mellan dessa tv˚a ¨ar REST statiska funktion att h¨amta information j¨amf¨ort med GraphQL’s dynamiska s¨att att h¨amta information genom sitt egna ”query language”. Ur Quicksearchs perspektiv s˚a ¨ar dom huvudsakligen intresserade av att utforska GraphQL funktionalitet att vara mer dynamisk med att h¨amta data i hopp om att det ska s¨anka belast-ningen p˚a deras system och ¨oppna upp f¨or mer funktionalitet med olika mjukvaror. F¨oretaget

22 CHAPTER 4. RESULTAT

kommer utf¨ora tester f¨or unders¨oka dessa m¨ojligheter och beroende p˚a det resultatet s˚a att f¨oretaget kan avg¨ora om GraphQL ¨ar ett alternativ till REST.

Dessa tester utg˚ar ifr˚an GraphQL’s belastning av deras system. Det betyder att f¨oretaget ska kunna utf¨ora stresstester och samla in data f¨or att utv¨ardera och ¨overv¨aga om det ¨ar v¨art att g˚a ¨over till GraphQL.

Chapter 5

Diskussion och Slutsatser

I detta kapitlet som kallas diskussion och slutatser kommer vi att reflektera ¨over v˚ara ˚asikt om hur projektet har varit samt genomf¨orts och d¨arf¨or med egna ord kan beskriva v˚ara tankar och id´eer ¨over vad vi tillslut har kommit fram till. Vi kommer l¨agga stor fokus i att reflektera ¨

over v˚art resultat d˚a det ¨ar det centrala vi l¨amnar ifr˚an oss till f¨oretaget. Vi kommer sam-tidigt att diskutera vad som har varit viktigt samt anv¨andsbar bakgrundsfakta av litteratur som vi har l¨ast och dess relevans.

F¨or att g¨ora ett avslut p˚a de fr˚agor som ¨annu obesvarade kommer det i slutsatser att klarg¨ora dessa. Vi kommer ¨aven att v¨ava in n˚agra mening f¨or att f˚a ett avslut p˚a vad man b¨or ha i ˚atanke n¨ar man skapar ett GraphQL API i framtiden eller enbart f¨ors¨oker j¨amf¨ora GraphQL

mot RESTful och beh¨over ett underlag av fakta.

Sist kommer vi ge n˚agra tips p˚a hur n˚agon kan f¨ors¨atta v˚art eller ett likartat arbete, d˚a v˚ar kunskap, m¨ojligtvis kan ge ett nytt och v¨ardefullt perspektiv.

5.1

Diskussion

Erfarenheten av bygga upp ett GraphQL API inom .NET ¨ar att det ¨ar att det kr¨avs mer arbete ¨an n¨ar man s¨atter upp ett REST API. REST ¨ar en bepr¨ovad teknologi som d¨ar det redan erbjuds f¨ardiga mallar och l¨osningar. GraphQL d¨aremot ¨ar fortfarande inom utveckling och det ¨ar en mer avancerad teknologi. Det kan medf¨ora en en del hinder n¨ar n˚agon funderar p˚a att ¨overg˚a till ett GraphQL API. N˚agot som har uppm¨arksammas inom detta projekt ¨ar att majoriteten av GraphQL biblioteken utvecklas mot senare versioner av .NET. Vilket ¨ar varf¨or en del av arbetet f¨or detta projektet har g˚att ut p˚a att testa olika .NET plattformar och versioner.

5.1.1 .NET

I detta projektet s˚a har b˚ade .NET Framework och .NET Core utforskats som m¨ojlig l¨osning f¨or att implementera GraphQL. Anledningen att .NET Core ans˚ags som en m¨ojlig l¨osning ¨ar f¨or att mycket utveckling idag ¨ar med .NET Core i ˚atanke och f¨or att plattformen erbjuder en enklare l¨osningar f¨or ”Dependency Injection”. Det var p˚a grund av inkompatibilitet med

24 CHAPTER 5. DISKUSSION OCH SLUTSATSER

Quicksearch l¨osning f¨or att kommunicera med databaser som gjorde att .NET Framework 4.7.2 anv¨andes ist¨allet.

Implementationen hade varit enklare att utf¨ora ju mer resurser som g˚ar att ˚ateranv¨anda fr˚an Quicksearch sida. Det kunde ha resulterat i att den slutgiltiga GraphQL produkten hade kunnat interagerat med fler objekt fr˚an databasen och d¨armed haft mer funktionalitet.

Det ¨ar viktigt att om det funderas p˚a implementera GraphQL i ett redan existerande sys-tem ha i ˚atanke att olika .NET versioner matchar varandra. Annars kan det resultera i att projektet blir f¨orl¨angt och kr¨aver mer tid och resurser ¨an n¨odv¨andigt.

5.1.2 GraphQL

Det finns potentiella m¨ojligheter till att GraphQL i framtiden kan bli en industristandard. Det ¨ar fortfarande f¨or tidigt att dra slutsatsen att GraphQL’s unika egenskaper ¨ar b¨attre ¨an alla andra alternativ p˚a marknaden. D¨aremot det som GraphQL erbjuder ¨ar v¨art att utforska.

Det finns slutsatser man kan dra ang˚aende funktionaliteten mellan REST och GraphQL men det beror helt och h˚allet vilken situation som de olika API ska anv¨andas inom. St¨orsta m¨ojliga nackdelen med REST ¨ar att det ¨ar sv˚art att uppdatera existerande endpoints utan att riskera att skapa inkompatibilitet med tj¨anster som anv¨ander sig av API’t. Detta ¨ar n˚agot som GraphQL kan erbjuda en m¨ojlig l¨osning med att du kan uppdatera API’t med nya datak¨allor som du kan kommunicera med genom en och samma endpoint utan att ¨aventyra existerande funktionalitet. Slutligen finns det ocks˚a en fr˚aga hur mycket belastning GraphQL l¨agger p˚a ett system.

Utan att ha utf¨ort prestanda tester s˚a ¨ar set sv˚art att dra en slutsats om vilken API struk-tur som ¨ar b¨attre ¨an den andra. Det ¨ar en avgr¨ansning inom detta arbetet f¨or att testa prestandan av ett API ¨ar ett v¨aldigt stort arbete. F¨orst hur testerna ska struktureras och vilken metod som skall anv¨andas och sen sj¨alva utf¨orandet. Ist¨allet har vetenskapliga k¨allor utforskats och det ¨ar sv˚art att hitta ett konsensus. En teori ¨ar att eftersom GraphQL utveck-las p˚a m˚anga olika h˚all f¨or m˚anga olika programmerings spr˚ak s˚a kan det ocks˚a mena att strukturen hos GraphQL kan vara annorlunda p˚a beroende p˚a vilket programmerings spr˚ak eller bibliotek som anv¨ands.

5.2

Slutsats

Denna sektionen kommer svara mer direkt och kortfattat p˚a problemformuleringen som st¨alldes i kapitel 1 av rapporten. Varje stycke i kommande sektion kommer svara en specifik punkt i problemformuleringen.

5.2. SLUTSATS 25

5.2.1 Praktiskt arbete

Quicksearch had som ¨onskning att implementera GraphQL i .NET Framework 4.5. Detta hade g˚att att genomf¨ora men det var inte f¨oredragbart eftersom GraphQL biblioteket som anv¨ands inom detta projektet inte har st¨od f¨or .NET Framework 4.5 i sina senaste versioner. Ist¨allet valdes .NET Framework 4.7.2 s˚a att det g˚ar att s¨akerst¨alla sig om att produkten har st¨od inf¨or framtiden.

Vad kr¨avs d˚a f¨or implementera GraphQL och kunna genomf¨ora f¨orfr˚agningar? Det beh¨ovs skapa en web applikation som g˚ar att kontakta ¨over http. I detta arbetet har det valts att skapa en MVC applikation f¨or att s¨atta upp en endpoint. Ytterligare s˚a kr¨avs det att skapa schemas och type som genom ”Dependency Injection” kopplas ihop med MVC applikationen. F¨or att integrera API’t mot Quicksearch s˚a har det skapats en uppkoppling mot deras databas. En del existerande funktionalitet fr˚an Quicksearch sida, gick f¨orlorat n¨ar GraphQL var tvun-gen att anv¨anda sig av en annan .NET version. Det p˚averkade arbetet p˚a ett s˚adant s¨att att en ny uppkoppling utvecklades f¨or att kontakta databasen och lades till i applikationen genom ”Dependency Injection”. Quicksearch datamodeller var ¨aven tvunget att kopieras och importeras till GraphQL applikationen.

Slutligen s˚a har har det kommit fram till att implementation av GraphQL i ett redan utveck-lat datasystem s˚a b¨or det finnas vissa f¨oruts¨attningar som kan ¨ar bra att ha i ˚atanke. Inom detta arbetet s˚a st¨ottes de p˚a kompatibilitets problem mot Quicksearch existerande datasystem. N˚agot som hade gjort arbetet mer genomf¨orbart ¨ar ifall .NET versionen som Quicksearch jobbar med hade matchat GraphQL biblioteket vilket hade resulterat till mycket ˚ateranv¨andning av existerande resurser som har n¨amnts tidigare, exempelvist datbasuppkop-pling. Resultatet av detta blev att GraphQL applikationen f˚ar k¨ora j¨amsides med andra applikationer p˚a samma serverer och system s˚a att applikationen kan ta del av resurser som ¨

ar kompatibla.

5.2.2 Teoretiskt

En del av fr˚agest¨allningen ¨ar att peka ut skillnader mellan GraphQL och REST. B˚ada tv˚a koncepten har liknande funktionalitet men det finns en viktig punkt som g¨or GraphQL unikt. Det ¨ar GraphQL’s dynamiska s¨att att manipulera data genom en endpoint gentemot REST statiska s¨att att manipulera data genom flera endpoints.

Ur Quicksearch perspektiv s˚a ¨ar det den dynamiska aspekten av GraphQL som ¨ar intres-sant f¨or det betyder att det g˚ar att uppdatera API’t utan att potentiellt bryta eller ¨andra den existerande funktionaliteten av API’t som applikationer ¨ar beroende av. Rent funk-tionsm¨assigt s˚a ¨ar det konstaterat att GraphQL ¨ar ett utm¨arkt alternativ. D¨aremot s˚a ¨ar detta bara en f¨ordel ifall GraphQL’s prestanda inte ¨ar s˚apass kr¨avande s˚a att det kommer beh¨ovas ytterligare investeringar f¨or att implementera den ny teknologin.

26 CHAPTER 5. DISKUSSION OCH SLUTSATSER

5.2.3 Prestandatester

F¨or att kunna s¨akerst¨alla att tester g¨ors korrekt s˚a ¨ar det viktigt att de genomf¨ors p˚a teknik/komponenter som har samma grundf¨oruts¨attningar, f¨or att resultatet ¨overhuvudtaget kan j¨amf¨oras. I detta arbetet har det varit otroligt sv˚art d˚a det har uppt¨ackts att det finns restriktioner som har gjort att det ¨annu inte har kunnat genomf¨oras. Den prim¨ara anlednin-gen ¨ar givetvis att GraphQL ej har den funktionalitet som beh¨ovs f¨or att det p˚a ett r¨attvist s¨att ska kunna j¨amf¨oras mot REST. En annan faktor har varit att man fr˚an Quicksearch sida inte har haft m¨ojlighet att till˚ata kunder att vara en del av ’testningen’. Detta bed¨oms som en viktig faktor f¨or att kunna genomf¨ora tester utan att ’r˚aka’ manipulera resulatet.

5.3

Framtida arbete

Det som finns kvar p˚a p˚a implementationen av GraphQL ¨ar att ge det mer funktionalitet. Alla m˚alen som Quicksearch specificerade inte ¨ar uppn˚adda. Det som inte ¨ar uppfyllt det ¨ar vissa objekt som inte g˚ar att h¨amta ut. Detta ¨ar beroende p˚a grund av of¨orutsedda h¨andelser under arbetets g˚ang och test av applikationen s˚a att API’t fungerade. I framtiden s˚a kommer ytterligare testning beh¨ovas utf¨oras, mer riktat mot prestanda tester.

Prestanda testerna kommer vara viktigt f¨or Quicksearch s˚a att GraphQL inte s¨atter f¨or stor belastning p˚a deras system. Skulle det visa sig att GraphQL har en stor belastning s˚a kommer det inte kunna ers¨atta REST helt och h˚allet. Ist¨allet s˚a kommer f¨oretaget anv¨anda det i vissa specialfall eller kanske bara vid intern kommunikation inom deras system.

5.3.1 Testning

F¨or att kunna m¨ata prestandan hos GraphQl mot REST API kr¨avs framf¨orallt att GraphQL ¨

ar full implementerat (av de s˚a kallade ’Rounds’) och har all funktionalitet som ¨aven REST API’t har. Med detta som grundpremiss s˚a har vi upplyst om tre m¨ojligheter att genomf¨ora testning p˚a, som kan l¨asas mer under kapitel 3.

Bibliography

[1] Building REST APIs with python and Django. https://medium.com/@siddhism/ building-rest-apis-with-python-and-django-573c01c7464d. Accessed: 2020-04-28.

[2] GraphQL: A query language for your API. https://graphql.org/. Accessed: 2020-02-04.

[3] GraphQL: Queries and Mutations . https://graphql.org/learn/queries/. Accessed: 2020-04-15.

[4] hasura.io. Writing data - Mutations. https://hasura.io/learn/graphql/react/ intro-to-graphql/3-writing-data-mutations/. Accessed: 2020-04-28.

[5] Niklas Broberg: Chalmers university of technology: Model – View – Con-troller (2016). http://www.cse.chalmers.se/edu/year/2017/course/DIT952/ slides/6-1a%20-%20Model-View-Controller.pdf. Accessed: 2020-02-04.

[6] What’s the difference between REST RESTful. https://stackoverflow. com/questions/1568834/whats-the-difference-between-rest-restful. Accessed: 2020-04-21.

[7] G. Brito, T. Mombach, and M. T. Valente. Migrating to graphql: A practical assess-ment. In 2019 IEEE 26th International Conference on Software Analysis, Evolution and Reengineering (SANER), pages 140–150, 2019.

[8] D. A. Hartina, A. Lawi, and B. L. E. Panggabean. Performance analysis of graphql and restful in sim lp2m of the hasanuddin university. In 2018 2nd East Indonesia Conference on Computer and Information Technology (EIConCIT), pages 237–240, 2018.

[9] M. Jailia, A. Kumar, M. Agarwal, and I. Sinha. Behavior of mvc (model view controller) based web application developed in php and .net framework. In 2016 International Conference on ICT in Business Industry Government (ICTBIG), pages 1–5, 2016. [10] Eve Porcello and Alex Banks. Learning GraphQL: Declarative Data Fetching for Modern

Web Apps. O’Reilly Media, Inc., 1st edition, 2018.

[11] M. Randic, M. Kunstic, and B. Blaskovic. Application design for ad hoc collaboration environment based on dependency injection pattern. In MELECON 2006 - 2006 IEEE Mediterranean Electrotechnical Conference, pages 664–667, 2006.

[12] C. Severance. Discovering javascript object notation. Computer, 45(4):6–8, 4 2012.

Appendices

Appendix A

Figure A.1: Exempel p˚a hur ett simpelt Schema med flera Type:s ser ut i GraphQL. Bildref-erens h¨anvisas till k¨allan[7].

Figure A.2: Exempel av en query fr˚an Star Wars Api:et (Json format).

32 APPENDIX A.

Figure A.3: Exempel av en query fr˚an Star Wars API:t, med hj¨alp av GraphiQL (i Json format).

33

Figure A.4: Exempel p˚a hur en mutation kan skrivas. Referens till bildk¨alla[4] .

Figure A.5: Uppvisning av hur fragment:s anv¨ands i GraphQL f¨or att minimera och effek-tivisera upprepning av kod.

34 APPENDIX A.

Figure A.6: Exempel p˚a Overfetching vid REST: GET-request. K¨alla-referens[1].

35

Besöksadress: Kristian IV:s väg 3 Postadress: Box 823, 301 18 Halmstad Telefon: 035-16 71 00

E-mail: registrator@hh.se www.hh.se

Våra namn är Johan Bergius och Philip Ranhult. Vi är studerar inom

Civilingenjör och Högskoleingenjör på Halmstads Universitet.