REST and GraphQL are the two dominant Application Programming Interface (API) architectures being used for communication with databases. They differ in a lot of aspects, and as such it is not immediately obvious which architecture is preferable. This thesis aims to shed some light onto this problem by exploring two aspects, developer experience, and performance. The method used to measure the developer experience was a case study, in which participants had to write code that communicates with a REST API and a GraphQL API and then answer questions that describe their experience communicating with both. To test the performance, a case study was done in which 5 different benchmarks were ran comparing the two. The results of the first case study show that GraphQL solutions were perceived to give a more overall picture of what is happening than REST solutions. REST was, however, viewed as easier to complete the tasks with. The results of the second case study show that a server that implements REST architecture has better performance during normal circumstances, but GraphQL shows better performance if data is being requested with specified fields. / REST och GraphQL är de två dominerande applikationsprogrammeringsgränssnitten (API) arkitekturerna som används för att kommunincera med databaser. De skiljer sig i många aspekter och därav är det inte uppenbart vilken arkitektur som föredras. Denna avhandling har som mål att reda ut detta problem genopm att utforska två aspekter, utvecklarupplevelsen och prestandan. Metoderna som användes för att mäta utvecklarupplevelsen var en fallstudie, där deltagarna fick skriva kod som kommunicerar med en REST server och en GraphQL server och sedan besvara frågor som beskriver deras upplevelse med att kommunicera med dessa. För att testa prestandan gjordes en fallstudie där 5 olika benchmarks kördes för att jämföra de två servrarna. Resultatet från våran första fallstudien visar på att GraphQL ansågs ha en bättre helhetbild av vad som händer gentemot REST, men när det kom till själva implementaionen av uppgifterna, ansågs REST vara lättare. Resultaten av den andra fallstudien visar att REST arkitekturen har bättre prestanda under normala omständigheter, men att GraphQL har bättre prestanda när datan efterfrågas med enbart specifika fält.

This paper explores an approach to extracting historical insights into a software keyword by data mining GitHub and Libraries.io. We test our method using the keyword GraphQL to see what insights we can gain. We managed to plot several timelines of how repositories and software libraries related to our keyword were created over time. We could also do a rudimentary analysis of how active said items were. We also extracted programing language data associated with each repository and library from GitHub and Libraries.io. With this data, we could, at worst, correlate which programming languages were associated with each item or, in the best case, predict what implementations of GraphQL they used. We found through our attempt many problems and caveats that needed to be dealt with but still concluded that extracting historical insights by data mining GitHub and Libraries.io is worthwhile.

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.