- Home>
- Software Development
Since the advent of Large Language Models (LLMs), we have been leveraging the technology to streamline processes and improve staff efficiency. One of the things LLMs are good at is coming up with coherent text based on a given context. Leveraging this strength, we have applied the Retrieval Augmented Generation (RAG) pattern to build chatbots that help staff across different areas, including human resources, contract management, and other department-specific procedures. For the user interface of the chatbots, we use Microsoft Teams, as it’s our primary communication platform. The bots’ functionalities are quite similar in nature, in the sense that they all pull data from a data store by calling APIs, sending the user’s chat message, and replying to messages in Microsoft Teams. However, because each bot requires a different category of data for use as the LLM’s context, we need a separate Microsoft Teams app for each bot. Behind the scenes, the Teams app calls the corresponding web API, which is an ASP.NET Core application, to send and receive messages. The ASP.NET Core applications are very similar in nature, in that they all call APIs to get the LLM’s response for a user’s request. As such, we were thinking of ways to minimize code duplication and the infrastructure needed to support multiple bots. In the web API, we follow a clean architecture with infrastructure, a shared kernel, a domain layer, and other typical layers. One approach I thought of was that we could reuse all the layers except for the web API. We would have one web API project for each bot we want to support. However, that approach still requires separate infrastructure for each bot—things like Key Vault, App Insights, Blob Storage, etc.—since each bot is a separate app that serves a different domain. Luckily, after some back-and-forth discussions with GitHub Copilot and reading sample code, I tested and found a way to support multiple bots using the same codebase and infrastructure.
Continue readingIn the past, I’ve worked on software projects where there were many model classes with very similar properties. I often questioned the necessity of having multiple models that appeared almost identical, as this approach seemed to introduce code duplication and unnecessary complexity. On the other hand, I’ve also contributed to projects where a few large, multipurpose model classes were used. These projects often suffered from inflexibility and the potential for widespread issues whenever modifications were required, as changes to one model could impact multiple components. In software development, the principle of ‘separation of concerns‘ is important for creating maintainable and scalable applications. Personally, I’ve come to favor using separate models to adhere to this principle. In this post, I’ll discuss the using shared versus separate models through a recent project example—a Blazor web application I worked on for building chatbots.
Continue readingIn this post, I share my knowledge and experience in developing a bot application for Teams using the Microsoft Teams Bot Framework. I will outline the key components involved in developing a bot application and explain how communication securely flows between an end user and the bot.
Continue readingIn this post, I share an example of how I use a HttpMessageHandler
to automatically attach a bearer token when calling a web API from an ASP.NET Core/Blazor application.