Creating amazing applications in Microsoft Teams is getting easier and easier each day. There is an ever increasing number of code samples and more on the internet. One area that doesn’t get a lot of attention is the backend development you might need. This isn’t Microsoft Teams specific of course, you could use this for any front-end application (React, Angular, etc) or may be needed in your next desktop application. Recently I’ve been working on a new Teams Application and the amount of data is LARGE. We are not talking 100’s or even 1000’s of rows but in the 100,000’s of rows of data.

As this information is captured it becomes imperative that your front-end application can easily handle this amount of data. A lot of applications (and I’ve been guilty of this) never test for the large set of data. Instead, test sets are really small, and when you reach critical mass (lots of data) suddenly your front-end application starts to fall apart because it’s simply requesting too much data.

Our Web API is going to be built on an Azure App Service using C#/.NET. Why? Because this is what I know and that is what I’m going to roll with. Additionally, I’ve opted to use Azure SQL Server instead of CosmosDB or another no-sql variant because I’m old school and still love me a good relational database.

Lastly to deal with the large data concerns we are doing to deploy OData in this environment. There are plenty of people, groups and even some organizations that seem to exist to hate OData. And some of the complaints are real. It can be a pain in the butt to setup on the front-end and it requires more backend code to produce a working API. But that said, the results are amazing. Not only do you have a working API endpoint but it’s a queryable language on it’s own. You want to only return a subset of items – use the $select command – need a count of items – use the $count command. So much fun. The other option we could have used in this project is GraphQL. It’s newer and has some fancy features. I decided to stick with OData because the learning curve is a bit less. Maybe down the road we can turn this into a GraphQL project.

As we deploy this we will use:

• Visual Studio 2019 (Can be free)
• .NET 5 Core
• Entity Framework 5.x
• OData 7.6.x
• Swagger

And all of this will of course be stored within GitHub. We need somewhere to run this. In this series I’m going to build everything within Microsoft Azure. And during this we are going to try to use as a few tools you may have never seen before. Our list of items we will use in Azure are:

• App Service
• Application Insights
• Azure SQL Server
• Azure Key Vault
• Azure DevOps

There are of course items that we build along that way that sit under this – like resource groups, app plans and more – but we can talk about those along the way. My hope is that as we walk through this together that we learn and really document the process. I’m not a developer by trade. I grew up on Novell Servers, GroupWise and ZenWorks – switched jobs and the next day I was installing Office Communication Server 2007. (Fun side story – that was the first time I had ever seen Microsoft Active Directory!)

So this series is as much for me as it might be for the next new developer. I may not hit every “industry” standard along the way but I’ll do my best to keep it secure. The last item of note is these might come out of order. Which I understand is going to be super annoying but as I build this out the first time I’m taking notes on roadblocks I run into. When I hit those roadblocks, I need to document it somewhere, so I’m going to do that here. Then I’m going to build the entire project again, taking screenshots and writing fun articles for each task.

My hope is each week I’ll get one article out. This would be a great pace for me so saying it publicly might make it happen.

With that…let’s get ready to write some code..