The first challenge to tackle was what do I need to convert my current service into an AppService? Actually, the real first challenge was: What is an AppService?
Developers usually don’t want to deal with anything about services or server setup. AppServices in Azure fixes this. When you create an AppService, after specifying how much power you need, you get an Url that points to it, and that’s all the set up you need. This removes all the difficulties that you might have with permissions, users, server ports, etc. Plus you can get automatic insights, how your AppService is behaving.
There are many ways to deploy code to an AppService, the main two I opted for are using Visual Studio and using Bitbucket Pipelines. Visual Studio 2019 has an easy to use “Publish” option for a project; you select publish, you get a pop-up where you log in to your Azure account, select the Resource Group, then either a new AppService or an existing one. And that’s it!
As for Bitbucket Pipeline, it’s just as easy and you get the added benefit of connecting directly to source control. In the AppService, you connect to the repository and choose which branch to pull from, if there is a change in that branch, Bitbucket will send the code to the AppService and it will deploy automatically. This is called Continued Integration/Continuous Delivery, or CI/CD.
Because I want to optimize resources, I had to restructure the code to be able to use the same AppService for multiple clients. There are many ways to skin a cat and the way that I decided to do it was to include a unique Client Code into the Url. this change had to be propagated to the database. Originally each client would have their own database, so this wasn’t a concern.
A client would only be able to see and manipulate their data. To make this part more secure, I will be including the Client Code into the security features so both values have to match, otherwise, we boot the user out.
Next Up, I’ll talk about how I didn’t need to store passwords in-app
Leave a Reply