The author source | | zhang ting Serverless public number

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. As stated last year, the use of the Serverless architecture enables overall front-end development performance to improve.

In March 2021, Midway Serverless launched its second major release. 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. Through the use of V1.0, we saw a lot of problems, this iteration of V2.0 reconstruction, we hope to solve these problems, let the user experience and development efficiency further.

  • Making:https://github.com/midwayjs/midway
  • Welcome to Github to help v2.0 Star~

Evolution of Midway Serverless

Midway Serverless is a development solution for The Serverless cloud platform produced by Midway. Its content mainly includes 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 end code directly from the front-end code. After the integration scheme was applied to the middle and back end projects of the group, remarkable effects were achieved.

In September of that year, Midway Serverless released the second version of the new Midway Application framework, introducing the component ecosystem, and components like Swagger, Typeorm, Mongo, gRPC, and more continued to proliferated, greatly expanding Midway’s capabilities.

In March 2021, Midway Serverless 2.0 will be released, reusing the capabilities of Midway Serverless and Midway, 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 a Serverless architecture.

Legacy V1.0, Midway Serverless featured:

  1. Easier migration between platforms, allowing code to be the same across platforms;
  2. Make the application easier to maintain and expand, provide a standard cloud platform function input parameter event definition;
  3. Let traditional applications deploy seamlessly to the Serverless environment.

V2.0, Midway Serverless, is all about integration of application functions, front-end and back-end, better experience and more efficient development.

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 Midway Server version 2.0, Midway Serverless has completely abandoned the original build method and implemented it in the same way as the application, while optimizing the function scenarios. In some scenarios (HTTP), developing a function is the same structure and experience as developing an application. Functions and applications differ only 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.

This is a fundamental change from V2.0 to V1.0, and a huge advantage of the overall architecture upgrade.

Of course, this is not a feature addition, as Midway Serverless 2.0 provides additional capabilities in addition to architectural upgrades. Mainly divided into the following four aspects.

Three, V2.0 pure function enhancement

First, Midway Serverless 2.0 provides additional enhanced support for HTTP scenario functions, including HTTP triggers, API gateways, and so on, in a purely functional development scenario.

V2.0 Upgrade – Decorator unification

In the V1.0 era, Midway Serverless defined the parameters of triggers in F.ml, which was standard in the cloud native sense, but very cumbersome when it came to writing code, especially with the @func decorator and class naming in our dependency injection container. Function name + Handler name + Class name + method name The user needs to be named multiple times.

Beginning with the V2.0 release, Midway Serverless took the same approach to application development, using the @Controller decorator for 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, Midway Serverless 2.0 also supports traditional application parameter decorators, such as @Query, @body, and other decorators that retrieve parameters from requests. Decorators for response operations such as SetHeader and ContentType are also supported.

In addition to decorator unification, Midway Serverless 2.0 incorporated the @MidwayJS/FAAS Framework into the new Framework, and now the @MidwayJS/FAAS Framework. It also has the same Application and Context definitions as the Application. For example, the following app method is exactly the same as the application.

To better support functional writing, Midway Serverless 2.0 added functional writing to the Portal configuration.ts so that functions can be written in an optional way in integration and other functional scenarios.

V2.0 Upgrade – Toolchain upgrade

Starting with Midway V2.0, the @MidwayJS/FAas-CLI function 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, there is an on demand capability, which is differentiated by scenario, for example, the cli tools installed in functions and application scenarios will be different.

The advantage of this is that the new VERSION of the CLI installed fewer packages, naturally faster. At the same time, it is also free to combine the plug-ins and apply them to different scenarios.

V2.0 Upgrade – Unit testing

Adjustments have also been made to Midway Serverless 2.0 for unit testing of the original functions.

The original Invoke method, though simple, was difficult to be combined with the process of creating an application. Each Invoke was a complete initialization logic and call, and in the case of HTTP, there were so many parameters to fill that it was difficult to simulate the actual effect.

The new version uses the idea of the application, since you can use the application mode to start, it can also use the application development mode, using supertest to do the test, much simpler than the original natural.

V2.0 Upgrade in Web mode

In the V1.0 era, Midway Serverless made it possible to seamlessly migrate application code to Serverless environments in response to industry-common egg/ KOA/Express frameworks, all of which can add deployType to F.ML, Support the appeal of elastic containers in traditional applications by building an automated generation portal.

I’ve had users ask, what if I don’t want my code 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, with @MidwayJS/Serverless-app (mentioned in the test above) and the same encoding pattern as the application, you can start an HTTP application.

Iv. Enhanced V2.0 integration capability

Last June, Midway Serverless launched an all-in-one coding solution to the community, using functional coding, like React Hooks, that is familiar to front-end developers.

In V2.0, this integration scheme is further enhanced to further enhance the experience of front-end development. From the following four aspects to introduce one by one.

Enhanced integration – Fast start

First is the extreme mode, the traditional React/Vue development/construction 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 reduced to below 2S, it can be said that the front end once again made a leap.

And Vite good compatibility, can contain a lot of front-end frameworks, although Vite is just out, I believe that it will not be long before the full front-end scenario rolled out.

Integration enhancement – Unit testing

The second aspect is single test, traditional integration, because of the existence of compilation, our single test is very difficult, users have asked us more than once, how to do single test, how to do the elegant back and forth call.

In the new V2.0, two approaches were used for testing.

You can either use supertest to perform the traditional HTTP behavior simulation single test or use the runFunction function we provide for 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 for Midway Serverless 2.0 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 modules to easily put business logic together.

Five, 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 and make the front end feel comfortable with the benefits of the new system.

The future is the era of Serverless and cloud.