We need to get one thing straight before we dive into Azure Mobile Apps and I get to tell why I fell in love with the concept: Azure Mobile Apps are the back-end, the API, the server layer of a Mobile App and it should be used as a back-end from your Web Apps or any other apps you may be building. The Azure Mobile App (misleading name, clarification was required by many developers) is an API with a beautiful SDK on top.
Let’s take a quick look at the ecosystem:

Thus, when I refer to Azure Mobile Apps I refer to the backend and the Mobile SDK is part of the client facing application. Here’s how I see it:

I like to think about myself as being a dedicated developer and technology enthusiast. Even so, I don’t believe I would become an expert in all of the following: Objective-C or Swift, Java, C# and .Net, Knockout, React or Angular. It’s quite a tall order.

I personally prefer Azure and C# – .Net (and the .Net Core is becoming this mature, clean and comprehensive framework I love to use) while building Asp.Net Web APIs and Angular apps with Cordova and worry about platform-specific exceptions while maintaining a single code-base.

Azure Mobile Apps is a feature of Azure App Service. This includes web hosting, Web API and Mobile DSKs.

Creating a new Azure Mobile App project is dead simple:


And getting the project to the cloud is a well-known, just as simple a process:



So Microsoft has really pulled together and, by merging the functionalities they started with in Mobile Services and bringing them all under Azure Web Apps, it has become easier to understand the project as an API and all capabilities offered as it shares security, scalability, development slots and continuous deployment and reliability with Web Apps configuration.

Any cloud connected app will use one or more services like:

  • Authentication
  • Structured or unstructured data access
  • Custom code
  • Autoscale (support milions of connections)
  • Social integration (Facebook, Twitter, Google, Microsoft)

Mobile cloud connected apps will also use

  • Push Notifications
  • Offline Sync
  • Broadcast push with customer segmentation

Worth pointing out that

  • All capabilities are available to clients through the Mobile SDK (your client side)
  • Authentication supports web and mobile flows, including use of native mobile SDKs, which are not easy with some frameworks. Using a client authentication SDK (from Facebook for example) does add a level of complexity before getting to market and come with a cost to the enterprise.
  • Using Azure PAAS capabilities provides an easier, no code capability and it is available, scales line nobody’s business, gets me to market sooner and since I am building on Azure, I don’t see it as an external dependency.

Publish from within Visual Studio should be reserved to early stages of development when the environment is still shaky and devs still try things out. Once the project is off the ground and the environment is defined, use DevOps. I personally prefer the integration offered by Continuous Integration and Continuous in Visual Studio Online.

Come back to my blog as I cover those topics in greater detail and don’t hesitate to comment or reach out to me on twitter.

All the code that will be presented in this series of posts is available on GitHub: https://github.com/badulescub/Server-Flow-Authentication—Demo