30 October, 2016

Building a single (cloud-based) backend supporting multiple mobile apps

Being the architect as well as hands-on implementor of a real-life system supporting a number of concurrent mobile applications (in both Google Play and Apple AppStore); I’ve learned a thing or two during the development and evolution of this system (now in gen. 3). What are my take-aways from this process? And what are the pit-falls?

Before we dive into the meaty part - maybe you should ask: why are we looking for one backend-system and not a bespoke and optimized backend-system supporting each specific mobile application? Wouldn’t that be a better approach? Well - I think it goes without saying; but the cost and effort of maintaining several different systems when you can do with just one aludes to a pretty good reason seen through my set of financial eyes.

Obviously - there are limits to how different these mobile (client) applications can behave and still being supported by the same system (you can’t mix automobile apps with fitness apps, can you?), but given that most companies tend to produce applications within the same realm or domain - it does make sense in a company-setting to strive for an as simple and generic system as possible. So that’s what we are trying to realize.

Before we move on - the audience to benefit most from this post will primarily be system architects, secondly developers as it becomes rather technical as we walk through the system...


The overarching goal is to have a system that can support not only your current applications, but also new applications that you do not yet know. Furthermore, the system should be able to respect different “twists" the mobile applications can exhibit. How can you realize this goal?


An idea of the overall picture is required before diving into the specifics. You need to be able to see that before you can appreciate the details. The overall picture looks like this:

System components


The graphics above can seem like a lot of arrows, but the key concept is that there is a Token System responsible for supplying the mobile Clients with a Token provided the credentials they present are accepted. This token is next presented in every call to the WebAPI (using the HTTP Auth-header). The WebAPI in this scenario constitutes the business logic of the system and is implementation-wise; a REST-API.

Given that the token obtained is part of every call to the WebAPI, the WebAPI can remain stateless and from the Token-value itself establish which context it is being invoked (context = App A or App B or…).

As the task of validating whether a given set of credentials are valid, by design is kept away from the business logic (WebAPI), the business logic can remain indifferent as to how the User is identified. It can simply rely on the simple fact that a token is present every time it is being called. An added advantage to the separation of concerns here is that the business logic also does not care whether credentials are coming in in the form of username/password, facebook integration, Google Login or an X509-certificate. All this is the responsiblity of the Token System.

Business Logic

The business logic should be able to adapt to the mentioned deviations in the clients requirements. Maybe when the caller is App A it should return Users with first name starting with Joe, whereas when being called in the context of App B it should return Users with 5 records in the database? This is where factories and plugins are relevant. Actually normal and standard object-oriented design, but shielded behind interfaces and WebAPIs.


Most mobile applications benefit from some form of push notifications. It has by now become an expected behaviour that Apps interact with the user by notifying him of relevant and contextual important information. Sending out notifications to Android phones or IOS phones relies on 2 different systems (FireBase by Google and Apples Push Notification Services), although the message itself is JSON in both cases. To realize a simple sub-system that is capable of sending out messages to the phones, also here - this is kept to a dedicated system with these capabilities.


Now that we have an idea of the overall picture (how the architecture is layed out and who is responsible for what); we can move on to a more technical part of this post. The implementation in this case is built on the Microsoft stack - so the following technologies are used:
  • MEF (adaptation to various contextual changes)
  • WebAPI 2 (interface, REST API)
  • Entity Framework (database access)
  • Swagger IO (documentation of REST API)
  • SQL (standard RDBMS)
  • Azure (hosting)
  • C# (runtime 4.6)

MEF and logic adaptation

To appreciate and fully understand the choice and usage of MEF - you need to understand how that works. MEF is an injection based implementation from MS that allows you to build loosely coupled implementations. As seen below - the interface implementation is found in 3 different assemblies (one default implementations and two supporting potential overrides for each context). Loading of the implementation is performed by an ObjectFactory found in the interface assembly. It will look in the /bin directory for implementations supporting a given interface.
To allow the MEF system to determine which implementation it should load - it uses metadata found as decoration on the various implementations. By default - it will load the "DEFAULT" implementation, but if an implementation is found with specific support for a context (e.g. App A) - this is loaded instead and returned to the webapi.


The interface the mobile app developer is faced with is REST based. To make it as easy to consume as possible it follows the conventions used by most REST-based API nowadays. It makes heavy use of the standard HTTP-verbs (GET, POST, PATCH, DELETE) and makes the URI part of the interaction of the resources.


An attempt to invoke any method requires the Client to present a valid security token as previously mentioned. If one is not present - the system refuses to execute and terminates the request (by design). This is manifested by the WebAPI as a standard HTTP-error code = .405

As seen from the image above - the web method is decorated with metadata that suggests that this method cannot be called without presenting a AuthToken (security token).

Hosting (Azure)

This section actually could be worth an entire blogpost in its own right (and I might write one), but simply put - this is hosted in the cloud to realise the scalable nature of Azures engines.


The minute I see a word document "constituting" documentation on a live system; I become suspicious. How relevant and current is this "documentation"? Does it reflect what Im seeing when programming against this webAPI? To remove that problem, Swagger IO is used to document the API. Swagger is a superior reflective toolset that generates documentation when you press F5 (refresh) in your browser.

It will generate documentation like you see here:

Final thoughts and comments

Finally - before you go all "religious" on me - this is just one route to the goal. There are other ways. It just happens to be the approach I found to be the better one ;-)

Mobile Apps



iPhone/XCode - not all cases are equal!

This bit me! Having made some changes to an iPhone application (Obj-C); everything worked fine in the simulator. But, when deploying the s...