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.