A common question I am asked as a consultant when working with clients on creating mobile apps is, “How do I connect to the database?” There is a general amount of confusion around how developers are supposed to get the data that is in their relational database (think SQL, Oracle, MySQL, etc) to the screen of their mobile devices. In simple, the answer is to create a service that wraps around that relational data and exposes it externally of your organizations network. Simple answer, but there is a lot involved here that all organizations may not have the experience / expertise or the money to build the infrastructure to support. So… you may be asking yourself, “What are some other options?” Well, there are quite a few options we can choose from.
Azure
Azure is Microsoft’s cloud computing platform and provides two options for securely exposing your relational database to mobile devices: Azure Mobile Services and Azure Service Bus Relay.
For more information Azure, see below:
Mobile Services
Mobile Services is a cloud-based backend service that can expose a SQL Azure or on-premise database to your mobile apps. Out of the box it’s much simpler to utilize SQL Azure to host your remote database, but this isn’t always an option when we want to work with databases that are on-premise. Luckily for us Azure provides a mechanism to create a mobile service that connects back to an on-premise database using what’s known as a Hybrid Connection.
A requirement to create a Hybrid Connection is to install the Hybrid Connection Manager on the machine you wish to connect to Azure. The Hybrid Connection Manager enables your on-premises machine to connect to Azure and relay TCP traffic. After the bits are installed you must modify some mobile service configuration and then utilize the Mobile Services Client to access your on-premise database on multiple platforms including Windows, iOS, Android, HTML/JavaScript, Xamarin, and PhoneGap.
For more information azure mobile services, see below:
For more technical information on setting up an on-premise mobile service, see below:
Service Bus Relay
Microsoft does a great job of explaining what Service Bus Relay is:
The Service Bus Relay service enables you to build hybrid applications that run in both an Azure datacenter and your own on-premises enterprise environment. The Service Bus relay facilitates this by enabling you to securely expose Windows Communication Foundation (WCF) services that reside within a corporate enterprise network to the public cloud, without having to open up a firewall connection or requiring intrusive changes to a corporate network infrastructure.
From the definition above 2 things are clear:
- This is really stinking easy to expose an existing service to be consumed by a mobile app
- You must use WCF or have an existing service layer built with WCF
All that is required to setup a Service Bus Relay is some Azure setup, usage of the Service Bus nuget package and a configuration change on your newly created WCF service or existing WCF service. That’s it, and you can use your WCF service externally of your organization within any platform that supports requests over HTTP.
For technical details on setting up a Service Bus Relay, see below:
Telerik Platform
Telerik Platform is Cross-Platform Mobile Development for iOS, Android and Windows Phone using web technologies (HTML, JavaScript, CSS). It also provides an option to securely expose your relational database with Telerik Backend Services.
Telerik Backend Services
Telerik Backend Services provide a “complete mobile app backend as a service for easy and scalable app development.” Within these backend services exists an application called Data Link Server which provides a generic web service that can be used to expose relational data externally. The beauty of the Data Link Server is the simplicity of installation and setup compared to the amount of functionality that it provides. Though there are some requirements for using this application:
- A windows based web server
- Ability to expose service externally of your environment
The Data Link Server essentially writes all the code necessary for you to access your database and its tables. After the installation of the server is completed you will need to pull down tables as Content Types into the Telerik Backend Services interface. This will then allow you to easily access your data via Telerik’s Backend Services SDK that is available in JavaScript, .NET, iOS, Android, and via a RESTful API.
For more information on Telerik Backend Services, see below:
For technical details on Telerik Backend Services, see below:
Which path do I choose?
Well, it depends.
Azure Mobile Services will require some modifications to your on-premise server and firewall changes to allow for traffic to pass between the on-premise server and Azure.
Service Bus Relay requires that you build your own WCF service or utilize an existing one, but other than that configuration is really easy.
Telerik Backend Services requires you to deploy an additional web application to a web server and potential firewall changes to allow for HTTP traffic over the port they suggest.
- If you have an existing WCF service – Service Bus Relay will seem like a no brainer.
- If you have a web server that is already hosting externally facing applications Telerik Backend Services may be a good fit.
- If you just have a database server and no way to host externally facing applications Azure Mobile Services may be a good fit.
At the end of the day, it depends on your organizations situation and expertise. Please feel free to comment on any experience you may have on any of the above options or other options that have worked well for you.
Great post, Justin!
Great Post!! I was searching day and night on this topic and finally you cleared my doubt in one post. Thanks bro 😉
Just a small doubt, If my company already has a web server hosting external apps, Do we really need a backend service then. Can’t I just write an api to make the relational data available to mobile apps? sorry if its silly question.
Thanks for the reply – not a silly question at all. If you already have externally-available services, you don’t really need a backend service – but it’s an option. Any way you look at it, you’re going to build some sort of service to give others a mechanism for accessing your data. The abstraction makes it simpler for your to control access and the types of queries others perform.
Some of this conversation relies on the security footprint you’re willing to have online. With every new hole you open through your firewall, you’re increasing the available attack surface. Writing a simple api to expose your relational data publicly can be relatively quick, but whether you want to manage and maintain that open hole in your firewall is between you, your network security administrator, and the business.
Service Bus Relay provides you a a quick way of getting your data accessible publicly without opening the incoming firewall ports. When you stand up your WCF services, you configure IIS to auto-start the App Pool, which establishes an outgoing and secure tunnel to Azure. Azure advertises your public endpoint and brokers the connection back to your data center. It’s certainly slower, but very little configuration.
I’ve used the Service Bus Relay approach before when my client has a limited budget, yet they want to get some data into a mobile app we’ve built. Another situation where I’ve used the Service Bus Relay is when IT security refused to open inbound ports to a web service, but were comfortable with having Azure broker that connection.
Another consideration to make is the volume of your traffic against your service. If you already have a website, but are expecting a significant amount of traffic through your api service, this may negatively affect the performance of your website.