La programación reactiva es un paradigma enfocado en el trabajo con flujos de datos de manera asíncrona. En este webinar veremos cómo Spring Framework implementa la programación reactiva con WebFlux.

To develop a high performant web service in Java, Reactive WebFlux has previously been utilized as the only alternative. With the introduction of virtual threads in Java 19, it has been considered that it would be an alternative to the current provided option. This paper presents the performance difference between Spring applications powered by normal threads, virtual threads, and its reactive counterpart Reactive WebFlux. The tests were done by creating three prototypes, which were used to call an endpoint with a set delay time and increasing the number of requests per second until system failure. The results show that the virtual threaded prototypes performed slightly better than the reactive prototype. The question remains whether the Reac- tive WebFlux application using the most optimal web server produces a different re- sult, as well as future research on how virtual threads perform with database usage. / För att utveckla högpresterande webbtjänster i Java har Reactive WebFlux varit det främsta alternativet. Med introduktionen av virtuella trådar i Java 19 har spekulerats kunna ersätta reaktiva webbtjänster. Detta arbete presenterar prestandaskillnaden mellan Spring-applikationer som drivs av normala trådar, virtuella trådar och dess reaktiva motsvarighet Reactive WebFlux. Testerna utfördes genom att skapa tre pro- totyper, som användes för att anropa en slutpunkt med en satt fördröjningstid och öka antalet förfrågningar per sekund fram till systemfel. Resultaten visade att proto- typen med virtuella trådar presterade något bättre än den reaktiva prototypen. Där- emot är det ännu oklart om Reactive WebFlux-applikationen med en optimal webb- server skulle producera ett annat resultat. Dessutom skulle det vara intressant för framtida forskning om hur virtuella trådar fungerar med databasanvändning.

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.