Vill man bygga en API tjänst idag existerar det en mängd olika ramverk att välja mellan, varav några av dessa använder reaktiva system. Denna teknik tillåter värden att använda sina resurser på ett mycket mer effektivt sätt än med de icke reaktiva ramverken. Två ramverk som kan användas för att utnyttja denna teknik är Spring Boot och Quarkus. Spring Boot är ett väl etablerat API ramverk med mycket inbyggd funktionalitet som hjälper utvecklare att bygga robusta API tjänster. Quarkus å andra sidan är ett nyare ramverk med fokus på att vara en liten och lätt API som är främst för containers. Även fast dom fokuserar på olika saker borde dom i slutet presentera på samma nivå och ge snarlika resultat. Målet med denna studie är att jämföra reaktiva API tjänster med icke-reaktiva API tjänster med hjälp av Spring Boot och Quarkus. Samt svara på frågor om vilket ramverk och teknik som är den bästa för olika scenarion. För att få kunskap om ämnet om reaktiva system gjordes det först en teoretisk studie för att veta vad som definierar ett reaktivt system samt vad som krävs av operativsystemet för att exekvera en sådan tjänst. För att kunna utföra jämförelsen byggdes det en reaktiv samt icke-reaktiv variant av de två olika ramverken som ger totalt fyra applikationer att jämföra. Flera olika tester var byggda och exekverade på de fyra olika applikationerna. Resultaten visade att reaktivt Quarkus var överlägsen jämfört med de andra applikationer när storleken på transaktionerna var små. I de fall att transaktionerna var stora eller behövdes behandlas var istället Spring Boot bättre. Jämförelsen av CPU- och minnesanvändning resulterade i att reaktivt Quarkus använder både mindre minne och använder mindre CPU. / As technology evolves, more and more companies strive to automate as much work as possible. The use of chatbots in messaging apps is becoming more and more common as replacements in the operation of customer service because of the efficiency and reliability it poses. Replacing customer service with chatbots also saves companies money. In this paper an IT company have asked for the implementation and proof of concept of integration between their server-side application, to Microsoft Teams. They want it to be possible to use a chatbot in Teams to send tickets containing data to their system in order to be handled by users of their application. In this paper a solution to this problem is described as well as discussions about the chosen implementation. The discussion is focused on the final solution, user tests, related work, ethical issues as well as future work. User tests of the implemented solution are included in the results. The conclusion of the work is that this implementation is useful and saves time and effort both for the customer and the employees. There is much potential for future work to be expanded upon, including specialized Ticket Forms and implemented AI.

The accelerating progress in network speeds and computing power permitted the architectural design paradigm to shift from monolithic applications to microservices. The industry moved from single-core and multi-threads, code-heavy applications, running on giant machines 24/7 to smaller machines, multi-cores single threads where computing power and memory consumption are managed very critically. With the advent of this novel approach to designing systems, traditional multi-tier applications have been broken down into hundreds of microservices that can be easily moved around, start, and stop quickly. In this context, scaling assumed a new meaning, rather than scaling up by adding more resources or computing power, now systems are scaled dynamically by adding more microservices instances. This contribution proposes a theoretical study and a practical experiment to investigate, compare and outline the performance improvements aid by the implementation of Protocol Buffers, Google's language-neutral, binary-based representational data interchange format over traditional text-based serialization formats in a modern, Cloud-Native, REST-based Java Microservice architecture. Findings are presented showing promising results regarding the implementation of Protobuf, with a significant reduction in response time (25.1% faster in the best-case scenario) and smaller payload size (72.28% better in the best-case scenario) when compared to traditional textual serialization formats while literature revealed out-of-the-box mechanisms for message versioning with backward compatibility.

Att utveckla applikationer med mikrotjänstarkitektur har idag blivit ett trendande tillvägagångssätt för att skapa tjänster som är anpassade för att köras i molnet med fördelar som mindre underhållsarbete och lättare skalbarhet. Mikrotjänster kännetecknas som löstkopplade och oberoende tjänster som kommunicerar genom att exponera ett API. För många populära programmeringsspråk, som till exempel Java, finns det flera ramverk att använda för att underlätta utvecklandet av mikrotjänster. Företaget Redpill Linpro i Karlstad, som är uppdragsgivare för den här studien, använder sig idag av Javaramverket Quarkus vid utvecklandet av mikrotjänster. De är dock intresserade av att veta hur mikrotjänster som utvecklats i Quarkus jämför sig prestandamässigt mot mikrotjänster som utvecklats i ett annat programmeringsspråk. Redpill Linpro har märkt att intresset för programmeringsspråket Go har ökat på sistone. I Gos officiella dokumentation rekommenderas ramverket Gin för att få bättre prestanda när det kommer till att utveckla tjänster som exponerar ett API. Redpill Linpro har tilldelat författaren av denna uppsats ett uppdrag att utveckla mikrotjänster med hjälp av ramverken Quarkus och Gin för att studera skillnader i prestanda samt beskriva tillvägagångssättet för hur utvecklingen av mikrotjänsterna gått till. Studien syfte är att identifiera vilken av mikrotjänsterna utvecklade i Gin eller Quarkus som presterar snabbast beträffande kompileringstid och uppstartstid, skillnader i filstorlek och skillnader i responstid vid HTTP-anropen GET och POST med och utan koppling till databas. Även vilken mikrotjänst som använder minst CPU-kraft och RAM-minne. Studiens resultat visar för- och nackdelar med båda ramverken men att mikrotjänsterna skapade med Gin presterade bäst i flest antalet parametrar som mättes i den här studien.