Have you ever heard about the Serverless Mobile Application method? In this post I’ll talk about a technique to connect your mobile app to the cloud with less effort.

You want to create your connected mobile app

You already know mobile development or you have never compiled your own application yet ? It doesn’t matter, I will frame the context so that everyone can understand.

To develop a mobile application, there are several technologies. I will talk about them in an other post later, that is not what we are interested in here. What you have to remember is that a mobile application, to be connected, is like a web site : you need a server that centralizes the data. And what is the problem ? Developing a mobile application and developing a server is like a cow and a fly : it is completely different and yet it always goes together.

What is the role of the back-end server in relation to the mobile application ?

The back-end server is used to store and deliver data to the mobile application. All the data are stored in the same place, in the server, and the mobile application just has to query the server to obtain the data in order to display it to the user.

Similarly, all business intelligence and algorithms must be done by the server, not by the mobile application. This for various reasons :

• The first and most important : to centralize the effort. If tomorrow I associate a website with my mobile application, I will only have to connect the site on the same server as my application, without having to recreate the algorithms of business logic. Similarly with an Android or iOS app.
• The second, and no less important than the first : the business algorithms will be coded only once, in the server. If there is a bug or modifications to do, the work will be done once, in one place, and will be reflected everywhere (mobile applications, possible websites, etc …)
• Finally, a server is a machine with powerful computing resources, unlike a smartphone that has much lower calculation capabilities : too slow.

In short : the back-end server is the brain and the mobile application is the interface between the user and the data.

How does a classic back-end server work ?

In a very conventional way, a back-end server is made of a database and an API linking the database to the outside of the server. By saying outside, I mean your mobile app, your website, or any other single query. Remember that hackers’ robots are constantly trying to access random addresses (including your APIs), and once they have found a valid address, they try known security flaws to hack your data. Anyone can access your API, you have to secure it.

Technically, the outside can access the database directly by having appropriate identifiers, without going through an API. This saves the production of an API. But this is highly not recommended ! First, because it forces the developer to create business logic outside the server. But the worst reason is because it opens doors to hack the database.

In other words : a back-end server includes a database and an API that serves as an entry and/or exit gate.

What way to reduce the effort of setting up a back-end server ?

I want to talk about a particular technique, called “Serverless Backend for Mobile Application”. James Montemagno perfectly detailed it on the Xamarin blog. This technique does not invent anything, but it allow you to use the Microsoft latest tools in order to get rid of a maximum of work, during the creation, the development or the maintenance.

The purpose is to use Microsoft Azure in order to code only the strict necessary. All the rest being supported automatically by Azure. Let me explain : actions such as “checking the rights of a user” or “managing a thread pull to process all incoming requests to the server” are generic actions to any project. It’s a waste of time to re-develop them each time. On the contrary, the strict necessary for an application is the business logic, the algorithms specific to the application, access to the database, etc …

Using the Serverless Backend for Mobile Application method allow you to code only the business logic. All the rest being automatically supported by Microsoft Azure. There is even no need to code on his computer and put the code into the online server : you can code directly in your internet browser ! This simplifies and greatly accelerates the creation of APIs for your mobile application project.

Let’s go, I want to try ! Where to start ?

Congratulations ! I’m glad I’ve convinced you to try ! But above all, I invite you to read my feedback on the Gotago project to get an overview of the pros and cons of this method. Any method is indicated in some cases, as it may be contraindicated in other circumstances. This one, in particular, is advised for rather short projects, or POC.

To start, you must have a Microsoft Azure account. Everything is free up to a certain threshold (which I did not exceed in several months of development).

In Azure, you can create, host, and administer your database with SQL Server. You will be able to use a database visualization tool of your choice. Personally, I use Visual Studio.

For your API, you will create a Function App. This one will consist of HTTP Triggers. An Http Trigger is a script executed, as its name implies, by an Http request to a specific URL. You can do a GET, a POST or anything else, and use JSon to transfer data for instance. You will create your business logic in these Http Triggers, and you will use URLs from your mobile applications or websites to send or retrieve JSon. And that’s all ! Nothing more to do.

A small example before the end

Here is a small example of an Http Trigger in Azure. I’m about to show you an API that checks the validity of a user email address. For instance, when a user subscribes to your application, he should not use an e-mail address already used.

I will have an URL : https://api-monexemple.azurewebsites.net/api/isemailvalid

In a POST Http request, I will pass a JSON string : {email: “my@email.com”}

As a result, the URL will return a JSON string with the verified email address, and the result of the check : {email: “my@email.com”, isValid: true}

Then I could make an HTTP request to the URL from anywhere ! My Android application, my iOS app, my website… Also, the email verification algorithm can change at any time, the only change to be made will be on the API.

  Coding interface directly in the browser

The window below represents my web browser in which I have coded my HTTP Trigger. You see the code at the top left, the test window on the right, and the console at the bottom left.

The code window allows me, as you guessed, to code my API. I do the “includes”, I decrypt the body if it is a POST request, I call the function for the business logic code, and I send a response with the result of the business code.

The test window allows me to simulate a fully customized API call. It’s useful to test your development ! Without this window I should have to run my Android or iOS application and click the button that calls the API … Once the call was made in test, I have the result directly below, in green, with the associated returned string.

The console window, gives all the information on the code. If the code compiles or not, where are the errors … We also have the traces in case of call to the API. These traces can be found in an other place : in the monitoring window. The latter provides a history of all calls made to the API. It is essential to maintain its service.

  API business code

The window below shows the business code that verifies my email address. I removed the test windows and the console for more readability :

First, the code checks the format of the email address.

Then, the API connects to a database, and performs a SQL query to check if a user with the same email address already exists. The SQL database can be hosted on Azure, free up to a certain threshold. It can also be hosted elsewhere.

Finally, here is the class to manage the JSON of the HTTP request :

By using this class and the Newtonsoft.Json nuget package, I can serialize and deserialize JSON in a single line ! Extremely convenient isn’t it ?!

And you, what methods do you use to create your API ? What architectures do you use for your web and / or mobile platforms?