Making: github.com/midwayjs/mi… Welcome to Github to help us click a Star~
Since Midway Serverless 1.0 was released last year, many businesses have tried it out, taking advantage of the flexible capabilities of the Serverless container to reduce the infrastructure and operations concerns of a large number of developers. For the front-end developers, they only need to write a few functions to implement the back-end business logic and bring the business online quickly. We also said last year that using the Serverless architecture would improve the overall front-end development performance.
In March 2021, we launched the second big release of Midway Servereless. As said two years ago, open source is just the beginning, and the end is far from here. The Midway system wants to evolve at its current crossroads, allowing the front end to evolve toward application engineers.
Midway Serverless 2.0 was internally codenamed “Hercules,” a reference to Greek mythology and Marvel’s Hercules, who was born a demigod on his way to becoming a god. And we, through the user in v1.0 use situation, we saw a lot of problems, this time v2.0 iterative reconstruction, we hope to solve these problems, let the user experience and development efficiency further.
Evolution of Midway Serverless
Midway Serverless is a development solution for The Serverless cloud platform produced by Midway. Its content mainly includes the function framework @midwayJS/FAAS, as well as a series of tool chains and initiators matching the platform.
After its release in early 2020, in June of the same year, it released the front and back end integration scheme, which can conveniently call the function side code directly from the front-end code. We applied this integration scheme to the middle and back end projects of the group and achieved remarkable results.
In September of that year, we released the second version of the new Midway App Framework, introducing the component ecosystem, and the swagger, Typeorm, Mongo, gRPC, and other components have been incubated to greatly expand Midway’s capabilities.
In March 2021, we will release Midway Serverless 2.0, which will reuse Midway Serverless and Midway capabilities, with the same CLI toolchain, compiler, decorator, and more.
The biggest changes to Midway Serverless 2.0
As mentioned earlier, Midway Serverless is a Serverless solution consisting of a framework, runtime, toolchain, and configuration specification that, when combined, provide some unique capabilities for the Serverless architecture.
In traditional V1.0, we focused on:
- Migration between platforms is easier, allowing code to be the same across platforms
- Make the application easier to maintain and expand, provide standard cloud platform function input and output parameter event definition
- Let traditional applications deploy seamlessly to the Serverless environment
And V2.0, we are focused on the integration of application functions, front-end and back-end integration, more experience, higher development efficiency.
The original V1.0 bottom layer is compiled, including a troublesome.faas_debug_tmp directory, many students have trodden on its pit, once the error, it is difficult to check.
In essence, this is due to not using the same process restart scheme as the application, but also due to the difference in function development and traditional technology selection. Function execution and caching, resulting in v1.0 data may not be updated, often with invalid code changes.
In the new V2.0, we completely abandoned the original compilation method, using the same implementation method and application, while optimizing the function scenario. For users, in some scenarios (HTTP), the development function and application are the same structure and experience, the function and application are only different when deployed.
You can see the optimized development situation, not only the same as the application, but also relatively fast, no temporary directory will be generated, the change takes effect in real time.
Of course, this is not a feature addition, in addition to the architecture upgrade, we also provide more capabilities. Mainly divided into the following four aspects.
V2.0 pure function enhancements
First, we made additional enhancements to support functions in HTTP scenarios, including HTTP triggers, API gateways, and so on, in a pure function development scenario.
V2.0 Upgrade – Decorator unification
In V1.0, we defined the parameters of the trigger inf.ymlAlthough standard in the view of cloud native, the actual writing of the code, especially when added to our dependency injection container, was very tedious@FuncDecorator and class name, function name + handler name + class name + method name the user needs to be named multiple times.
From v2.0, we directly follow the application development mode, using the original @Controller decorator applied to the development of HTTP functions.
Meanwhile, the functions field in the original F.ML will no longer need to be filled in, and our publishing tool will automatically analyze routes from the code and register functions.
In addition to the @Controller decorator, we also support traditional application parameter decorators, such as @Query and @body, which are commonly used to retrieve parameters from requests, as well as decorators for response operations such as SetHeader and ContentType.
In addition to decorator unification, we have integrated the @MidwayJS/FAAS Framework into the new Framework, and now @MidwayJS/FAAS is a function Framework, which also has the same Application as the Application. The Context definition. For example, the following app method is exactly the same as the application.
In order to better support the functional writing, we use theconfiguration.tsAdded the function writing method, so that in the integration of functional scenarios can also choose the function writing method to write.
V2.0 Upgrade – Toolchain upgrade
Starting with Midway V2.0, we used @midwayJS/CLI as our basic CLI tool. The original function CLI (@MidwayJS/faas-CLI) will gradually complete its historical mission and be unified into @MidwayJS/CLI.
In the traditional CLI, all functions are combined into one NPM package. In this way, each application has to install one copy, occupying hard disk space and resources. In the new version, we have created an on-demand capability to differentiate by scenario, such as the cli tools installed in functions and application scenarios.
The advantage of this is that the new VERSION of the CLI installed fewer packages, naturally faster. At the same time, it can also freely combine the plug-ins, which can be applied to different scenarios more reasonably.
V2.0 Upgrade – Unit testing
In the case of unit tests of the original function, we also made adjustments.
The originalinvokeMethod, though simple, is difficult to be combined with the process of creating an application. Each invoke is a complete initialization logic and call, and in the case of HTTP, there are so many parameters to fill in that it is difficult to simulate the actual effect.
The new version, we use the idea of application, since we can use the application mode to start, it is natural to use the application development mode, using supertest to do the test, much simpler and more natural than the original.
V2.0 Upgrade in Web mode
In V1.0, we made it possible to seamlessly migrate application code to a Serverless environment for common egg/ KOA/Express frameworks, all of which are available in thef.ymladddeployTypeBy building an automated generation portal that supports the appeal of elastic containers in traditional applications.
I’ve had users ask, what if my code doesn’t want to run in a function environment anymore? The answer to V2.0 is that you can deploy that code to your own traditional container, or Docker, by applying patterns.
The way to deploy it is simple because of the use of@midwayjs/serverless-appStart an HTTP application using the same encoding pattern as the application (as mentioned in the test above).
Enhanced v2.0 integration capabilities
In June last year, we opened to the community an integrated coding solution, using functional coding and React Hooks coding, which is very familiar to students of front-end development.
Enhanced integration – Fast start
First is the extreme mode, the traditional React/Vue development/build time we all know, Webpack working time is often close to 20s, but thanks to the recent new Vite, after our test and use, the traditional 20S will be reduced to less than 2S, it can be said that the front end of a leap again.
Integration enhancement – Unit testing
The second aspect is single test, traditional integration, due to the existence of compilation, our single test is very difficult, there are users more than once asked us, how to do single test, how to do the elegant front and back end call.
In the new V2, we tested two scenarios.
You can use Supertest to perform traditional HTTP behavior simulation as a single test, or you can use what we providerunFunctionFunction to do a single test.
Integration enhancement – Support for applications
The third feature is very surprising. In addition to being used in functional scenarios, integration projects are now being used in application development as well. Traditional Midway projects can now be developed using an all-in-one solution.
Integration Enhancement – Run time upgrade
In V1.0, we wrote entry functions with many limitations due to compiler limitations, but in V2.0, we replaced the runtime with a native framework and native Node modules, so those limitations are gone.
At the same time, you can write your own hooks module to easily put business logic together.
In the future
Midway Serverless 2.0 offers a lot of enhancements, but it’s not enough. We’re still adding new capabilities to enrich scenarios so that the front end can take advantage of the new system.
The future is the era of Serverless and cloud.