GO — Healthy across the board

• Last commit 1w ago
• 14 active contributors
• Distributed ownership (top contributor 27% of recent commits)
• Apache-2.0 licensed
• CI configured
• Tests present

_{Computed from maintenance signals — commit recency, contributor breadth, bus factor, license, CI, tests}

BFE (Beyond Front End) is a production-grade Layer 7 load balancer written in Go that performs content-based routing, load balancing, and traffic management. It routes HTTP/HTTPS requests to backend servers based on request properties, handles health checking, and supports both single-cluster (SLB) and global server load balancing (GSLB) across multiple geographic clusters. Monolithic Go application (bfe.go as entry point) with modular subsystems: bfe_balance/ contains the load balancing engine split into bal_slb/ (single-cluster round-robin), bal_gslb/ (geographic load balancing with state management), and backend/ (health checks and backend management). Configuration is file-driven via testdata directories with .data files.

Infrastructure engineers and platform teams deploying cloud-native load balancing at scale—particularly those at organizations like Baidu running Kubernetes clusters or edge computing environments who need advanced traffic steering beyond basic round-robin.

Production-ready and actively maintained as a CNCF sandbox project. The codebase shows comprehensive test coverage (bal_gslb_test.go, backend_test.go, health_check_test.go), CI/CD via GitHub Actions (.github/workflows/ci.yml), and release automation (.goreleaser.yml). Last activity and structured governance (GOVERNANCE.md, MAINTAINERS.md) indicate active stewardship.

Low-to-moderate risk for production use: the project is well-established with formal governance, but verify compatibility with your Go version before upgrading (the codebase is ~3MB of Go). No obvious single-maintainer bottleneck evident from MAINTAINERS.md. Watch for breaking changes in the configuration format—the bfe_balance/testdata/ structure suggests config evolution (cluster_table.data, gslb.data).

Active development on load balancing logic and health checking (health_check.go files have test coverage). The project maintains a CHANGELOG.md and VERSION file suggesting regular releases. No specific PR/milestone data visible in file list, but governance documents indicate structured decision-making.

git clone https://github.com/bfenetworks/bfe.git
cd bfe
make

This builds the binary via the Makefile. For Docker: make docker (see README quick start section).

Daily commands:

make
./bfe  # runs the load balancer

Configuration requires cluster_table.data and gslb.data files (see bfe_balance/testdata/bal_table/case1/). For containerized: docker build -t bfe:latest . then docker run -p 8080:8080 bfe:latest.

• bfe.go — Main entry point for the BFE load balancer; defines the application lifecycle and initialization.
• bfe_balance/bfe_balance.go — Core load balancing orchestrator that coordinates GSLB and SLB routing decisions.
• bfe_balance/bal_gslb/bal_gslb.go — Global Server Load Balancing (GSLB) implementation for cross-cluster routing logic.
• bfe_balance/bal_slb/bal_rr.go — Server Load Balancing (SLB) with round-robin backend selection within a cluster.
• bfe_basic/condition/parser/parser.go — Condition expression parser enabling dynamic request routing rules and policies.
• bfe_config/bfe_cluster_conf/cluster_conf/cluster_conf_load.go — Cluster configuration loader that parses and validates backend cluster definitions.
• bfe_basic/request.go — Core request object definition representing HTTP requests flowing through the load balancer.

Add a new routing condition

1. Define the condition primitive in bfe_basic/condition/primitive.go with evaluation logic (bfe_basic/condition/primitive.go)
2. Add parser rules in the YACC grammar file to support the new condition syntax (bfe_basic/condition/parser/cond.y)
3. Add test cases in the parser test to validate the new condition (bfe_basic/condition/parser/parser_test.go)
4. Update configuration files in testdata/ to demonstrate the new condition usage (bfe_balance/testdata/bal_table/case1/cluster_table.data)

Add a new load balancing strategy

1. Create a new file in bfe_balance/bal_slb/ implementing the strategy interface (bfe_balance/bal_slb/bal_rr.go)
2. Register the strategy in the balance table constructor (bfe_balance/bal_table.go)
3. Add configuration loading logic in bfe_config to parse strategy parameters (bfe_config/bfe_cluster_conf/cluster_conf/cluster_conf_load.go)
4. Write unit tests with testdata fixtures to validate the strategy (bfe_balance/bal_slb/bal_rr_test.go)

Add a new request action/rewrite rule

1. Create a new action handler in bfe_basic/action/ extending the Action interface (bfe_basic/action/action.go)
2. Implement the Execute method to apply the rewrite transformation (bfe_basic/action/action_rewrite_test.go)
3. Add parser support in bfe_basic/condition/parser for the new action syntax (bfe_basic/condition/parser/parser.go)
4. Write integration tests validating the action with various request types (bfe_basic/action/action_test.go)

Extend configuration with a new cluster parameter

1. Define the parameter struct in the cluster configuration loader (bfe_config/bfe_cluster_conf/cluster_conf/cluster_conf_load.go)
2. Add parsing logic to extract the parameter from .conf files (bfe_config/bfe_cluster_conf/cluster_conf/cluster_conf_load.go)
3. Add testdata fixtures demonstrating the new parameter (bfe_config/bfe_cluster_conf/cluster_conf/testdata/cluster_conf_1.conf)
4. Add unit tests validating parameter parsing and validation (bfe_config/bfe_cluster_conf/cluster_conf/cluster_conf_load_test.go)

• Go — High-performance, concurrent request handling with goroutines and built-in networking; minimal runtime overhead suitable for a production load balancer.
• Custom condition parser (YACC/Lex) — Enables declarative routing rules without code changes; users can define complex conditions via configuration files.
• Modular plugin architecture — Allows extensibility for custom actions, conditions, and balancing strategies without modifying core code.
• Configuration-driven design — Separates routing logic from deployment; cluster, backend, and GSLB configurations can be updated without recompilation.

• Two-tier load balancing (GSLB + SLB)

  • Why: GSLB selects across geographic clusters; SLB distributes within a cluster. Enables geo-awareness and resilience.
  • Consequence: Additional latency and state management complexity; requires synchronization of health checks across both layers.

• In-memory balance table (pre-computed from config)

  • Why: Fast O(1) routing decisions at request time with no file I/O or parsing overhead.
  • Consequence: Config changes require reloading the entire balance table; cannot handle dynamic backend discovery without explicit reload.

• Condition-based routing via custom DSL parser

  • Why: Powerful, declarative rules without code changes; supports host, path, query, and custom matchers.
  • Consequence: Adds parser complexity and potential for parsing errors; condition evaluation has CPU overhead for complex rule sets.

• Synchronous health checks per backend

  • Why: Simple, deterministic health state; avoids race conditions and provides consistent routing decisions.
  • Consequence: Health check latency affects request routing; many concurrent health checks can become a bottleneck at scale.

• Does not provide built-in authentication or authorization; relies on backend services for auth.
• Not a reverse proxy with caching; focuses on routing and load distribution, not response caching.
• Does not handle TLS termination or certificate management directly; assumes external TLS or another layer.
• Not a real-time streaming load balancer; optimized for HTTP request-response worklo

Configuration-driven operation: BFE requires well-formed cluster_table.data and gslb.data files to start (see testdata/ for format). Health check state in bal_gslb/state.go is internal and may not be immediately visible in logs. The Yacc parser (2954 bytes in file list) suggests custom DSL parsing—check for .y grammar files if modifying configuration parsing. Docker builds reference VERSION file for tagging; manually update it before make docker if creating custom images.

• Global Server Load Balancing (GSLB) — BFE's bal_gslb/ subsystem implements geographic load balancing; critical to understand how it selects clusters across regions before selecting backends within a cluster
• Health Check State Machines — bfe_balance/backend/health_check.go and bal_gslb/state.go use state machines to track backend availability; understanding state transitions prevents routing to failed servers
• Consistent Hashing / Sticky Sessions — Load balancing strategies like round-robin (backend_rr.go) may need session affinity; relevant for stateful backends or connection pooling
• Layer 7 (Application Layer) Routing — BFE routes based on HTTP headers, host, path, not just IP/port; this is the core value proposition vs Layer 4 load balancers
• Hot Reload / Zero-Downtime Config Updates — Implied by conf-agent integration; BFE must reload routing tables without dropping active connections—examine how bal_table.go handles concurrent updates
• Backend Connection Pooling — Efficient request forwarding to backends requires connection reuse; likely implemented in bfe_balance/backend/ layers

• bfenetworks/api-server — Control plane companion that provides API and config management for BFE Server; required for production deployments
• bfenetworks/conf-agent — Fetches configuration updates from API-Server and triggers BFE Server config reload; bridges control and data planes
• bfenetworks/ingress-bfe — Kubernetes Ingress controller built atop BFE; enables native K8s integration for this load balancer
• envoyproxy/envoy — Comparable Layer 7 proxy with different architectural philosophy (C++ vs Go); reference for feature parity discussion
• nginx/nginx — Traditional alternative load balancer; BFE is designed as modern successor with better dynamic routing and GSLB out of the box

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive integration tests for bal_gslb (Global Server Load Balancing)

The bfe_balance/bal_gslb directory contains testdata (cluster1, cluster2, g1, g2, gb1, gb2) but lacks integration tests that verify end-to-end GSLB behavior across multiple clusters. The existing bal_gslb_test.go only covers unit tests. New integration tests would validate state transitions, cluster failover, and weight distribution across geographically distributed backends—critical for a production load balancer.

• [ ] Create bfe_balance/bal_gslb/bal_gslb_integration_test.go
• [ ] Add tests for cross-cluster failover scenarios using existing testdata files
• [ ] Add tests for sub_cluster state transitions and health check propagation
• [ ] Verify load distribution consistency across multiple GSLB cycles
• [ ] Add tests for concurrent cluster updates and state consistency

Add E2E tests for condition parsing and action composition

The bfe_basic/condition and bfe_basic/action directories contain a complex DSL parser (build.go, ast.go, composite.go) but existing tests (build_test.go, action_test.go, action_query_test.go) are unit-level only. No integration tests verify that parsed conditions correctly filter requests and trigger the expected action chains. This is critical for rule evaluation—the core of a layer 7 load balancer.

• [ ] Create bfe_basic/condition/e2e_test.go for complex condition compositions
• [ ] Add tests for nested composite conditions with AND/OR/NOT operators
• [ ] Create bfe_basic/action/e2e_test.go testing action chains (host rewrite → path modification → routing)
• [ ] Add tests for malformed condition syntax error handling
• [ ] Verify action execution order and state isolation across concurrent requests

Add health check resilience tests for backend pool failures

The bfe_balance/backend/health_check.go module is critical for determining backend availability, but health_check_test.go lacks tests for edge cases: network timeouts, partial failures in clusters, rapid health state oscillation, and behavior during backend pool saturation. These gaps risk cascading failures in production.

• [ ] Extend bfe_balance/backend/health_check_test.go with timeout simulation tests
• [ ] Add tests for health check behavior under high concurrency (simulate 1000+ backends)
• [ ] Add tests for marking backends unhealthy/healthy during connection pool exhaustion
• [ ] Add tests for health check interval timing and jitter under load
• [ ] Add tests for false-positive detection when backends recover from transient failures

• Add benchmark tests to bfe_balance/bal_slb/backend_rr_test.go comparing round-robin performance under different concurrency levels (10 concurrent backends vs 1000)
• Document the cluster_table.data schema with example comments in bfe_balance/testdata/bal_table/case1/cluster_table.data and create a JSON Schema validator for it
• Extend health_check_test.go to cover edge cases: backend recovery timing, cascade failures (multiple backends down), and health check timeout scenarios

The BFE codebase demonstrates a reasonable security posture with an established security policy and CII Best Practices certification. However, several areas require attention: the Docker build process uses relatively recent but not latest versions of base images, and there's limited visibility into configuration security practices. The main concerns are around dependency management and ensuring regular updates. The project has good governance with a dedicated security contact (bfe-security@baidu.com) and transparency in its security policy. No critical hardcoded secrets or obvious injection vulnerabilities are apparent from the file structure provided. The Go-based implementation in a stateless load balancer context reduces certain attack surfaces, though standard web application security practices should still be followed for configuration and secrets management.

• Medium · Outdated Go Version in Docker Build — Dockerfile, line 19. The Dockerfile uses Go 1.22.2 which may contain known vulnerabilities. While not critically old, Go versions should be regularly updated to receive security patches for dependencies and the runtime itself. Fix: Regularly update Go version to the latest stable release. Consider implementing automated dependency updates using Dependabot or similar tools.
• Medium · Alpine Linux Version Not Pinned in Final Stage — Dockerfile, line 31. The final stage uses 'alpine:3.19' which will pull the latest patch version. While this ensures security patches, it can introduce inconsistencies between builds. The build stage uses 'golang:1.22.2-alpine3.19' which is more specific. Fix: Pin the Alpine version to a specific patch level (e.g., 'alpine:3.19.1') to ensure reproducible builds while still receiving security updates.
• Low · Incomplete Dockerfile - Truncated Content — Dockerfile, line 32-33. The Dockerfile appears to be incomplete with a truncated RUN command that installs packages but doesn't show the full context. This suggests the provided snippet may not reflect the complete build configuration. Fix: Review the complete Dockerfile to ensure all build steps are properly configured and documented. Verify that all installed packages are necessary and from trusted sources.
• Low · Missing Security Headers Configuration — bfe_basic/action - configuration modules. As a layer 7 load balancer, BFE should document or enforce security headers for HTTP responses. No explicit security header configuration is visible in the provided structure. Fix: Document and implement default security headers (X-Frame-Options, X-Content-Type-Options, Strict-Transport-Security, etc.) that BFE applies to proxied requests.
• Low · Configuration File Security Not Evident — bfe_config directory and related configuration modules. While test configuration files exist in bfe_balance/testdata and bfe_config directories, there's no visible evidence of encryption for sensitive configuration values or documentation on protecting configuration files. Fix: Implement secure configuration management practices. Document how sensitive values (credentials, API keys) should be handled. Consider supporting configuration encryption or secure external secret management.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/bfenetworks/bfe shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live bfenetworks/bfe repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/bfenetworks/bfe.

What it runs against: a local clone of bfenetworks/bfe — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in bfenetworks/bfe | Confirms the artifact applies here, not a fork | | 2 | License is still Apache-2.0 | Catches relicense before you depend on it | | 3 | Default branch develop exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 40 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of bfenetworks/bfe. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/bfenetworks/bfe.git
#   cd bfe
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of bfenetworks/bfe and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "bfenetworks/bfe(\\.git)?\\b" \\
  && ok "origin remote is bfenetworks/bfe" \\
  || miss "origin remote is not bfenetworks/bfe (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Apache-2\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Apache-2\\.0\"" package.json 2>/dev/null) \\
  && ok "license is Apache-2.0" \\
  || miss "license drift — was Apache-2.0 at generation time"

# 3. Default branch
git rev-parse --verify develop >/dev/null 2>&1 \\
  && ok "default branch develop exists" \\
  || miss "default branch develop no longer exists"

# 4. Critical files exist
test -f "bfe.go" \\
  && ok "bfe.go" \\
  || miss "missing critical file: bfe.go"
test -f "bfe_balance/bfe_balance.go" \\
  && ok "bfe_balance/bfe_balance.go" \\
  || miss "missing critical file: bfe_balance/bfe_balance.go"
test -f "bfe_balance/bal_gslb/bal_gslb.go" \\
  && ok "bfe_balance/bal_gslb/bal_gslb.go" \\
  || miss "missing critical file: bfe_balance/bal_gslb/bal_gslb.go"
test -f "bfe_balance/bal_slb/bal_rr.go" \\
  && ok "bfe_balance/bal_slb/bal_rr.go" \\
  || miss "missing critical file: bfe_balance/bal_slb/bal_rr.go"
test -f "bfe_basic/condition/parser/parser.go" \\
  && ok "bfe_basic/condition/parser/parser.go" \\
  || miss "missing critical file: bfe_basic/condition/parser/parser.go"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 40 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~10d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/bfenetworks/bfe"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.