Mobile App Backend Services

This article provides guidance for building, connecting, testing, and monitoring mobile backend services using Google Cloud Platform. Links to code samples and sample applications follow each design pattern.

Most mobile apps and games need a backend service for things that can’t be done solely on-device, such as sharing and processing data from multiple users, or storing large files.

Selecting a design pattern

Building a backend service for a mobile app is similar to building a web-based service, with some additional requirements:

  • Limit on-device data storage
  • Synchronize data across multiple devices
  • Handle the offline case gracefully
  • Send notifications and messages
  • Minimize battery drain

The following design patterns demonstrate different ways to use Cloud Platform to create backend services that address these requirements. For more information, select a pattern to go to a detailed description of the pattern.

Firebase design pattern Firebase with App Engine design pattern Firebase with App Engine flexible environment design pattern App Engine standard environment with Endpoints design pattern Compute Engine design pattern

The first three patterns use Firebase, a two-tier architecture, in which mobile apps and Firebase both manipulate the data directly. This creates important differences in how security and data validation are handled.

In a traditional three-tier model, like the last two patterns, there is a communication layer between the mobile app and the backend service. You would typically write authentication and data-validation code in this layer.

In Firebase, you specify authentication and validation as declarative rules in the Firebase web UI, with no need to write code. For more information, see Firebase Authentication in the Firebase documentation.

In addition, these design patterns transition from a fully managed platform, Firebase, to a completely unmanaged platform, Google Compute Engine. In managed platforms, Google handles tasks such as upgrades and autoscaling for you, but imposes some limitations on configuration. In unmanaged platforms, you have full control over the configuration of your server, but must handle management tasks yourself.

The following table details the differences between these design patterns.

Feature Firebase Firebase & App Engine standard environment Firebase & App Engine flexible environment App Engine standard environment & Endpoints Compute Engine & REST/gRPC
Automatic capacity scaling Yes Yes Yes Yes If you configure an autoscaler.
Automatic real-time data synchronization Yes Yes Yes

Automatic server maintenance Yes Yes Yes Yes

Backend logic

Yes Yes Yes Yes
Call native binaries, write to the file system, or make other system calls.

Yes

Yes
Data storage Yes Yes Yes If you add other Cloud Platform services If you add other Cloud Platform services
File storage Yes
Yes
Yes
Yes
with Cloud Storage
Yes
with Cloud Storage
Easy user authentication Yes Yes Yes OAuth 2.0

Language support for backend service logic N/A Java, Python, Go, PHP Any Java, Python, Go (Cloud Endpoints for Go.) Any
Messages and notifications, such as push notifications Yes
Yes
Yes
Yes
with Cloud Messaging
Yes
with Cloud Messaging
Platform support iOS, Android, Web iOS, Android, Web iOS, Android, Web iOS, Android, Web iOS, Android, Web
Requires code to run within a sandbox.

N/A

Yes

Yes

Requires SSL

Yes

Yes

Firebase

Firebase is a fully managed platform for building iOS, Android, and web apps that provides automatic data synchronization, authentication services, messaging, file storage, analytics, and more. Starting with Firebase is an efficient way to build or prototype mobile backend services.

Firebase

Recommended for:

  • Limiting on-device data storage by storing JSON data in the Firebase Realtime Database and files in Firebase Storage.
  • Sending notifications with Firebase Cloud Messaging.
  • Automated real-time data synchronization across multiple devices.
  • Gracefully handling the offline case.
  • Authenticating users through a variety of identity providers.
  • Rapid development of a backend service.

Not recommended for:

  • Apps that need a backend service to modify the synchronized data.

Firebase getting started

How to get started using Firebase.

Firebase code samples

Sample applications that use Firebase.

Firebase and Google App Engine standard environment

App Engine standard environment is an application platform that monitors, updates, and scales the hosting environment; all you need to do is write your mobile backend service code.

If your app needs to process user data or orchestrate events, extending Firebase with App Engine standard environment gives you the benefit of automatic real-time data synchronization.

Firebase and App Engine

Recommended for:

  • Firebase apps that need a backend service to modify the synchronized data.
  • Backend services that run periodically to process or analyze Firebase data.

Not recommended for:

  • Backend services that call native binaries, write to the file system, or make other system calls.
  • Persistent connections to Firebase. App Engine standard environment reclaims socket connections after 2 minutes.

Using Firebase and App Engine standard environment in a mobile app

A tutorial on how to build a mobile app that stores a to-do list in Firebase. Firebase automatically synchronizes the data across devices. Backend logic running on App Engine standard environment sends out daily reminder emails based on the task list.

Firebase and App Engine flexible environment

Like App Engine standard environment, App Engine flexible environment is an application platform that monitors, updates, and scales the hosting environment; all you need to do is write your mobile backend service code.

The difference is that flexible environment runs your backend service inside Docker containers that you can configure. This means you can call native binaries, write to the file system, and make other system calls.

If your app needs to process user data or orchestrate events, extending Firebase with App Engine flexible environment gives you the benefit of automatic real-time data synchronization, without the need to run your code inside the App Engine sandbox.

Firebase and App Engine flexible environment

Recommended for:

  • Firebase apps that need a backend service to modify the synchronized data, and that service requires a custom server configuration or third-party libraries not supported by App Engine standard environment.
  • Backend services that require a persistent connection to Firebase to receive notifications of data changes. Flexible environment can hold a connection open for 24 hours.

Build a mobile app using Firebase and the App Engine flexible environment

This tutorial demonstrates how to write a mobile app with backend data storage, real-time synchronization, and user-event logging using Firebase. Java servlets running in the Google App Engine flexible environment listen for new user logs stored in Firebase and process them.

App Engine and Cloud Endpoints

Google Cloud Endpoints generates APIs, client libraries, and discovery documentation for an App Engine application. Using Cloud Endpoints means you don’t have to write wrappers to handle communication with App Engine. With the client libraries generated by Cloud Endpoints, you can simply make direct API calls from your mobile app.

Using Cloud Endpoints with App Engine gives you an application platform that monitors, updates, and scales the hosting environment.

App Engine and Cloud Endpoints

Recommended for:

  • Automated generation of client libraries that apps can use to call the backend service directly.
  • Reducing on-device storage by moving files to Cloud Storage.
  • Sending notifications by calling Cloud Messaging.

Not recommended for:

  • Apps that require automatic real-time data synchronization across devices.
  • Backend services that require custom server or third party libraries.
  • Systems that do not support SSL; SSL is required by Cloud Endpoints.

Hello Endpoints

A set of getting-started tutorials that show how to build the Hello Endpoints sample app that sends simple messages. The backend service is implemented on App Engine and exposed to the mobile app with Cloud Endpoints.

Tic Tac Toe

A sample application that demonstrates how to call a backend service running on App Engine to create a simple game. The Tic Tac Toe backend service is implemented in Java.

Compute Engine and REST or gRPC

Compute Engine lets you create and run virtual machines on Google infrastructure. You have administrator rights to the server and full control over its configuration. This also means that you are responsible for updates and maintenance.

Compute Engine and REST

There are two main protocols used to connect to Compute Engine instances: REST and gRPC. REST is the more established protocol. gRPC is newer and offers benefits in terms of more efficient transmissions, which can minimize battery drain and enhance security. For more information about REST and gRPC, see Connect your app to your custom backend service.

Recommended for:

  • Porting an existing backend service running on an on-premise server or a virtual machine.
  • Backend services that require a custom server or third-party libraries.

Not recommended for:

  • Apps that require automatic real-time data synchronization across devices.
  • Automatic maintenance; you must maintain and upgrade the server yourself.
  • Automatic scaling; you must manually configure and manage an autoscaler.

Using Compute Engine and REST in a mobile app

An end-to-end sample that uses REST to connect a mobile app to a backend service hosted on Compute Engine. The sample app, Stickynotes, sends text to the service, which responds by returning a generated image.

The Stickynotes sample is available in both REST and gRPC versions, so you can compare the two protocols.

iOS

Using Compute Engine and gRPC in a mobile app

An end-to-end sample that uses gRPC and protocol buffers to connect a mobile app to a backend service hosted on Compute Engine. The sample app, Stickynotes, sends text to the service, which responds by returning a generated image.

The Stickynotes sample is available in both REST and gRPC versions, so you can compare the two protocols.

iOS

Building your mobile backend service

Google provides a variety of tools and services that you can use to build backend services that integrate with Cloud Platform services.

Android Studio

Android Studio is the official IDE for Android application development, based on IntelliJ IDEA, and offers additional capabilities such as lint tools, a Gradle-based build system, and code templates.

In addition, Android Studio has built-in support for integrating Cloud Platform services and Firebase into your app. For more information, see Cloud Tools for Android Studio.

Google APIs for iOS

Google distributes several iOS-specific APIs and SDKs using CocoaPods. CocoaPods is an open-source dependency manager for Swift and Objective-C Cocoa projects. CocoaPods makes it easy to install or update new SDKs when working with Xcode.

Cloud SDK

The Google Cloud SDK contains tools and libraries you can use to create and manage resources on Cloud Platform.

Cloud Source Repositories

Cloud Source Repositories are fully-featured Git repositories hosted on Cloud Platform.

Each project you create in the Google Cloud Platform Console has an associated Cloud Source Repository. You can use this repository for collaborative development of any application or service, including those that run on App Engine and Compute Engine.

If you are using Google Stackdriver Debugger, you can use Cloud Source Repositories and related tools in the Cloud Platform Console to view debugging information alongside your code during application runtime.

Stackdriver Debugger

You can use Stackdriver Debugger to inspect the state of a Java application, at any code location, without stopping or slowing it down. You can use Stackdriver Debugger on both production and staging instances of your application.

You can use Stackdriver Debugger with:

Connecting your app to your mobile backend service

After you’ve built your backend service you need to establish communication to and from instances of your mobile app.

Connecting your app to Firebase

If your backend service uses Firebase, the process to connect your mobile app to Firebase is the following:

  • Create a Firebase account.
  • Get an application URL from Firebase.
  • Import the client libraries into your app. These are available for iOS, Android, web applications, and REST.
  • Call the libraries from your app, referencing the application URL.

For walk throughs of how to do this, see the Getting Started Guides in the Firebase documentation.

Connecting your app to your custom backend service

There are several protocols you can use to call a backend service from your mobile app. The protocols most commonly used with Cloud Platform are REST, Cloud Endpoints, and gRPC.

REST

REST is an architecture for networked applications that uses HTTP requests to post, read, and delete data. You can build REST APIs on Compute Engine, App Engine standard environment, and App Engine flexible environment instances that your app can call to access the backend service you build.

The most common tools for building RESTful services on Cloud Platform are:

For sample code that demonstrates how to use REST in a backend service, see Compute Engine and REST or gRPC.

You can also use REST to communicate with Firebase. For more information see, Firebase Database REST API in the Firebase documentation.

Cloud Endpoints

Cloud Endpoints generate APIs and client libraries for an App Engine application. Using Cloud Endpoints means you don’t have to write wrappers to handle communication with App Engine. With the client libraries generated by Cloud Endpoints, you can simply make direct API calls from your mobile app.

Cloud Endpoints requires SSL and only works with an application running on App Engine.

For sample code that demonstrates how to use Cloud Endpoints in a backend service, see App Engine and Cloud Endpoints.

gRPC

gRPC is a framework that makes it possible for a mobile app to directly call methods on a backend service as if it was a local object.

It uses the HTTP/2 standard, which introduces bidirectional streaming, flow control, header compression, and the ability to multiplex requests over a single TCP connection. You can use gRPC to make your mobile app more bandwidth-efficient and to reduce latency between your app and backend service running on Cloud Platform.

gRPC clients and servers can be written in any of gRPC's supported languages. You could, for example, create a gRPC server in Java with clients in Go, Python, or Ruby.

For sample code that demonstrates how use gRPC in a backend service, see Compute Engine and REST or gRPC.

Sending notifications to your app

Notifications are an important feature of most mobile apps. You can use them to communicate with users, regardless of whether your app is open on their device.

Firebase Cloud Messaging

Firebase Cloud Messaging (FCM) is a cross-platform messaging solution you can use to reliably deliver messages and notifications to client devices running your app.

With FCM you can:

  • Distribute messages to your client app in any of three ways — to single devices, to groups of devices, or to devices subscribed to topics.
  • Deliver notifications up to 2KB, data payloads up to 4KB, and send messages with both notification and data payload.
  • Send acknowledgments, chats, and other messages from devices back to your server over FCM’s reliable and battery-efficient connection channel.

To get started using Cloud Messaging to send notifications, see:

Firebase Notifications

Built on Firebase Cloud Messaging and the FCM SDK, Firebase Notifications provides a graphical console that you can use to send messages to client devices running your app.

Testing your mobile backend service

One of the challenges of creating a mobile app is testing it on all possible device configurations. Cloud Platform provides tools to test your mobile app on both physical and virtual devices, as well as tools to test the security and performance of your backend service.

Cloud Test Lab

Google Cloud Test Lab provides cloud-based infrastructure for testing Android apps. With one operation, you can initiate testing of your app across a wide variety of devices and configurations. Test results — including logs, videos, and screenshots — are made available in your project in the Cloud Platform Console. Even if you haven't written any test code for your app, Cloud Test Lab can analyze your app automatically, looking for crashes.

Cloud Test Lab supports two types of devices. Each type has characteristics making it more appropriate for a particular phase of app development. A variety of models are available for each device type.

  • Virtual devices are high-fidelity virtual simulations of specific Android devices. These devices have the highest availability for scheduling and are most appropriate for day-to-day development or continuous testing.

  • Physical devices are actual, physical Android devices, installed and running in a Google data center. Tests on physical devices are most appropriate for pre-release testing, as they can help you to detect issues that might not occur when testing your app with virtual devices.

Google Cloud Security Scanner

Cloud Security Scanner identifies security vulnerabilities in your App Engine web applications. It crawls your application, following all links within the scope of your starting URLs, and attempts to exercise as many user inputs and event handlers as possible.

Cloud Security Scanner currently supports regular App Engine instances only. It is not yet enabled for App Engine flexible environment, Compute Engine, or other Cloud Platform resources.

Stackdriver Trace

Stackdriver Trace is a feature of Cloud Platform that collects latency data from App Engine applications and displays the data in near real time in the Cloud Platform Console.

With Stackdriver Trace, you can find out how long it takes your application to handle incoming requests from users or other applications, and how long it takes to complete operations — specifically RPC calls — performed when handling the requests.

Currently, Stackdriver Trace collects end-to-end latency data for requests to App Engine URIs and additional data for round-trip RPC calls to App Engine services like Google Cloud Datastore, URL Fetch, and Memcache.

Monitoring your mobile backend service

Launching a backend service is just the beginning; you need to monitor the service to ensure that it’s functioning as intended.

Health monitoring is done for you automatically by App Engine for the standard environment and flexible environment, both of which spin up new instances when necessary. You can also configure autoscaling for Compute Engine to replace non-responsive instances.

Cloud Platform also provides tools to collect and analyze logs and a monitoring dashboard that you can configure to send alerts when your application is performing outside of specified boundaries.

Stackdriver Logging

Stackdriver Logging collects and stores logs from applications and services on Cloud Platform. The Logs List shows the logs you can access. After you’ve collected logs, you can:

Stackdriver Monitoring

Stackdriver Monitoring provides dashboards and alerts for your cloud-powered applications.

You configure Stackdriver Monitoring using the Stackdriver Monitoring Console. Use the Stackdriver Monitoring API to retrieve monitoring data and create custom metrics.

With Stackdriver Monitoring, you can review performance metrics for Cloud Platform services, virtual machines, and common open source servers such as MongoDB, Apache, Nginx, Elasticsearch, and more.

Send feedback about...