Supporting Multiple Microsoft Teams Bots in One ASP.NET Core Application

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.

Common frameworks, libraries and design patterns I use

In this short post, I share some of the core frameworks, libraries and design patterns I worked with on a regular basis.

Notes on component coupling

In this post, I write about the three principles regarding component coupling that I have learned from reading the book “Clean Architecture : A Craftsman’s Guide to Software Structure and Design” by Robert Martin. The three principles are: Acyclic Dependencies Principle, Stable Dependencies Principle and Stable Abstractions Principle.

Notes on Component Cohesion

In this post, I summarize the three component principles regarding component cohesion which I learned from reading the book “Clean Architecture : A Craftsman’s Guide to Software Structure and Design” by Robert Martin. The three principles are: The Reuse/Release Equivalence Principle, The Common Closure Principle, and The Common Reuse Principle.

Notes on the three programming paradigms

In this post, I summarize the different programming paradigms which I learned from reading the book “Clean Architecture A Craftsman’s guide to Software Structure and Design” by Robert Martin. The programming paradigms are structured programming, object oriented programming and functional programming.

Notes on The Clean Architecture

In this post, I’m going to share my understanding of clean architecture after reading about it in the book “Clean Architecture” and other posts, as well as how I implement the clean architecture in an ASP.NET core project.

Notes on The Dependency Inversion Principle

The Dependency Inversion Principle is the last principle in SOLID. As a recap, SOLID is an acronym that stands for the five software design principles which Robert Martin discusses in his book “Clean Architecture – A Craftsman’s Guide to Software Structure and Design”.

• S: Single Responsibility Principle
• O: Open Closed Principle
• L: Liskov Substitution Principle
• I: Interface Segregation Principle
• D: Dependency Inversion Principle

Notes on the Interface Segregation Pattern

The Interface Segregation Pattern (ISP) is one of the principle in SOLID. As a recap, SOLID is an acronym which stands for the five software design principles:

• The Single Responsibility Principle
• The Open Closed Principle
• The Liskov Substitution Principle
• The Interface Segregation Principle
• The Dependency Inversion Principle

Notes on Barbara Liskov paper on data abstraction and hierarchy

In October 1987, Barbara Liskov published a research paper in which she discussed about different but related concepts: data abstraction, inheritance, encapsulation, implementation hierarch, type hierarchy and polymorphism. I’ve found the paper to be insightful and informative. In this post, I simply give a recap of what I have learned and share my thoughts from reading the paper.

The Liskov Substitution Principle

In the previous post, I wrote about Barbara Liskov research paper on data abstraction and hierarchy. In the paper, the author states a property which exists between type and subtype. That property later becomes known as the Liskov Substitution Principle. In this post, I continue to go over the principle in more details and give examples. The principle is one out of the five software design principles in SOLID:

• S: Single Responsibility Principle
• O: Open Closed Principle
• L: Liskov Substitution Principle
• I: Interface Segregation Principle
• D: Dependency Inversion Principle