The Backend API is deprecated as of March 13, 2014. Although Google will
continue to support the Backend API in accordance with our
terms of service
, it is strongly recommended that all new applications
use the
Modules API
instead.
For information on converting existing apps using the Backend API to the
Modules API, see
Converting Apps to
Modules
You can add backends to your application in a configuration file called
backends.xml
, which declares the name and desired properties of each backend server. The
backends.xml
file is stored in the application's
WEB-INF
directory.
- About backends.xml
- Uploading Backends
- Types of Backends
- Request Handling
- Defining Handlers
- Instance Classes
- Backends Definitions
About backends.xml
Backends have several unique and important differences from default App Engine instances; for more information about how backends work, see the
Backends documentation
. The following code sample shows a sample
backends.xml
file. This configuration file defines three separate backends:
-
A backend named
memdb
. This backend has five instances of the instance class B8. -
A backend named
worker
using the default class with one instance, and configured with failfast to disable pending queue behavior. -
A backend named
cmdline
, used to execute long-running commands issued by admins of the application.
<backends>
<backend name="memdb">
<class>B8</class>
<instances>5</instances>
</backend>
<backend name="worker">
<options>
<fail-fast>true</fail-fast>
</options>
</backend>
<backend name="cmdline">
<options>
<dynamic>true</dynamic>
</options>
</backend>
</backends>
Uploading Backends
You use the same tool (
appcfg
) to upload your backend that you use to upload your application:
appcfg backends <dir> update backend_name
Types of Backends
App Engine supports two backend types: resident and dynamic. Resident backends are the default type of backend; they use resident instances, which remain in memory, even when idle, and are restarted automatically. This allows you to perform larger tasks or tasks requiring continuous processing. By default, a backend is configured with one instance, but you can add more in the configuration file.
The following table compares the major features of resident and dynamic backends:
Resident Backends | Dynamic Backends | Other Notes | |
---|---|---|---|
Instance type |
Resident |
Dynamic |
Both resident and dynamic backends have one instance by default. You can configure the number of instances using the optional instances element. |
Startup |
Manual, via the Admin Console or command-line tool |
Upon receipt of an HTTP request |
|
Shutdown |
Usually manual, via the Admin Console or command-line tool |
After sitting idle for a few minutes. |
Other factors can affect shutdown. See Shutdown for more information. |
State |
Preserved until manually shut down, or until an unexpected shutdown event takes place. See Shutdown for more details on shutdown events. |
Erased when the backend is shutdown after sitting idle for a few minutes. |
|
Type of Processing |
Continuous or driven by requests |
Driven by requests |
|
Cost |
Relatively more, because resident backends run continuously. |
Relatively less, because dynamic backends terminate when idle. |
Billed by the hour , even if idle |
Uses |
Any work that requires continuous processing or preserved state, such as:
|