How Midway Serverless Bridges Multi‑Cloud Functions with Seamless Code Migration

Midway Serverless: Core Concepts and Design Principles

Last weekend I gave a foundational presentation on Midway Serverless in Shanghai, covering its capabilities and the underlying design philosophy.

Background

Serverless adoption is accelerating across the industry, with companies like Alibaba migrating workloads to reduce costs. This talk first outlines the current serverless landscape, typical front‑end use cases, then introduces basic usage of Midway Serverless, followed by design insights for abstracting platform differences and future directions.

Midway has been the internal Node.js framework for Alibaba Group since 2014, evolving from Express to Koa and Egg, supporting both front‑end separation and function‑as‑a‑service models.

Midway v1 was a full‑stack web framework with dependency injection, suitable for large applications. With Midway Serverless, the framework’s focus shifts toward multi‑cloud deployment and seamless migration of traditional applications to elastic services.

Key goals of Midway Serverless are: (1) provide a serverless framework that works on multiple cloud platforms, (2) simplify migration of legacy applications to elastic services, and (3) enable code to run unchanged across traditional and function‑based environments.

Structure

The typical project layout consists of a f.yml configuration file and an index.ts entry file. The f.yml file replaces the routing layer; the gateway handles routing, while the controller logic remains in the code.

Each service defined in f.yml maps to an interface whose handler field binds to a method. At runtime, the framework injects dependencies dynamically, eliminating performance concerns.

By standardising f.yml, developers can define HTTP triggers via path and method, or rely on default wildcard routing.

Toolchain and Capabilities

Beyond f.yml, Midway Serverless provides faas-cli with four commands— create, invoke, test, and deploy —covering the entire development lifecycle. Sample projects demonstrate integration with React/Vue and various use‑case demos.

Principle Analysis

The dependency‑injection container from Midway v1 loads user code, builds a dependency graph, and resolves instances on each request.

To avoid tight coupling with a single framework, the design abstracts common components such as router, ORM, and GraphQL so they can be reused across different scenarios, preserving code continuity when moving from monolithic to serverless architectures.

Design

Architecture Anti‑Corrosion Layer

A thin anti‑corrosion layer sits between the cloud platform’s runtime and the user’s entry function, normalising parameters, handling async differences, and propagating errors. It also re‑creates the Midway v1 container based on f.yml metadata.

The generated entry file ( index.js) performs two main tasks: (1) initialise platform adapters according to provider.name in f.yml (supporting Alibaba Cloud, Tencent Cloud, AWS, etc.), and (2) invoke the framework’s FaaSStarter to run user code ( src/index.ts). Helper wrappers like asyncWrapper and asyncEvent enable uniform async handling.

Runtime Adaptation Example

An Alibaba Cloud adapter demonstrates how asyncEvent distinguishes Web and non‑Web triggers, constructs a Koa‑like context for HTTP requests, and then forwards the normalised parameters to the user’s logic via the lifecycle hooks before and after.

Application Migration

All extensions (layers) are reusable across runtimes. By adding a simple f.yml with four lines, the Midway builder generates the necessary entry and adaptation code, making the solution suitable for private deployments within enterprises.

Conclusion

The talk covered Midway Serverless fundamentals, entry generation, lifecycle management, and migration strategies. Future articles will explore additional aspects of the framework.