Todays topic is “how do I upgrade the service backend to support the new ASP.NET Core service without affecting my current customers?” Let’s assume, for a moment, that I have already created an API Management service, and added caching to my API. Finally, I’ve adjusted the client application so everything is routing through the API Management service instead of direct to the backend.
In my last article I introduced API Management and showed how it can be used to provide a front door to the REST API that is exposed by Azure Mobile Apps. What I implemented was a simple pass-through. It didn’t support authentication, and if a link was returned (for example, the “next-page” link in a query result),it pointed right back at the original source. It wasn’t much of an improvement. I’m going to change that today with a couple of improvements:
Over the years, I’ve been asked for several features within Azure Mobile Apps that I’ve been reluctant to support out of the box. Azure Mobile Apps provides a toolkit in the context of the Node.js and ASP.NET Framework environments, so you can - theoretically - provide a lot of this functionality yourself. You can also use external services to provide that functionality.
Following on from last weeks article, I am continuing on my UI journey for my contacts app. My app design calls for a bottom app bar, with three sections - contacts, groups, and profile. The contacts and groups will be lists, and the profile will be a detail page for your own details with an editor.
I’ve started building a new app using Xamarin Forms from scratch. The idea is that I have a list of contacts stored in the cloud. There isn’t anything revolutionary about that, but I’m going to allow sharing of specific lists with others. You could, for example, create a tag called “Cycling Buddies”, and then tag your friends with that. Everyone who subscribes to the same list gets the same information. Even better, you can “broadcast” your information to certain groups, allowing other p...