How Biz-UI Crafted a Scalable Business Middle Platform – Lessons from the Frontlines

Front, Backend, and Middle Platform

The frontend is the user‑facing system (web, app) that must react quickly to changing business needs. The backend hosts core data, compute resources and infrastructure, prioritising stability and reliability. The middle platform sits between them, acting as a “gear” that balances the speed of the frontend with the stability of the backend and provides reusable business‑centric services.

Platform vs. Middle Platform

A platform offers technical services without business logic (e.g., generic middleware). A middle platform embeds business attributes—such as player, skill, or equipment services—and is therefore reusable across multiple frontends while carrying domain‑specific logic.

Middle Platform Classification

Business middle platform : abstracts common business capabilities for reuse.

Data middle platform : processes business data for downstream consumption.

Technical middle platform : packages middleware and infrastructure as reusable interfaces.

All three ultimately serve business needs, reduce cost and increase delivery efficiency.

Definition of Middle Platform

A middle platform abstracts shared business functions into reusable modules, forming a “middle‑end” layer that lowers development cost and accelerates delivery. It can be viewed as a product‑oriented platform that embeds business attributes into a reusable service suite.

Why Build a Middle Platform?

Middle platforms enable:

Support for multiple frontends from a single set of services.

Rapid response to new business demands.

Evolution from a monolithic platform to a business‑centric architecture when existing platforms cannot keep pace with growth.

Biz‑UI Business Middle Platform Construction Process

The construction is divided into three iterative stages.

Collect requirements & build team – In 2017 the monolith was migrated to micro‑services using a bottom‑up, capability‑driven approach. The BSAP (Business Service Architecture and Practice) project was created to provide shared libraries, middleware, and governance tools. Teams are formed in a crowdsourced model: developers propose problems, discuss solutions, and volunteer to implement them.

Analyze business & design features – Common capabilities are extracted across domains. Example: a lightweight Job middleware built with Golang and Redis provides basic scheduling plus extensions such as Dynamic Cron (runtime schedule changes) and Hook (custom callbacks, e.g., sending email or uploading to AWS S3). Design sessions use brainstorming to identify shared pain points and abstract solutions.

Implement & connect to frontend – Development follows the Minimum Viable Product (MVP) principle: deliver the smallest usable component, gather feedback, and iterate. The team follows a SAFe framework with ticket tracking, weekly BSAP sync meetings, and code reviews to ensure reliability and controllability.

Integration Patterns

Self‑service – Consumers integrate middle‑platform components themselves using documentation, examples, and training provided by the platform team.

Full‑package – The platform team assists consumers with code, configuration and deployment, useful for small‑scale component upgrades.

Design Examples

Job middleware (Golang + Redis)

// Simplified usage example
job := NewJobScheduler(redisClient)
job.AddTask("emailReport", DynamicCron("0 */2 * * *"), Hook(func(ctx context.Context) error {
    // send email or upload to S3
    return sendReport()
}))
job.Start()

Lightweight service communication layer

// Application entry point
func main() {
    app := NewApp()
    app.RegisterInitializer(MyServiceInitializer{})
    // ServerOption adds interceptors for tracing, logging, auth
    app.Start(ServerOption{Interceptors: []Interceptor{TraceInterceptor, LogInterceptor, AuthInterceptor}})
}

// Protobuf definition (example)
// service MyService { rpc DoWork(Request) returns (Response); }

Implementation Practices

The MVP approach is used for each component: deliver a minimal, functional version, collect real‑world feedback, then iteratively enhance. Development is tracked via tickets; weekly BSAP meetings review progress, design, and code quality. The middle platform serves internal micro‑service developers, who act as both product owners (defining requirements) and implementers (integrating components as pilots).

Future Roadmap

Productization – Add non‑functional qualities (scalability, reliability) and improve documentation to treat the middle platform as a distributable product.

Standardization – Define a unified mid‑platform API to harmonize integration methods across independently developed components.

Service‑ification – Transform library‑style components into independent services where appropriate, reducing language‑binding constraints and simplifying consumption.

In summary, the Biz‑UI middle platform demonstrates how a small, agile team can iteratively build a reusable, business‑centric backend layer that bridges frontends and backends, improves development efficiency, and positions the organization for sustainable growth.