Swell Apps may implement a frontend to serve different purposes, depending on the goal of the app. A frontend is essentially its own application within a Swell App, intended to render pages for public display. For example, a storefront app implements the page structure and functionality of a storefront using a frontend. Different technologies can be used to build a frontend, such as Next.js, Astro, and other frameworks supported by Cloudflare Pages.

  • Storefront apps: Customer interfaces such as product pages, checkout, account portals, and more.
  • Admin apps: Merchant user interfaces that are embedded in the Swell dashboard.
  • Integrations: Configuration or other interstitial interfaces to support unique workflows, serving either merchants or customers.

Proxima app serves as an example for developers to learn best-practices for developing storefront frontends, but the sky is the limit. With a wide range of framework choices, and the power of Cloudflare Pages, any number of storefront use cases can be achieved on the Swell platform.

A frontend can be configured as an embedded UI within Swell's dashboard, to provide a more flexible interface for merchants to manage data and settings for your app.

Embedded frontend UIs in the admin dashboard is still a work in progress. Stay tuned for updates and further documentation.

You can create a frontend by initializing an app using the JavaScript framework of your choice in the app's frontend/ folder, or by using the following CLI command:

Create frontend
swell create frontend

At this time, the following frontend app frameworks are supported:

We will expand this list as demand for additional support grows. If your framework of choice is not yet supported, reach out to us or make a pull-request on Github.

To simplify your frontend's interactions with the Swell platform, we've developed the Apps SDK, a Typescript-based library that comes built-in with frontend and backend API clients, and theme rendering logic for storefront apps.

-> See the Apps SDK reference for more details.

During local development, you'll be able to run the app on your machine and quickly preview changes using the following CLI command:

Frontend dev
swell app frontend dev

This will perform several functions:

  • Start a local proxy using ngrok.
  • Start the app using its own dev command, for example next dev or astro dev.
  • Add the local proxy URL to your account session, which informs Swell that your app dev server is running and should be loaded instead of a deployed version.

You should only run app frontend dev on one app at a time, otherwise your account session will only remember the last app that was started.

When the command is successfully executed, it will provide a URL to preview the app through the ngrok proxy. It will also watch for changes and automatically push configurations and app files to Swell as you develop the app.

When you're ready to test your frontend in the cloud, or ready to make a final deployment before release, you will deploy it using the CLI. At the time of this writing, the frontend app will be deployed to your own Cloudflare account, which you can obtain for free. In a future release, Swell may be able to handle worker deployments for you.

To configure Cloudflare, first make sure your are logged in using wrangler:

Wrangler login
wrangler login

Once logged in, Swell CLI will orchestrate deployment using wrangler, with the following command:

Frontend deploy
swell app frontend deploy

Frontend deployment will also occur automatically when using swell app push.

When your app is invoked, either as a storefront or as an admin app, Swell will proxy the request along with headers that can be used by the app to identify the merchant and authenticate with the store's frontend and backend APIs.

The following table outlines the headers passed to a frontend app when requested:

HeaderDescription
Swell-Store-IdID of the store.
Swell-Environment-IdString 'test' indicates the request is from a test environment, while blank indicates a live environment.
Swell-App-IdID of the app.
Swell-App-VersionVersion of the app, i.e. "1.0.0".
Swell-App-RouteBase portion of the target URL, if applicable. Typically indicates the app is loaded through the Swell dashboard.
Swell-Access-TokenUnique backend API key representing scoped access for the app installed in a merchant's store.
Swell-Public-KeyUnique frontend API key representing scoped access for the app installed in a merchant's store.
Swell-API-HostURL of the store's backend API.
Swell-Admin-UrlURL of the store's admin dashboard.

Storefront-specific headers:

HeaderDescription
Swell-Storefront-IdID of a storefront using this app, if applicable.
Swell-Deployment-ModeIndicates the storefront context for the request. One of `editor`, `preview`, or `live`.
Swell-Cache-ModifiedDate the storefront was last modified or published, relative to this request.

Theme-specific headers:

HeaderDescription
Swell-Theme-IdID of a theme that should be loaded by this app.
Swell-Theme-VersionVersion of the theme, i.e. "1.0.0".
Swell-Theme-Version-HashUnique hash of all theme files combined, often used to cache response output in association with other properties.
Swell-Theme-Config-VersionInteger representing the incremental change of configurations in the requested theme.

These headers are unique for each store and its app installation. Once invoked, your frontend will likely connect to the the Swell Frontend API, Backend API, or both, using the access token (backend) and public key (frontend) provided via headers.

Using the Apps SDK:

Apps SDK
import { Swell } from '@swell/apps-sdk';

const swell = new Swell({
  serverHeaders: context.request.headers, // Object received from worker environment
  ...options,
});

// Make a backend API call
await swell.backend.get('/products');

// Make a frontend API call
await swell.storefront.get('/products');

Using Swell libraries:

Swell libraries
import Swell from 'swell-node';
import SwellJS from 'swell-js';

const storeId = context.request.headers['Swell-Store-Id'];
const accessToken = context.request.headers['Swell-Access-Token'];
const publicKey = context.request.headers['Swell-Public-Key'];

// Initialize backend API client
const backend = Swell.init(storeId, accessToken, [...options]);

// Initialize frontend API client
const storefront = SwellJS.create(storeId, publicKey, [...options]);

You may otherwise prefer to build your own request handlers using the Fetch API, following our backend and frontend API guides for details.

Because frontends are hosted by Cloudflare Workers, your app has access to standard worker context properties and runtimes.

Here are some useful docs to better understand the worker environment:

Cloudflare KV is recommended for caching output to optimize app performance.

Things to consider:

  • The Cloudflare Worker environment supports a limited subset of the Node.js runtime. Some npm packages may rely on APIs that are unavailable in this context.
  • Some npm libraries may work on your local machine, however due to the difference in local vs Worker Node.js environments, it's important to test cloud deployments regularly.
  • When deploying a storefront app on your own Cloudflare account, it is your responsibility to maintain the account in order for the app to remain accessible to users.