How Ele.me’s API Everything Framework Transforms Backend Service Integration

Overview

API Everything is a unified API gateway framework built at Ele.me to isolate front‑end HTTP calls from back‑end SOA services, provide protocol conversion, authentication, orchestration, rate‑limiting, mock services and automated documentation.

Key Requirements

HTTP‑to‑SOA mapping with SSO authentication.

API orchestration (compose multiple services into a single response).

Automated Swagger‑compatible documentation generated from JavaDoc annotations.

Automated regression testing (API Robot).

Mock service generation from Maven dependencies.

Rate limiting, anti‑scraping and gray‑release control.

Design Principles

Stability and high availability – the framework must remain operational even if optional features are disabled.

Performance (throughput, latency) and fault tolerance with graceful degradation of external dependencies.

Isolation of back‑end services from external traffic.

Self‑service DevOps: metrics, monitoring, alerting, log/trace access and auto‑scaling.

Clear separation of responsibilities between the framework and consuming applications.

Automation of configuration, deployment and documentation (“code‑as‑documentation”).

User‑centric configuration – minimal manual steps for developers.

API Lifecycle

1. Developers annotate Java interfaces with @Api and related metadata and optionally define mock cases.

2. Build system (ELESS) emits a deployment event.

3. API Portal parses the compiled classes, extracts annotations and generates Swagger JSON, which is stored and displayed in a custom table view and the standard Swagger UI (“Try it out”).

4. Stargate Cluster consumes the deployment event, stores it in the proprietary MaxQ queue and triggers a Docker deployment via the internal AppOS platform.

5. New Docker containers are registered with the Nginx management platform (Navigator); old containers are deregistered, achieving zero‑downtime roll‑out.

6. At runtime the gateway converts incoming HTTP requests to SOA calls, applies authentication, rate limiting, orchestration rules and optionally routes to Mock Server based on query parameters.

7. Monitoring, alerting and auto‑scaling are handled by the DevOps layer.

Core Components

API Portal – central documentation hub; parses source code, generates Swagger docs, exposes “Try it out” and custom table UI.

Stargate Cluster – runtime gateway; listens to MaxQ, launches Docker instances, registers them with Nginx, performs protocol conversion and routing.

API Robot – automated regression tester; reads API definitions from the portal and issues test requests against Stargate.

Mock Server – mock response generator; automatically discovers service interfaces from Maven artifacts, lists classes/methods, and lets users create Mock Cases with input matching rules and expression‑based output.

Stargate Cluster Technical Architecture

The flow is:

ELESS (Ele.me’s CI/CD system) publishes a build/deploy message.

Message is written to MaxQ, a high‑throughput internal MQ.

Stargate core service reads the message and stores minimal routing metadata (stable component).

Stargate operational service consumes the metadata, invokes AppOS to start a Docker container that runs the generated Web API code.

AppOS returns the container IP; Navigator registers the IP in the Nginx upstream pool.

When a newer version is ready, the old container is stopped and its IP removed from Nginx, ensuring seamless traffic cut‑over.

Docker‑Based Zero‑Downtime Deployment

Each API version is identified by a “Push Seq”. The same Push Seq is stored both in the SOA service and the corresponding Web API container, guaranteeing version consistency. Deployment metadata (artifact version, container ID, timestamps) is persisted for audit.

Automated Documentation (API Portal)

During deployment the portal scans compiled classes, extracts JavaDoc annotations such as @ApiOperation, @ApiParam, and builds a Swagger JSON file. The portal then renders a custom table view for front‑end developers while preserving the original Swagger UI for “Try it out”.

Mock Server Workflow

1. User supplies a Maven coordinate (groupId:artifactId:version) of the target SOA service.

2. Mock Server downloads the artifact from Ele.me’s private Maven repository, reflects over the classes to list available methods.

3. For each method a Mock Case can be created. The case defines an Input pattern (e.g., any integer for field type) and an Output expression (static JSON or evaluated Groovy/SpEL).

4. When an incoming request matches the Input pattern, the Mock Case’s Output is returned, bypassing the real SOA service.

Front‑End / Back‑End Decoupling

Back‑end developers push annotated code; API Portal instantly updates documentation and notifies front‑end teams. Front‑end developers consume the docs and use Mock Server to develop UI logic without waiting for the real service. Once the back‑end API is ready, a quick integration test (via API Robot) validates compatibility, reducing overall development time from an estimated five days to three days (≈50 % effort reduction).

Open Challenges

End‑to‑end tracing and rapid fault localization across the gateway, mock layer and SOA services.

Automated incident capture, analysis and self‑healing mechanisms.

Snapshot‑based regression testing using recorded traffic.

Exploration of async web techniques and Go for higher performance.

Intelligent recommendation of API composition versus new development.

Business‑level API attribute analysis and search/recommendation services.

References

Ele.me internal services: ELESS, MaxQ, AppOS, Navigator (Nginx management).