This document shows the success story of the use of SCF in online education made available by IMWeb, which boasts the following achievements:
IMWeb has made various technological attempts in the traditional web application area, such as traditional offline package and PWA offline application. However, each technology stack has its own strengths and weaknesses. The multi-dimensional comparison between the team's current technical schemes is as shown below:
The comparison unveils that server-side rendering (SSR) has outstanding performance with regard to above-the-fold rendering and SEO. Based on the result, the team favors the SSR scheme for the following reasons:
The following performance optimization issues are highlighted:
renderToStringmethod of React on the server to render the React component as HTML strings. For complicated SSR applications, this process may involve a large amount of CPU-intensive computation, which is not a field of expertise of Node.
Service availability: as most frontend engineers may not be good at service OPS, service availability is also an important concern in technical scheme selection.
Based on the issues mentioned above, the considerations can be summarized as follows:
The SSR technical architecture used by the team is as shown below:
The following sections describe the team's existing schemes in terms of code organization, performance optimization, and runtime context.
A heterogeneous mode is used in both the PC and HTML5 projects to construct SSR applications as shown below:
In heterogeneous mode, business developers can focus more on the business features without being distracted by runtime problems; however, they also need to pay attention to the following:
documentin traditional browsers.
Page rendering usually depends on backend data, which can be divided into dynamic data and static data:
By separating dynamic/static data for APIs, the static data can be used for caching thanks to its low latency sensitivity. After static data is used to render the page on the server, the dynamic data will be used to perform secondary rendering on the server. The main logic is as shown below:
Redis is used to cache the page rendered with static data, which not only accelerates SSR rendering but also improves the QPS of a single server (
renderToString is a CPU-intensive operation in a certain sense).
On the client, PWA can be used to cache static data-based HTML SSR pages offline so as to further improve the above-the-fold rendering performance. The main logic is as shown below:
Because of the high OPS complexity and maintenance costs of backend applications, Serverless (Tencent Cloud SCF) is used to deploy SSR applications. Thanks to the inherent advantages of the Serverless architecture mode, the team does not need to concern over issues such as service OPS and scaling.
As shown above, in essence, an SSR application is a Node application, and SCF invocation is an event. Therefore, the following method is used to ensure compatibility with the two modes:
Based on the various standardized APIs provided by Tencent Cloud Serverless Framework, Serverless-based encapsulation is added to Tencent Cloud's proprietary Node framework (imserver). In addition, compatibility with the elements from
Koa Request Context has been added to the entry as shown below:
As a business has multiple pages implemented through SSR, if SCF is used to implement SSR, it is required to determine whether the business features should be combined to one SCF function (at the business level) or divided into multiple functions (at the page level). The latter is recommended for the following advantages:
Here, as the current project has implemented automated construction of SCF functions, the corresponding function will be automatically generated with the
.scfssr.json configuration file, which will have no impact on the current development. Only multiple functions will be generated during the construction, minimizing the application maintenance and development costs.
In addition, based on the SCF function construction process, the code of a single function can be made simpler. Based on the analysis of the dependencies in
package.json, built-in toolkits can be removed from the function container, and import analysis will be performed on the third-party packages depended on by the function to remove redundancy as shown below:
The logic of SCF-based multi-function SSR scheme is as shown below. When there is a version update, the release process and steps will become relatively complicated.
prehubaliases in the function and point them to the
releasealias of function B and publish it into the
releasestage of the API Gateway service.
prehubalias of function B and publish it into the
prehubstage of the API Gateway service.
devstage of the API Gateway service.
$DEFAULTalias to point it to the
$LATESTversion. Continuous development and modification can be performed based on this version, and new versions can be published after modification.
prehubalias can be configured to point to version 3 for test and trial in the pre-release environment.
releasealias version from 1 to 2 for beta test.
To optimize the SCF function release process, a quick SCF function release tool developed based on the Node SDK of Tencent Cloud Serverless is provided as shown below:
A complete lifecycle of an SCF SSR application is as shown below:
The SCF-based SSR scheme can greatly reduce the service OPS costs. Based on the Tencent Cloud Serverless log system, all individual SSR application requests can have complete linkage on the log platform, which greatly speeds up problem locating and troubleshooting.
The Serverless architecture mode has a long cold start time, and technical improvements have been made in SCF accordingly, such as pre-start container. The actual business can also be optimized; for example, downgrade optimization can be made on the service at the access layer. The optimization is as shown below:
Subsequent optimization can be made from various aspects such as beta test and multi-dimensional downgrade.