🎉 Welcome to the Mobify DevCenter, our new home for v2.0 documentation and developer resources! (For now, the site is desktop-only.) Switch to old site
close
Mobify DevCenter
DocumentationAPI & SDK ReferenceHow-To Guides
search_icon_focus

Deployment Infrastructure

Mobify provides bundles and targets to facilitate modern web app deployment best practices. These tools support a build, release, run methodology:

  • Bundles are your application’s code at a specific point in time. They are immutable– once a bundle has been created, it cannot be changed. Your project can have multiple bundles, but only 1 live bundle per target at a time.

  • Targets are the environments, consisting of cloud infrastructure, that run your application. Your project can have multiple targets, such as staging, production, or even something short-lived to test a feature, like feature-branch-123.

  • During deployment, your bundle code begins to run on a specific target, such as production.

What’s in a target?

Targets have the following parts: the Request Processor, CDN, Application Cache, App Server, and Proxies. Each of these plays a special role in server-side rendering:

Mobify Targets

The flow of server-side rendering for a Mobify application. Once rendered, client-side requests are made directly to the proxies.

App Server

The App Server renders your Progressive Web App (PWA) server-side. Under the hood, it’s an Express.js web server. Located within packages/pwa/ssr.js, the App Server gets updated when you deploy a bundle to a target.

For a deeper dive, continue reading our App Server Overview.

Proxies

Proxies allow the App Server and browsers to fetch data from your backends in a simple, performant and observable way. Mobify’s proxies route requests for APIs through Mobify’s CDN, which acts as an HTTP proxy server.

When you deploy, you can alter or change your proxies.

To learn more about Mobify’s proxies, check out our How-To Guide on using proxies.

CDN

The CDN works to improve the speed of the App Server’s responses. It speeds things up using two techniques:

  1. Caching your content. The CDN stores responses from the App Server, then uses them to fulfill subsequent requests.
  2. Improving the physical proximity between requests and responses. The CDN caches pages in multiple regions around the world, enabling the pages to be stored closer to your application’s users.

The CDN is configurable using Mobify’s Request Processor.

To learn more, find our guide on using the CDN Cache.

Request Processor

The Request Processor is a serverless function that’s executed by the CDN. It changes how the CDN checks for objects in its cache, and it modifies how requests are routed from the CDN to the App Server. It’s designed to improve the CDN’s cache hit ratio. (The cache hit ratio is the percentage of requests that are fulfilled by the cache, rather than by the App Server.)

The scaffold contains an example request processor at packages/pwa/app/request-processor.js. It exports a function processRequest:

export const processRequest = ({path, querystring /* setRequestClass */}) => {
return {path, querystring}
}

Implementing a request processor means modifying the processRequest function, returning an object with the path and querystring that should be passed to your app. Optionally, you may also mark requests for special handling using the setRequestClass function.

To learn more about using the request processor, check out our How-To Guides covering A/B testing with the request processor, and using the request processor to filter query strings.

Application Cache (App Cache)

The App Server uses the App Cache to store and fetch the result of slow operations.

Like the CDN, it also works to improve the App Server’s response speed by storing rendered pages. It’s designed as a backup caching system for the CDN: if there’s a cache miss on the closest regional CDN cache, then the App Server checks to see if the request is available from the App Cache. The App Cache functions as an origin shield for the App Server, shielding any unnecessary requests. It stores requests from the App Server and propagates some of them back, when needed.

For more information, read our guide on using the App Cache.