BFF Layer for Lead Generation Apps

A Backend-for-Frontend service that aggregates, transforms, and delivers data specifically shaped for lead generation single-page applications.

Node.jsTypeScriptExpressGraphQLRedisGCP Cloud RunREST APIs
Duration
8 months
Team
4 engineers
Role
Senior Frontend Engineer

Overview

This BFF (Backend-for-Frontend) service sits between lead generation SPAs and a fragmented set of internal APIs. It consolidates multiple backend calls into single, purpose-built endpoints optimized for the frontend's data requirements, reducing client-side complexity and over-fetching.

Problem

Lead generation SPAs were making 4–6 independent API calls per page load to different internal services: campaign configuration, form schema definitions, geo-based routing rules, and consent management. Each call had different authentication requirements and response formats. Frontend code contained significant data transformation logic, making it brittle and hard to evolve.

Solution

We introduced a BFF layer that exposes a small, SPAs-oriented API surface. Each endpoint aggregates the necessary upstream calls, normalizes the response shape, and applies caching where appropriate. The frontend only calls the BFF — it no longer needs to know about the internal service topology.

Your Role

I designed and built the initial BFF service, defined the endpoint contracts with frontend teams, and established the caching strategy for campaign and schema data. I also set up the CI/CD pipeline on GCP Cloud Run and wrote the OpenAPI spec used to generate TypeScript client types on the frontend side.

Architecture

  • BFF Service (Node.js / Express): Thin aggregation layer, no business logic
  • Upstream adapters: Individual modules per internal service with retry and timeout handling
  • Response normalization: Shared transform functions enforce a consistent shape across endpoints
  • Redis cache: Campaign config and form schemas cached with TTLs aligned to CMS publish cycles
  • GCP Cloud Run: Containerized, scales to zero between low-traffic windows
  • OpenAPI spec: Auto-generates TypeScript types consumed by frontend build tooling

Impact

Page load API calls dropped from an average of 5 to 1 per SPA. Campaign onboarding time decreased as frontend teams stopped implementing custom data transformation logic for each new market. The caching layer absorbed the majority of repeated schema lookups during high-traffic campaign launches, reducing upstream API load noticeably during peak windows.