Exploring BFF Development with OpenFaaS: Practices, Architecture, and Code Samples

With the rapid development of cloud computing, service models for business systems continuously evolve. The article describes a team's journey of exploring the Backend‑for‑Frontend (BFF) development pattern and sharing practical experience of building a private function service using OpenFaaS, along with the underlying principles.

Background : Initially, the front‑end team took over Java Web applications for API aggregation and template rendering, while back‑end teams focused on business logic and provided RPC services. Deployment relied on CentOS virtual machines, leading to high manual operational costs.

Microservice Transition : As the business grew, the back‑end migrated to a microservice architecture, and the Java BFF became a large monolith with hundreds of APIs, prompting the need for a more flexible development model.

Cloud‑Native Shift : The team evaluated Serverless frameworks (OpenFaaS, KNative, OpenWhisk) and chose OpenFaaS, deploying it on an internal Kubernetes cluster. They built function services for tool utilities, mini‑program APIs, and other peripheral services.

OpenFaaS Setup : The core prerequisites are a Kubernetes cluster and a private Docker registry. Using Helm, the installation steps are similar to npm install . After installation, the main OpenFaaS components (gateway, NATS, Prometheus, etc.) run as containers.

Function Service Practice :

Python example (pinyin conversion):

1 # handler.py
2 
3 import pinyin
4 
5 def handle(req):
6     return pinyin.get(str(req), format="strip", delimiter=" ")

Bash/YAML example for defining functions (mobile.yml):

1 # file: mobile.yml
2 
3 version: 1.0
4 provider:
5   name: openfaas
6   gateway: https://openfaas.demo.domain
7 functions:
8   m-search:
9     lang: node12
10    handler: ./functions/search
11    image: docker.demo.domain/mobile-search:latest
12    secrets:
13      - docker-auth
14   m-notice:
15     lang: node14
16     handler: ./functions/notice
17     image: docker.demo.domain/mobile-notice:latest
18     secrets:
19       - docker-auth

JavaScript example for a simple handler:

1 const axios = require('axios');
2 
3 // Get API URL from environment variable
4 const API_URL = process.env.API_URL;
5 
6 module.exports = async (event, context) => {
7   const { q } = event.query;
8   const response = await axios.get(API_URL, {/* options */});
9   // process response
10   return context.status(200).succeed(data);
11 };

Dockerfile for a Node.js function with OpenFaaS watchdog:

1 FROM ghcr.io/openfaas/of-watchdog:0.8.4 as watchdog
2 FROM node:12-alpine as ship
3 
4 COPY --from=watchdog /fwatchdog /usr/bin/fwatchdog
5 RUN chmod +x /usr/bin/fwatchdog
6 
7 COPY function/ ./
8 RUN npm i
9 WORKDIR /home/app/
10 ENV fprocess="node index.js"
11 ENV mode="http"
12 ENV upstream_url="http://127.0.0.1:3000"
13 CMD ["fwatchdog"]

Underlying Architecture : OpenFaaS runs on Kubernetes and Docker, exposing services via a Gateway, using NATS for asynchronous function execution, Prometheus/AlertManager for metrics and auto‑scaling, and a watchdog process that proxies requests to the user function. The auto‑scaling flow involves AlertManager triggering scaling, the gateway requesting container creation, Kubernetes scheduling, image pulling, and container start‑up.

Watchdog and Runtime : Each function container includes a watchdog that forwards HTTP requests to the function process. For richer request context, an Express‑based runtime can be used, with a custom Dockerfile that sets mode="http" and defines the function entry point.

Conclusion : The article recaps the BFF evolution, OpenFaaS adoption, and core principles, emphasizing that while serverless improves development efficiency, business complexity remains, and future work should focus on abstracting flexible BaaS services that can be composed without worrying about underlying infrastructure.