Mobile app backend services

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. To learn more about backend services
specific to games, see
Overview of cloud game infrastructure.

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
Google Cloud to create backend services that address these requirements.
For more information, select a pattern to go to a detailed description
of the 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
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 imperative 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, 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.

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 and App Engine flexible environment

Like App Engine standard environment,
App Engine flexible environment is an app
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.

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 App Engine flexible environment listen for new user logs
stored in Firebase and process them.

App Engine and Endpoints

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

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

Recommended for:

Automated generation of client libraries that apps can use to call the
backend service directly.

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 Endpoints.

Tic Tac Toe

Compute Engine and REST or gRPC

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

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-premises server or a
virtual machine.

Backend services that require a custom server or third-party libraries.

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.

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.

Regardless of the design pattern you choose, you should also check the
architecture guides of the mobile platform of your app. For example, check
Guide to app architecture in the Android developer documentation.

Building your mobile backend service

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

Android Studio

Android Studio
is the official IDE for Android app 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
Google Cloud services and Firebase into your app. For more information,
see
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 that you can use to install or update new SDKs when working
with Xcode.

Cloud SDK

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

Cloud Source Repositories

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

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

Cloud Debugger

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

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 commonly used with Google Cloud are REST,
Endpoints, and gRPC.

REST

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

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

Endpoints Frameworks

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

Endpoints Frameworks requires SSL and only works with an app running on
App Engine.

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.

gRPC 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 Google Cloud.

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

Note: To send a notification to an iOS app, you must go through the
Apple push notification service.
This requires that you create an APNs certificate with Apple and use it to sign
your notifications.

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
that are 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. Google Cloud 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.

You can also configure your mobile app to work with a test backend service to
isolate your production environment from any side effects caused by the tests.
For more information, see
Supporting different environments
in the Firebase documentation.

Firebase Test Lab

Firebase Test Lab
provides cloud-based infrastructure for testing Android and iOS 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 Console. Even if you
haven't written any test code for your app, Firebase Test Lab can analyze your app
automatically, looking for crashes.

You can use Firebase Test Lab to test your app on virtual devices or physical
devices. A variety of models are available for each device type.

Virtual devices are high-fidelity virtual simulations of specific
mobile 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 mobile devices, installed and
running in a Google data center. Tests on physical devices are most
appropriate for pre-release testing, because they can help you to detect
issues that might not occur when testing your app with virtual devices.

Web Security Scanner

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

Cloud Trace

Cloud Trace
collects latency data from App Engine apps and displays the
data in near real time in the Cloud Console.

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

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.

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

Cloud Logging

Cloud Logging
collects and stores logs from apps and services on Google Cloud.
Available logs
shows the logs you can access. After you’ve collected logs, you can: