Reactive vs Non-Reactive Java framework : A comparison between reactive and non-reactive APIs

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