Introduction & Overview
Creating an App Service Web App
Configuring a Web App
Creating Web Service Containers
The course is part of these learning pathsSee 3 more
You’ve got an idea for a great web app, or maybe you’ve already started building it. The next question is how are you going to get it out there on the Internet?
In this course, you will learn how you can quickly and easily set up a website and publish your app to the world with Azure App Service. Of course, web apps are a lot more complex and varied than just HTML pages and we will see how App Service supports a range of programming languages, frameworks, and even operating systems. We will explore features that greatly simplify application deployment and management, as well as those that will increase your app’s functionality like authentication and accessing on-premise data. App Service as with other Azure products has a raft of tools for monitoring and logging so you can make sure your app is performing optimally.
For any feedback, queries, or suggestions relating to this course, please contact us at firstname.lastname@example.org.
- Deploy apps using the Azure App Service
- Create a web app using the Azure Portal
- Create a web app using Visual Studio
- Understand the configuration and diagnostic capabilities available from Azure App Service
- Understand the advanced features of the service such as container deployment and deployment slots
This is a beginner level course suited developers or anyone wanting to know how to deploy web apps to the Azure cloud.
To get the most from this course, you should have a basic understanding of the software development lifecycle, while knowing how to code would be a plus.
Course source code
Visual 2019 with .NET Core 3.1 was used for the demonstrations in this course.
Azure and mobile apps are where things get a little interesting and a bit confusing. In November 2019 Azure dropped Easy Tables and the mobile menu from the Azure portal, and the Azure Mobile API template has disappeared from Visual Studio 2019. Azure does retain explicit mobile support through the Microsoft.Azure.Mobile.Server and client SDKs under the traditional .Net 4.5 and above frameworks, just not in the .Net Core lineup. This technology hasn’t changed for the past 5 years and there are well-documented examples of how to use it.
So why has Microsoft dropped this mobile technology? Well they say it was underutilized, but it’s more likely that it didn’t fit well REST API standards, which in turn is probably why it has had low uptake. After all a mobile app is just another client, the same as a web or desktop application. It doesn’t make sense to have two APIs serving up the same information, one for mobile and one for other clients.
Sticking with the tracking theme I’ve got an API that performs CRUD operations on a pickup table. A driver has a mobile app that lists the pickups. The driver can add pickups and update pickups.
Here is the pickups controller. As you can see it bears a striking resemblance to the vehicles controller in the previous API. We have all the usual methods for listing items, getting a specific item, creating or posting an item and updating and deleting an item.
Having said that from an App Service point of view there is no difference between APIs serving different clients we can look at how a mobile or desktop app would interact with an App Service API. In this Xamarin forms app, we have a data store based on the pickup model. The data store is a gateway between the app and the API. There is a HttpClient that faces the App Service, and we have a generic GetResponse method for retrieving data from the API and casting it into the type we want. Next, there is a PostResponse method for sending our JSON formatted data to the API. The app interacts with the data store through specific methods like GetItemsAsync and AddItemAsync. In this way, the main workings of the app don’t need to know about the mechanics of interacting with the API. Let’s just have a quick look at it in action. Here we have the current pickups which we can drill into and we can add a pickup. As this is just an unpolished demo I need to refresh the list to see the new record id that has been created as part of the database insert. I’ll just flick over to the Azure SQL database to show the newly inserted record.
One important aspect that is missing from this example. and that Azure doesn’t yet cater for in its new vanilla .net core REST JSON world, is offline sync. What happens when there is no network connection. I suspect Microsoft realized that many developers were coming up with their own or using third-party solutions rather than using the non-REST, Azure mobile SDK libraries. So, how would you go about implementing offline synchronization? There are a multitude of ways to skin the proverbial cat. But first and foremost you must implement local storage on your device, and SQLite has become the defacto standard for lightweight databases. You write your app logic as a stand-alone application talking to a local database. All inserts and updates are simultaneously written to a send queue, which under normal circumstances will dispatch the JSON data immediately to the App Service, but if there is no connection the data will remain in the queue until connected. In terms of retrieving data from your API, it depends on whether you are polling the app service or using push notifications. If you are polling then you are only interested in data that has been modified or created since you last connected, so timestamping your updates is crucial. You could compare the new incoming data with that in you send queue to make sure what you are about to send won’t overwrite newer data. I know this may sound trivial, but when you’re dealing with apps running in different time zones it’s important to make sure that all your date comparisons are done in the same time zone.
About the Author
Hallam is a software architect with over 20 years experience across a wide range of industries. He began his software career as a Delphi/Interbase disciple but changed his allegiance to Microsoft with its deep and broad ecosystem. While Hallam has designed and crafted custom software utilizing web, mobile and desktop technologies, good quality reliable data is the key to a successful solution. The challenge of quickly turning data into useful information for digestion by humans and machines has led Hallam to specialize in database design and process automation. Showing customers how leverage new technology to change and improve their business processes is one of the key drivers keeping Hallam coming back to the keyboard.