How Serverless Is Redefining Frontend Development: From BFF to JAMS

From BFF to SFF

BFF (Backend For Frontend) is a logical layer that tailors APIs for front‑end consumption; in the Node.js world it is used for API proxy, rendering, and SSR. Migrating BFF to Serverless For Frontend (SFF) moves the same responsibilities onto Function‑as‑a‑Service (FaaS) and BaaS, eliminating operational overhead while keeping the same functional capabilities.

JAMstack and JAMS

JAMstack stands for JavaScript, API, and Markup. It requires JavaScript to run all dynamic code on the client, APIs to abstract server‑side processes, and pre‑built markup generated at build time. The architecture delivers better performance, security, lower cost, and an improved developer experience.

Extending JAMstack with Serverless hosting creates JAMS (JavaScript‑API‑Markup‑Serverless). JAMS retains the three JAM principles while deploying both APIs and pages as serverless functions, enabling seamless scaling and zero‑ops hosting.

Redwood.js and FABs

Redwood.js is a full‑stack, serverless web framework that simplifies building JAMstack applications. It provides a unified project structure and integrates with serverless providers.

FAB (Frontend Application Bundle) is a zip format that packages a server‑side JavaScript entry point together with static assets. Deploying a FAB to a serverless platform delivers both CSR and SSR capabilities without managing servers.

const getProdSettings = () => {
  return {
    // All production settings are bundled into the FAB here,
    // ensuring predictable behaviour regardless of host.
    // These are returned as a separate entry point, however,
    // so that any encrypted variables can be decrypted
    // by the host before being passed through to the render.
  }
}

const render = async (request, settings) => {
  // request: a fetch.Request object
  // settings: your production settings plus any
  //           environment-specific overrides
  const { body, statusCode, headers } = await myApp.render(request, settings)
  // return a fetch.Response object with the full data.
  // Streaming responses not yet supported, but will be in future.
  return new Response(body, { statusCode, headers })
}

module.exports = { render, getProdSettings }

Serverless‑Side Rendering

Traditional SSR runs on dedicated servers; serverless‑side rendering moves the rendering logic into FaaS, combining the benefits of CDN‑cached static assets with on‑demand server‑rendered pages. The concept of Caaf (Component as a Function) abstracts components into functions, enabling uniform handling of CSR, SSR, and API calls.

Practical Scenarios

Deploying Next.js applications to Cloudflare Workers.

Adding redirect rules to CRA projects without ejecting.

Generating logged‑in and logged‑out pages with Gatsby and switching via cookies.

Protecting applications from unauthorized actions.

Publishing each commit to a unique URL for collaborative review.

Future Directions and Tooling

Combining serverless infrastructure with developer portals (e.g., Backstage) and micro‑frontend frameworks (e.g., qiankun) creates a “frontend workbench” that abstracts away the underlying functions, offering templates for API, SSR, mock services, and more. Stability, extensibility, and seamless CSR/SSR switching are key goals for the next generation of front‑end development.