With the rise of mobile devices claiming a greater and greater portion of internet traffic, optimizing performance of data fetching becomes more important. A common technique of communicating between subsystems of online applications is through web services using the REpresentational State Transfer (REST) architectural style. However, REST is imposing restrictions in flexibility when creating APIs that are potentially introducing suboptimal performance and implementation difficulties. One proposed solution for increasing efficiency in data fetching is through the use of frameworks for declarative data fetching. During 2015 two open source frameworks for declarative data fetching, Falcor and Relay+ GraphQL, were released. Because of their recency, no information of how they impact performance could be found. Using the experimental approach, the frameworks were evaluated in terms of latency, data volume and number of requests using test cases based on a real world news application. The test cases were designed to test single requests, parallel and sequential data flows. Also the filtering abilities of the frameworks were tested. The results showed that Falcor introduced an increase in response time for all test cases and an increased transfer size for all test cases but one, a case where the data was filtered extensively. The results for Relay+GraphQL showed a decrease in response time for parallel and sequential data flows, but an increase for data fetching corresponding to a single REST API access. The results for transfer size were also inconclusive, but the majority showed an increase. Only when extensive data filtering was applied the transfer size could be decreased. Both frameworks could reduce the number of requests to a single request independent of how many requests the corresponding REST API needed. These results led to a conclusion that whenever it is possible, best performance can be achieved by creating custom REST endpoints. However, if this is not feasible or there are other implementation benefits and the alternative is to resort to a "one-size-fits-all" API, Relay+GraphQL can be used to reduce response times for parallel and sequential data flows but not for single request-response interactions. Data transfer size can only be reduced if filtering offered by the frameworks can reduce the response size more than the increased request size introduced by the frameworks. / Alteftersom användningen av mobila enheter ökar och står för en allt större andel av trafiken på internet blir det viktigare att optimera prestandan vid datahämtning. En vanlig teknologi för kommunikation mellan delar internet-applikationer är webbtjänster användande REpresentational State Transfer (REST)-arkitekturen. Dock introducerar REST restriktioner som minskar flexibiliteten i hur API:er bör konstrueras, vilka kan leda till försämrad prestanda och implementations-svårigheter. En möjlig lösning för ökad effektivitet vid data-hämtning är användningen av ramverk som implementerar deklarativ data-hämtning. Under 2015 släpptes två sådana ramverk med öppen källkod, Falcor och Relay+GraphQL. Eftersom de nyligen introducerades kunde ingen information om dess prestanda hittas. Med hjälp av den experimentella metoden utvärderades ramverken beträffande svarstider, datavolym och antalet anrop mellan klient och server. Testerna utformades utifrån en verklig nyhetsapplikation med fokus på att skapa testfall för enstaka anrop och anrop utförda både parallellt och sekventiellt. Även ramverkens förmåga att filtrera svarens data-fält testades. Vid användning av Falcor visade resultaten på en ökad svarstid i alla testfall och en ökad datavolym för alla testfall utom ett. I testfallet som utgjorde undantaget utfördes en mycket omfattande filtrering av datafälten. Resultaten för Relay+GraphQL visade på minskad svarstid vid parallella och sekventiella anrop, medan ökade svarstider observerades för hämtningar som motsvarades av ett enda anrop till REST API:et. Även resultaten gällande datavolym var tvetydiga, men majoriteten visade på en ökning. Endast vid en mer omfattande filtrering av datafälten kunde datavolymen minskas. Antalet anrop kunde med hjälp av båda ramverken minskas till ett enda oavsett hur många som krävdes vid användning av motsvarande REST API. Dessa resultat ledde till slutsatsen att när det är möjligt att skräddarsy REST API:er kommer det att ge den bästa prestandan. När det inte är möjligt eller det finns andra implementations-fördelar och alternativet är att använda ett icke optimerat REST API kan användande av Relay+ GraphQL minska svarstiden för parallella och sekventiella anrop. Däremot leder det i regel inte till någon förbättring för enstaka interaktioner. Den totala datavolymen kan endast minskas om filtreringen tar bort mer data från svaret än vad som introduceras genom den ökade anrops-storleken som användningen av ett frågespråk innebär.

In today's interconnected world, we as users constantly demand more information to be accessible from the web. Not only should the data be accessible but a crucial factor is that load times should be fast. With the internet expanding to more devices of different types such as smartphones, tablets, IoT devices and more, this factor becomes even more important. The most commonly used service today for serving data between clients and a server is REST, which has been the leading service used for this purpose for many years. This research paper focuses on identifying the differences in performance between RESTful services and Facebook's GraphQL. These two technologies are the two most commonly used and talked about solutions when it comes to serving data between clients and servers as of today, with more developers moving towards the newer GraphQL.

This essay describes the work to document and evaluate tools for front-end development at the company B3 Consulting Group. The methods that are evaluated is AMP-stack and JAM-stack. AMP-stack uses Apache, MySQL and PHP, Wordpress is used to build with that method. JAM-stack uses JavaScript, API and Markup, for that method GatsbyJS and Contentful is used. The evaluation is done both through user tests and how the methods are percived from a developer perspective. The project also includes work with customers at the company the project is done, Wordpress is used for those web pages. / Denna rapport beskriver arbetet med att dokumentera och utvärdera verktyg för frontend-utveckling vid företaget B3 Consulting Group. Metoderna som utvärderas är AMP-stack och JAM-stack. AMP-stack bygger på Apache, MySQL och PHP, för att bygga med den metoden har Wordpress använts. JAMstack bygger på JavaScript, API samt Markup, för den metoden har GatsbyJS samt Contentful använts. Utvärdering sker både genom användartester och hur metoderna upplevs ur ett utvecklarperspektiv. I arbetet ingår även arbete med kunder till företaget projektet utförts hos, för deras webbplatser har Wordpress använts.

Chatbots are computer programs with the capability to lead a conversation with a human user. When a chatbot is unable to match a user’s utterance to any predefined answer, it will use a fallback intent; a generic response that does not contribute to the conversation in any meaningful way. This report aims to investigate if a content-based recommender system could provide support to a chatbot agent in case of these fallback experiences. Content-based recommender systems use content to filter, prioritize and deliver relevant information to users. Their purpose is to search through a large amount of content and predict recommendations based on user requirements. The recommender system developed in this project consists of four components: a web spider, a Bag-of-words model, a graph database, and the GraphQL API. The anticipation was to capture web page articles and rank them with a numeric scoring to figure out which articles that make for the best recommendation concerning given subjects. The chatbot agent could then use these recommended articles to provide the user with value and help instead of a generic response. After the evaluation, it was found that the recommender system in principle fulfilled all requirements, but that the scoring algorithm used could achieve significant improvements in its recommendations if a more advanced algorithm would be implemented. The scoring algorithm used in this project is based on word count, which lacks taking the context of the dialogue between the user and the agent into consideration, among other things.

The thesis describes the design and implementation of an information system for a small business company. The thesis includes strategic analyzes of the company and an assessment of the current situation associated with the Covid­-19 pandemic. Subsequently, the thesis describes the process of specification and analysis of the requirements of the client, the design and implementation of the system corresponding to the proposals. Finally, the thesis provides the evaluation and expected benefits of the information system.

The project's primary goal is to develop a prototype for Columbus Global with the e-commerce platform Lithium GraphQL API and Next.js Commerce. It must contain a start and product page and a shopping cart. The prototype aims to investigate whether the untested combination of the mentioned tools is possible. A higher goal of the project is that Columbus can conclude that the prototype should be further developed and that I, as a developer, get more experience. It has since been tested for accessibility, performance and functionality with, among other things, user tests, Google Lighthouse and Wave.The result of the project shows that a combination of the two tools is feasible, and at the time of writing, there are no direct impossible obstacles. Regarding evaluation results, the prototype has fallen somewhat short in terms of performance but is still within the framework of the requirements that have been set. The availability is approved, and the user tests showed that the site was clear with a good product focus but with mixed reactions to the structure. The user tests also came with good suggestions on what can be improved, what was unclear and what functions are missing. The prototype's responsiveness is approved for both large and small screens. Columbus is pleased with the results, and further prototype development will take place. As a developer, I have gained a lot of new experience and have had the opportunity to start something that can potentially change a part of an international company. / Det huvudsakliga målet för projektet är att ta fram en prototyp-webbplats för företaget Columbus Global med e-handelsplattformen Litium GraphQL API och Next.js Commerce. Den ska innehålla en start och produktsida samt en kundvagn. Projektets syfte är att undersöka om den oprövade kombinationen mellan de nämnda verktygen är möjlig. Ett högre mål med projektet är att Columbus ser möjligheten att senare vidareutveckla prototypen. Dessutom får jag som blivande utvecklare arbetserfarenhet. Prototypen har testats gällande tillgänglighet, prestanda och funktionalitet med till exempel användartester, Google Lighthouse och Wave. Resultatet av projektet visar att en kombination mellan de två verktygen är utförbar och att det i skrivande stund inte finns några direkta omöjliga hinder. Utvärderingsresultaten av prototypen gällande prestanda kunde varit bättre men det föll ändå inom ramen för de krav som satts upp. Tillgängligheten är godkänd och användartesterna visade på att sidan var tydlig med bra produktfokus dock med blandade reaktioner på strukturen. Ur användartesterna kom även bra förslag på vad som kan förbättras, vad var otydligt och vilka funktioner fattas. Prototypens responsivitet är godkänd för både stora och små skärmar. Columbus är nöjda med resultaten och vidareutveckling av prototypen kommer att ske. Jag som utvecklare har fått mängder av ny erfarenhet och har fått chansen att starta något som potentiellt kan förändra en del av ett internationellt företag.

Application Programming Interfaces (APIs) are an important component in modern-day web applications. Representation State Transfer (REST) has been the de facto standard for building web APIs since its inception in 2000. In 2015 Facebook launched GraphQL, a technology with the purpose of solving some of the drawbacks of traditional REST APIs. However, few scientific studies have yet to assess the benefits and drawbacks of GraphQL vs REST from a performance standpoint. In this study, a controlled experiment was conducted to assess three categories of runtime performance: response time, CPU consumption and memory consumption. Results show that GraphQL consumes more server-side resources than REST, except in certain scenarios, while response time depends highly on the query. When fetching the same amount of data, REST is more efficient than GraphQL in every regard.  Keywords: Web Development, Application Programming Interfaces, REST, GraphQL, Performance.

The utilization of Application Programming Interfaces (APIs) has experiencedsignificant growth due to the increasing number of applications being devel-oped. APIs serve as a means to transfer data between different applications.While RESTful has been the standard API since its emergence around 2000,it is now being challenged by Facebook’s GraphQL, which was introducedin 2015. This study aims to fill a knowledge gap in the existing literatureon API performance evaluation by extending the focus beyond read opera-tions to include CREATE, UPDATE, and DELETE operations in both REST-ful APIs and GraphQL. Previous studies have predominantly examined theperformance of read operations, but there is a need to comprehensively un-derstand the behavior and effectiveness of additional CRUD operations. Toaddress this gap, we conducted a series of controlled experiments and anal-yses to evaluate the response time and RAM utilization of RESTful APIsand GraphQL when executing CREATE, UPDATE, and DELETE operations.We tested various scenarios and performance metrics to gain insights into thestrengths and weaknesses of each approach. Our findings indicate that con-trary to our initial beliefs, there are no significant differences between the twoAPI technologies in terms of CREATE, UPDATE, and DELETE operations.However, RESTful did slightly outperform GraphQL in the majority of tests.We also observed that GraphQL’s inherent batching functionality resulted infaster response times and lower RAM usage throughout the tests. On the otherhand, RESTful, despite its simpler queries, exhibited faster response times inGET operations, consistent with related work. Lastly, our findings suggestthat RESTful uses slightly less RAM compared to GraphQL in the context ofCREATE, UPDATE, and DELETE operations.

Application Programming Interfaces (APIs) are still relevant today in most modernweb applications. Some studies have compared the performance of RepresentationState Transfer (REST) and GraphQL in order to assess scenarios in which one out-performs the other. However, there is a lack of comparative studies exploring thescenarios of different programming languages. In this study/thesis, we focused onNode.js and Python, which are widely utilized by developers, due to their popular-ity. We aimed to fill this research gap by examining and comparing the scenariosof these two languages. We also considered comparing performance-centric frame-works like Fastify and FastAPI and traditional/feature-rich frameworks like Expressand Flask. Two applications were built for each framework comparing their perfor-mance in terms of response time, throughput and server-side resources. These weretested with JMeter and a custom middleware. Results show that GraphQL outper-forms REST in most scenarios. The environment that performed the best was Fastifywith GraphQL sacrificing CPU Usage.

GraphQL is a query language rising in popularity, causing many transitions from traditional API endpoints to a GraphQL solution. Reflecting upon the positives and the flaws to using GraphQL, a DataLoader for batching queries sent to databases is sold as a solution to the infamous N+1 problem. Experiments were conducted to test how GraphQL response time, with and without DataLoader, changes when paired with MySQL and MongoDB. Along with the experiments, a Literature Review was conducted reflecting over the databases structural differences that could affect the response time for GraphQL. Results suggest that no major differences were to be found, and the explanation for the minor differences could rather be because of the disparity in query optimization instead of architectural differences for MySQL and MongoDB.