The aim of this thesis is to analyze, design and implement solution for selling merchandise, which sellers can be used with commonly used hardware, free in basic package and they should be able to handle system setup. As a result, sellers can avoid new operating costs. The system will run as a service on Heroku servers. The front-end and back-end is implemented in JavaScript, front-end also uses React. GraphQL is used for communication between frontend and back-end. The data is stored in the PostgreSQL relational database, but also is used the Redis database, which runs tasks in the background.

It is only a matter of time before the Swedish Companies Registration Office makes digital registration of annual reports/auditors reports mandatory. At the time of writing, there are only ten public integrators currently able to handle this requirement. In collaboration with one of the big four accounting firms, this project aims to evaluate performance of the response time while using GraphQL versus REST in Web APIs. The application under test is a .NET application integrating to the Swedish Companies Registration Office API. Through a controlled experiment using two different GraphQL frameworks, HotChocolate and GraphQL for .NET, this thesis provides a knowledge base for the partnered accounting firm, developers and other stakeholders that are evaluating the use of GraphQL in their future applications. Results  from the experiment indicate that HotChocolate in its current version is not only faster than its competitor GraphQL for .NET, but also faster than REST. This is surprising, given that other related work seems to suggest that this is not always the case. Testing of GraphQL for .NET gives a more traditional result when compared to other related work. Given the results, a senior developer of HotChocolate was contacted to gain insight to why the framework outperforms not only GraphQL for .NET but also REST. The senior developer states that a large amount of effort has been put in to make the GraphQL execution engine more optimized, something that is corroborated by this thesis experiment. HotChocolate is also periodically measuring and comparing performance benchmarks to other libraries to conclude on its performance in different scenarios. The analysis of the experiment concluded that there exists another important variable previously not identified in other research, more precisely the chosen framework, that has a large impact on performance and can impact both memory allocation and response time.

Max Gordon is a researcher at the Karolinska Institute who works with developing a deep learning algorithm for interpreting orthopedic X-ray images. It is using radiologist’s reports in order to deduce labels that are of interest such as presence of fracture, osteoarthritis and other features. The previous image viewer’s interface Swagger had issues in terms of managing the stored data. This could potentially be solved by switching to GraphQL according to Max Gordon. On request by Max Gordon studies were conducted in order to conclude if Swagger or GraphQL was more compatible with the medical CE-marking and which was more suited for expanding the system. The studies mainly consisted of measuring interpretability at different target groups and how they faced Swedish law when it came down to handling personal data. Based on the qualitative and quantitative studies, the conclusion was drawn that Swagger was more compatible with the medical CE-marking and expansion of the image viewer. / Max Gordon är en forskare på Karolinska Institutet som arbetar med att utveckla en algoritm och tillämpning vilket kan tolka röntgenbilder. Denna används tillsammans med rapporter från radiologer för att kunna utreda röntgenbilders egenskaper. Den föregående bildvisarens gränssnittsspecifikation Swagger hade problem med att hantera den lagrade datan, detta kunde potentiellt lösas genom att använda GraphQL, enligt Max Gordon. På begäran av Max Gordon skulle kompabiliteten mellan GraphQL och CE-märket utredas. För att kunna dra slutsatsen om GraphQL eller Swagger var mest lämplig för CE-märket och vilken var mest anpassad för vidareutveckling av bildvisaren i framtiden. Detta genom att jämföra resultatet av fallstudier på Swagger och GraphQL som huvudsakligen undersökte hur god språkens tolkbarhet var hos olika målgrupper, samt hur hanteringen av persondata förhåller sig till den svenska lagstiftningen. Baserat på de kvantitativa samt kvalitativa undersökningarna ansågs Swagger mest kompatibelt med CE-märkets krav och vidareutveckling av bildvisaren.

Detta examensarbete är baserad på ett projekt hos SPV. Den presenterar resultaten av en studie som syftar till att utvärdera och jämföra prestanda hos olika webb-API-tekniker och hanterare. Syftet med denna forskning var att välja lämpliga webb-API-tekniker som uppfyller funktionella krav och distribuera dem på noggrant utvalda API- hanterare för att dra slutsatser om deras prestanda. Studien fokuserade på att jämföra REST och GraphQL webb-API-tekniker sedan distribuera dem på två API-hanterare WSO2 och 3Scale. Både REST och GraphQL API har sina egna fördelar och nackdelar, där användningsområdet och API:ets funktionskrav bestämmer vilken som är bäst. Dessutom REST API är kända av sin enkla implementering och resurshantering medan GraphQL API är mer lämpliga med hantering av komplexa relationer. Detta projekt tolkar att REST API överträffade GraphQL API över båda APIhanterare. Dessutom visade resultaten att API-hanterare WSO2 uppvisade någon snabbare svarstid för både REST och GraphQL API jämfört med 3Scale. Projektets resultat bidrar till den vetenskapliga förståelsen av webb-API-tekniker och hanterare samt att den ger värdefulla insikter för framtida forskning och utveckling. Den dokumenterade källkoden och data, tillgängliga på GitHub, säkerställer transparens. Etiska överväganden demonstrerades också, med betoning på ansvarsfull användning av dataskydd av användarnas integritet. / This thesis is based on a project at SPV. It presents the results of a study aimed at evaluating and comparing the performance of different Web API technologies and managers. The objective of this research was to select appropriate Web API technologies that meet functional requirements and deploy them on carefully selected API handlers to draw conclusions about their performance. The study focused on comparing REST and GraphQL web API technologies, then deploying them on two API managers WSO2 and 3Scale. Both the REST and GraphQL APIs have their own advantages and disadvantages, with the use case and the API's functional requirements determining which one is best. Moreover, REST APIs are known for their simple implementation and resource management while GraphQL APIs are more suitable with handling complex relationships. This project interprets that the REST API outperformed the GraphQL API across both API managers. In addition, the results showed that API manager WSO2 exhibited slightly faster response time for both REST and GraphQL APIs compared to 3Scale. The project's results contribute to the scientific understanding of web API technologies and handlers and provide valuable insights for future research and development. The documented source code and data, available on GitHub, ensures transparency. Ethical considerations were also demonstrated, emphasizing the responsible use of data protection of user privacy.

В данной работе проведено исследование для создания программного обеспечения управления контролем качества, позволяющего автоматизировать процесс оценки агентов, а также постановку задач менеджерам по контролю качества. Предметом исследования является разработка программного обеспечения, которое обеспечивает автоматизацию выбора взаимодействия агента и клиента, создание оценочных карт, отчетов о качестве, управление персоналом и многое другое. / In this work, a study was carried out to create a quality control management software that allows you to automate the process of evaluating agents, as well as setting tasks for quality control managers. The subject of the research is the development of software that automates the choice of interaction between the agent and the client, the creation of scorecards, quality reports, personnel management, and much more.

Over a few years back, REST APIs were considered standard web APIs, which nowhave a strong competitor. REST APIs provide some excellent features like stateless serversand structured access to resources. However, over time, it doesn’t offer flexibility withthe access of data and client changing requirements. In 2015 GraphQL was introduced byFacebook, which overcomes the problems with the REST and provides more flexibility andefficiency to the client requirements. For example, remove the over and under fetching.To change the existing APIs into GraphQL APIs require considerable time and effort.Therefore, some server implementation tools are developed to reduce the developmentcost and time. A few of these tools generate GraphQL schema and server implementationsautomatically over a legacy database.This master thesis studies tools that automatically generate GraphQL server implementationover legacy databases and evaluate such generated GraphQL server’s performance.First, we find some GraphQL server implementation tools such as Hasura andPostGraphile and then compare the server’s performance using benchmark methodology.Secondly, we run an experiment on a computer system and use the performance metricsfor assessment. The results of our experiment concluded that PostGraphile has higherthroughput and low query execution time as compared to Hasura. In most of the querytemplates from the benchmark, PostGraphile outperforms Hasura.

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.

Recent supply chain attacks on a larger scale in combination with a growing adoption of the set of automated software development and deployment practices commonly referred to as ’DevOps’, made us interested in the security of the underlying infrastructure supporting these practices. If a malicious commit in a piece of software can expose internal systems and networks of all users of said software to vulnerabilities, questions regarding trust and repudiation becomes central, in the platforms themselves as much as in each digitally signed software update version. GitLab is a DevOps platform that offer an open-source (Community Edition, (CE)) of their application, for anyone to use and even modify to better suit their own needs. Anyone who chooses to use GitLab will as a result thereof also choose to put the trust others put in them in the hands of the open-source community around GitLab. Since any vulnerability in GitLab could affect users or organizations that use software developed and shipped with the help of GitLab, we wanted to try finding one for ourselves. We employed well-known techniques from the ethical hacker playbook (threat modeling, risk assessment) in order to identify candidates for attack vectors, and found GitLab’s GraphQL Application Programming Interface (API) to be a great starting point since it not only was but still is under development, but that the body of previous work seemed to suggest inconsistencies in the business logic layer underneath. Our main findings are: at least two instances where we were able to gain unauthorized access to data within our self-hosted GitLab instance. We also found that a new feature could be used for privilege escalation under certain conditions. We were then able to conclude that open source software and a prolific bug bounty program does not guarantee the security of GitLab, in and of themselves. All findings have been reported to GitLab through their bug bounty program. / Under det senaste decenniet har mjukvaruutvecklande organisationer visat ett tilltagande intresse för de metoder för automatiserade utvecklings- och distributionstekniker som vanligen brukar samlas under termen DevOps. Den trenden taget i kombination med det senaste årets större försörjningskedjeattacker (SolarWinds, Microsoft Exchange Server) gjorde att vi började intressera oss för säkerheten kring den infrastruktur som möjliggör dessa metoder. Om en utvecklare med ont uppsåt lyckas få in en ändring i en mjukvara innan den digitalt signeras och distribueras till mjukvarans användare, kan denne lyckas utnyttja svagheten för att få tillgång till eller modifiera de system och nätverk mjukvaran körs på. Frågor om tillit och avsändarintegritet kring vem som står bakom ett kodavsnitt blir i förlängningen därav oerhört viktiga. GitLab är en DevOps-plattform som erbjuds i en version med öppen källkod, vilken alla kan använda och rent av anpassa för sina egna behov. Att använda GitLab innebär dock att man lämpar över den tillit och säkerhet ens användare lagt i ens händer på de som utvecklar plattformen. Eftersom en enskild sårbarhet i GitLab potentiellt kan påverka ett stort antal aktörer som aldrig själva använt GitLab gjorde att vi ville se efter om även vi kunde hitta en sådan sårbarhet. Vi använde oss av välbekanta metoderi etisk hackning-kretsar (hotmodellering) genom vilka vi identifierade GitLabs GraphQL-Application Programming Interface (API) som en potentiellt gynnsam attackvektor. Detta både eftersom API:t fortsatt är under utveckling och att tidigare forskning antytt logiska brister i applikations-lagret. Arbetet ledde fram till ett par fynd. Vi fick åtkomst till otillåten data vid två tillfällen. Med hjälp av en ny funktionalitet kunde vi under vissa omständigheter utöka en användares behörighet. Vi kunde därmed dra slutsatsen att öppen källkod och ett väletablerat bug bounty-program inte i sig är några garantier för säker mjukvara. Samtliga fynd har rapporterats till GitLab via deras bug bounty-program på plattformen HackerOne.

Nowadays, smartphones are one of the main mediums to transfer content to clients and they provide a good interface for the delivery of digital therapeutics (DTx). Application Programming Interfaces (APIs) are keystones for any service-based mobile application to manage the data transfer between the clients and the server(s). At the time of writing, REST and GraphQL are arguably the most popular API types. These APIs provide simplicity, efficiency, and scalability for data-driven applications. However, we can question the validity of these qualities when it comes to content-driven applications such as DTx apps for example. The objective of this project is to decide whether common data-driven API types are suitable for products where the content is not created by the users, but by content creators, or if a new API type could be developed which is more suitable for this use case. Useful insights are presented on how standard APIs should be adapted to address this problem. Moreover, this document presents a new prototype of API that is supposed to help content creators with content creation while providing high performance. Additionally, an advanced test platform is introduced in order to help the comparison of the implementation in terms of performance. This thesis shows that GraphQL is not a suitable method for the initial problem. It also shows that REST is a good standard adapted for scalability in the present scope. The prototype displayed guarantees great performances by means of preloading, thus, suffers high concurrency in terms of performances when scaled up. However, potential solutions are given in order to counter this. / Smartphones är idag ett av de viktigaste verktygen för företag att leverera innehåll till användare och de utgör ett bra gränssnitt för digitala terapier (DTx). API:er (Application Programming Interfaces) är en grundsten i alla tjänstebaserade mobilapplikationer för att hantera dataöverföringen mellan klienterna och servern/servrarna. I skrivande stund är REST och GraphQL de mest populära API-typerna. Dessa API:er anses vara enkla, effektiva och skalbara för många tillämpningar, däremot är de inte nödvändigtvis optimala för innehållsdrivna applikation såsom DTx-appar. Syftet med det här projektet är att avgöra om vanliga datadrivna API-typer är lämpliga för produkter där innehållet inte skapas av användarna utan av innehållsskapare, eller om en ny API-typ kan utvecklas som är mer lämplig för detta tillämpningsområdet. I denna rapport presenteras insikter om hur standard-API:er bör anpassas för att lösa detta problem. Dessutom presenteras i en ny prototyp av API som hjälper innehållsskapare att skapa innehåll samtidigt som den ger hög prestanda. Dessutom presenteras en avancerad testplattform för att underlätta prestandajämförelser. Denna avhandling visar att GraphQL inte är en lämplig metod för innehållsdrivna applikationer, emedan REST är det. Den prototyp som presenteras garanterar bra prestanda med hjälp av så kallad pre-loading, även om prestandan försämras väsentligt vid hög belastning, även om potentiella lösningar föreslås för att åtgärda detta.

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.