ZUMO V2 AND AUTHENTICATION: MAKING THE CASE
In today’s dynamic technology landscape, it’s easy, as developers, to start building all that beautiful code while happily reinventing the wheel. Thankfully, design patterns and SOLID principles come in handy when it’s time to replace a piece of functionality while minimizing the overall impact to the application as a whole, as well as the hit to the bottom line.
I have committed to cloud development in general and Azure in particular and I do enjoy the details of cloud backed and enhanced mobile development. Mobile is a topic in which an Azure architect or developer feels very well and Microsoft provides security features to cover all enterprise and most consumer needs, including but not limited to social media authentication (Facebook Authentication, Google Plus, Twitter, Microsoft, OAuth … ) and Multi Factor Authentication.
Of course, there are specialized authentication providers out there that one may consider and I have personally used them in a few projects betting on these solutions already being tested and having answered questions about scalability, availability and disaster recovery. Being a dev I love getting my hands dirty and write the code so it covers my very particular need, yet as a dev, I recognize that we’re inclined to write, refactor, test, reinvent and lose sight that the project may never see the market.
A developer’s maturity comes with having to strike that balance and see the benefit of using paid per-use(r) services as a fantastic tool to move your project into the hands of consumers sooner, all in a reliable, disaster proof and scalable way.
Business arguments are those related to the impact to the bottom line and there is a tipping point when businesses may redirect the funds they funnel into a provider and hire a team of devs to reduce that external dependency, with interesting examples like: Dropbox (do not forget: they were already to market).
Zumo, Azure Mobile Services codename became Zumo V2 with the transition to Azure Mobile Apps: a server SDK running on top of a website. This alone is fascinating to me as you can use all the benefits of an Azure web application while consuming the API from Mobile and Web apps alike.
As you guessed, it runs on Azure, and to get started, you need and Azure Subscription. There are many ways you can get one and many ways are free for 30 days (free trial) or 1 year (Dev essentials) and there is even a Try App Service that lasts one hour but gets you access to a backend, although it is restrictive and you cannot alter backend code.
I’ll come back with new posts to run you through the setup and backend code access. I will be concentrating on an enterprise level solution with a C# backend and SQL server database, and for the next 10 posts, we’ll run through setting it up, configuring and using in a real-world scenario.
These posts assume you are knowledgeable about azure, web development and you understand C# and WebApi. We’ll also be using .Net Core to a certain extent so you may want to get the very basics of that too, but it’s not a requirement.
If you need to enter the basics of App Services, Microsoft defines that as:
App Service is a platform-as-a-service (PaaS) offering of Microsoft Azure. Create web and mobile apps for any platform or device. Integrate your apps with SaaS solutions, connect with on-premises applications, and automate your business processes.
You may read more on that in “What is Azure App Service?” and watch the very informative 4 minute video provided.
Also, if you are interested in App Service Pricing, Microsoft provides a clear enough breakdown but you may drop me a comment or a tweet and I’ll do my best to answer your specific question.
One note before I go: I will use .Net for the backend and asp.net core + Angular (and maybe Xamarin, I have not decided yet) for the frontend but App services allows you to build standards-based web apps and APIs using .NET, Java, Node.js, PHP, and Python.
