Ali Midway officially released Serverless V1.0, 50% improvement in R&D efficiency

Github: Github.com/midwayjs/mi…For the development of the front end and Node.js,Please go to Github to click Star!



Last year, Alibaba introduced Serverless architecture and took advantage of its next-generation R&D architecture to reduce the focus of a large number of r&d staff on infrastructure and operations. For front-end developers, they only need to write a few functions to implement the back-end business logic, drive the business online quickly, and make the whole front-endR&d efficiency increased by 50%.



Over the past six months, Midway FaaS has gained a lot of attention from students and many large corporations. Thank you for joining us. Today, the Midway FaaS will evolve into the Midway Serverless and become the core scenario of the Midway system with the official release of V1.0.



V1.0 represents an official release and can be used with confidence. Through the entire Midway Serverless system, we are opening ali’s Serverless capabilities to a whole new era. As said two years ago, open source is just the beginning, and the end is far from here.



Serverless is the golden age of cloud discovery for all of you, and Node.js is the place to be, with the Midway system at the crossroads where it’s going to lead.

What is Midway Serverless

As mentioned earlier, Midway Serverless is a Serverless solution consisting of a framework, runtime, toolchain, and configuration specification. The combination of these components provides some unique capabilities for a Serverless architecture:

1. Migration between platforms is easier

   • Code is basically the same on every platform by providing a uniform configuration specification and entry smoothing mechanism;
   • Extend the runtime apis of different cloud platforms to not only load common inter-platform extensions, but also access private deployment solutions within the company;
2. Make your application easier to maintain and expand

   • Provides a standard cloud platform function entry and exit parameter event definition;
   • Provide multiple sets of community front-end React, Vue and other integrated development schemes;
   • We use TypeScript as the base language for extensions and definitions.
   • Providing a comprehensive Midway system signature dependency injection solution;
3. Ecology is lighter and freer

   • The functional architecture reuses KOA’s ecology and Web middleware capabilities, making it easier to deal with traditional Web.
   • Provide egg component reuse egg plug-in ecological chain, enterprise development link is more simple and smooth;
   • The Midway architecture’s unified decorator capabilities make traditional Web migration to Serverless faster and better;

All of the capabilities mentioned above are now open source at the Midway Serverless repository, welcoming Star. Making: github.com/midwayjs/mi…

Anti-platform lock

Vendor Lock-in is a question that torments the soul of everyone who uses a cloud platform. Midway Serverless’s original intent was to have a single set of code that could run on different platforms and runtimes. We don’t recommend customizing runtimes without knowing the whole picture. In fact, the official runtime is the most stable and certainly the best performing, and all benchmark runs are based on that. Most of the enterprises we know the first problem when facing Serverless is whether my code must be tied to Ali Cloud, Tencent Cloud, AWS and so on. Faced with this problem, Midway Serverless provides a set of “hidden” portals with generic definitions to solve this problem.

For each platform, Midway Serverless provides different runtime initiators to smooth out platform differences and regularize platform entry and exit parameters, event structures, and gateway return formats so that users are as unaware of differences in underlying containers and protocols as possible.









In addition, Midway Serverless provides a set of Spec definitions that smoothen the differences between platforms while making it easy to reuse the same toolchains and functional logic across multiple platforms.







In this way, both API Gateways and plain HTTP triggers can provide apis on a single programming plane, making writing code easier.

TS and decorators

Function writing is flexible, which brings simplicity and maintenance costs. This introduces TS into functions, and introduces standards and extensibility.



The following code, which appears to be koA’s standard syntax, is actually an API for HTTP triggers in functions. In order to be consistent with the Syntax of the Web stack, some changes have been made to make parameter fetching and call as seamless as possible, and also reduce the learning cost, and the original code can be better migrated.







On the other hand, methods decorated with decorators will become function entrances, freeing up the structure of the entire function. By building in such a way that the actual entry is hidden, not only can functions be called across multiple platforms, but also can be adapted to different routes. In the example above, it is possible to have more than one entry in a fileShare the same codeBut in factEach function is called independently, provides convenience in management and later maintenance.



The actual structure of different cloud platforms is different. If users need to use the traditional event and context structures, we also provide different definitions for triggers of different platforms to facilitate code writing, as shown in the following figure.

Reuse community ecology

As mentioned above, the Midway Serverless architecture was designed to reuse the existing KOA ecosystem, transforming the underlying event rules of multiple platforms into a unified KOA-like API. The API is similar in purpose to the entire KOA Web ecosystem, which we also hopeThe entire MIDDLEWARE ecosystem of KOA can be reused. As shown below, it introduces@koa/cors 。







On the other hand, Midway, thanks to its excellent IoC componentization capabilities, provided the egg foundation for the upper level, as wellReuse an existing Egg plug-in, allowing traditional enterprise development capabilities to continue, as shown in the following figureegg-mysqlExamples of plug-ins.

Applications and functions

Serverless is the direction for some time to come and the paving brick for the front end to move to a higher level. I have been thinking about the relationship between the end state of functional development and applications. At the present stage, our answer is to unify. After countless soul questioning and user demand questioning, we have come to this answer, function is the smallest embodiment of the application in the current business, more simply, it is part of the code running the application in the smallest specification container. In the following period of time, we will focus on the access of more platforms and the migration scheme of traditional applications, so that the former users can also enjoy the dividend of Serverless flexibility, so that the cost of enterprises is lower and the business is easier to go online.