I detta examensarbete utforskas vilka överförings- och betalningsmetoder ungavuxna föredrar av Swish, Klarna och Tink samt tekniska implementering gällandekodkomplexitet för dessa överförings- och betalningsmetoder. Detta är viktigt för attkunna erbjuda överförings- och betalningsmetoder som unga vuxna känner sigtrygga med och till att denna målgrupp fortsätter gå mot ett kontantfritt samhälle.Studien syftar till att fylla det forskningsgap som finns kring en direkt jämförelse avdessa betalningsmetoder.Forskningen visar att unga vuxna föredrar metoder som är användarvänliga och harett starkt varumärkesrykte. Forskningen visar också behovet av att vända sigspecifikt till unga vuxna då dessa saknar finansiell kunskap inom området.En prototyp utvecklades för att jämföra kodkomplexitet mellan de mest populärabetalningsmetoderna Swish, Klarna och Tink. Kodkomplexiteten förimplementeringen av dessa metoder mättes med Cyclomatic Complexity, ochresultaten visade att Swish, Klarna och Tink alla har en liknande implementering viaAPI-anrop i sin enklaste form, vilket innebär att valet mellan dem inte innebär någonskillnad i kodkomplexitet.Utifrån jämförandet av kodkomplexitet valdes en komplett prototyp att utvecklas föratt funktionstesta en implementetion av Tink, med hjälp av Quarkus för logik-delenkallad backend och SwiftUI för utseende-delen kallad frontend. SwiftUI valdes föratt skapa en dynamisk och användarvänlig gränssnittsupplevelse för Apple-enheter,medan Quarkus valdes för sin robusthet och effektivitet på server sidan.Prototypen funktionstestades och utvärderades av produktägaren Peak AMSecurities AB. Resultatet blev att prototypens kodbas kan användas i framtidaproduktionssättning.Denna studie bidrar till insikt om unga vuxnas preferenser för digitalabetalningsmetoder och erbjuder en teknisk grund för vidare forskning inomområdet. Genom att jämföra Swish, Klarna och Tink ger arbetet viktiga insikter somkan hjälpa utvecklare att skapa bättre finansiella verktyg som möter användarnasbehov och förväntningar. / This thesis explores which transfer methods young adults prefer among Swish,Klarna, and Tink, as well as the technical implementation concerning code com-plexity for these transfer and payment methods. This is important to offer transferand payment methods that young adults feel comfortable with and to ensure thistarget group continues to move towards a cashless society. The study aims to fill theresearch gap regarding a direct comparison of these payment methods.Research shows that young adults prefer methods that are user-friendly and have astrong brand reputation. The research also highlights the need to specifically ad-dress young adults as they lack financial knowledge in the area.A prototype was developed to compare code complexity with the most popular pay-ment methods Swish, Klarna, and Tink. The code complexity for the implementa-tion of these methods was measured using Cyclomatic Complexity, and the resultsshowed that Swish, Klarna, and Tink all have similar implementations via API callsin their simplest form, which means they do not increase code complexity for devel-opers.Based on the comparison of code complexity, a complete prototype was chosen tobe developed for functional testing, implemented with Tink, using Quarkus for thebackend logic and SwiftUI for the frontend interface. SwiftUI was chosen to createa dynamic and user-friendly interface experience for Apple devices, while Quarkuswas chosen for its robustness and efficiency in server-side processing.The prototype was functionally tested and evaluated by the product owner Peak AMSecurities AB. The result was that the prototype's codebase can be used in futureproduction deployment.This study contributes to the understanding of young adults' preferences for digitalpayment methods and provides a technical foundation for further research in thearea. By comparing Swish, Klarna, and Tink, the work offers important insightsthat can help developers create better financial tools that meet users' needs and ex-pectations.

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.