Explore the front-end development pattern in Serverless

Dynamic pages based on template rendering

In the early Internet age, our web pages were simply static or dynamic pages, mainly for the display and dissemination of information. This time to develop a Web page is also very easy, mainly through JSP, PHP and other technologies to write some dynamic templates, and then through the Web Server template parsing into a HTML file, the browser is only responsible for rendering these HTML files. At this stage, there is no division of labor between the front and back ends, usually the back-end engineers write the front end pages incidentally.

Front-end engineering based on Node.js

The introduction of Node.js in 2009 was also a historic moment for front-end engineers. Along with Node.js comes the CommonJS specification and the NPM package management mechanism. Subsequently, a series of front-end development and construction tools based on Node.js, such as Grunt, Gulp and Webpack, emerged.

Around 2013, the first versions of the three front-end frameworks, React. Js /Angular/ vue.js, were released. We can go from page-by-page development to component-based development. After the completion of development, webpack and other tools are used for package construction, and the command line tool based on Node.js is used to publish the construction results online. Front-end development has become standardized, standardized, and engineered.

Next generation front-end development patterns

As you can see, every change in the front-end development model has been caused by a transformative technology. First came AJAX, then Node.js. So what’s the next transformative technology? It goes without saying, Serverless.

Introduction of Serverless

As defined by CNCF, Serverless refers to the concept of building and running applications that do not require server administration. (serverless-overview)

Serverless computing refers to the concept of building and running applications that do not require server management. — CNCF

Serverless is already connected to the front end, but we may not be aware of it. For example, after we publish static resources to CDN, we do not need to care about how many nodes CDN has, how to distribute the nodes, how to do load balancing and how to achieve network acceleration, so CDN is Serverless for the front end. Another example is the object storage. Like CDN, we only need to upload files to the object storage and use it directly. We do not need to care about how to access files and how to control permissions. Even some third-party API services are Serverless, because we don’t need to care about the server when we use them.

Of course, having motion sensation is not enough, we still need a more precise definition. From a technical point of view, Serverless is a combination of FaaS and BaaS.

Serverless = FaaS + BaaS.

To put it simply, FaaS (Function as a Service) is a platform for running functions, such as Function calculation of Ali Cloud and Lambda of AWS.

Backend as a Service (BaaS) is back-end cloud services, such as cloud databases, object storage, and message queues. With BaaS, we can greatly simplify our application development.

Serverless can be understood as running in FaaS, using functions of BaaS.

The main features of Serverless are:

• event-driven
  • Functions In the FaaS platform, a series of events are required to drive function execution.
• stateless
  • Because each function execution may use a different container, there is no memory or data sharing. If you want to share data, you can only do so through third-party services such as Redis.
• No operational
  • With Serverless we do not need to care about the server, do not need to care about operation and maintenance. This is also at the heart of Serverless’s thinking.
• Low cost
  • Using Serverless is cheap because we only pay for each function run. If the function does not run, it costs nothing and does not waste server resources

Framework (Framework)

Currently, there is no unified Serverless standard, and Serverless services provided by different cloud computing platforms are likely to be different, which leads to the failure of smooth migration of our code. One of the main functions of the Serverless framework is to simplify the development and deployment process of Serverless. Another major function is to shield the differences between different Serverless services, so that our functions can be modified with no changes or only minor changes. It also runs in other Serverless services.

Common Serverless frameworks include Serverless Framework, ZEIT Now, Apex, etc. However, these are basically foreign companies do, there is no such platform in China.

Command line tool

Of course, the main development method is still local development. So developing Serverless’s command-line tools locally is also essential.

There are two main types of command line tools. One is provided by cloud computing platforms, such as AWS of AWS, Az of Azure and Fun of Ali Cloud. There are also classes provided by the Serverless framework, such as Serverless, now.

Most of the tools, such as Serverless, Fun, etc., are implemented in Node.js.

Here are some examples of command line tools.

The deployment of

# serverless
$ serverless deploy
# fun
$ fun deploy
Copy the code

Application scenarios

One layer above the development tools are some vertical application scenarios for Serverless. In addition to using traditional server-side development, Serverless technology is currently used for small program development and may be designed for the Internet of Things (IoT) domain in the future.

Front-end development mode based on Serverless

In this chapter, mainly to several cases to illustrate Serverless based front-end development model, and it and the previous front-end development what is different.

Before getting into specific cases, take a look at the traditional development process.

In a traditional development process, we need front-end engineers to write pages and back-end engineers to write interfaces. After the back-end interface is written, deploy the interface, and then perform front-end and back-end debugging. After the joint investigation is completed, it will be tested and put online. After the system is online, o&M engineers need to maintain the system. The whole process involves many different roles, the link is long, and communication and coordination is also a problem.

However, based on Serverless, the back end becomes very simple. The previous back-end applications are divided into functions one by one. You only need to write functions and deploy them to Serverless service, and there is no need to care about any server operation and maintenance. The bar for back-end development has dropped dramatically. As a result, you only need one front end engineer to do all the development work.

Of course, front-end engineers writing back-end based on Serverless also need to have some back-end knowledge. Scenarios involving complex back-end systems or where Serverless is not appropriate still require back-end development, and the backend becomes further behind.

At the bottom are the various back-end microservices, and at the top are the various front-end applications. Before microservices and applications, there was BFF, usually developed by front end engineers.

This architecture solves the problem of interface coordination, but it also introduces some new problems.

For example, developing a BFF application for each device also presents some problems of duplication. And whereas the front end used to just develop pages and focus on browser-side rendering, now it has to maintain various BFF applications. In the past, the front-end didn’t need to care about concurrency, but now the concurrency pressure is on the BFF. Overall, the operation and maintenance costs are very high, and usually the front end is not good at operation and maintenance.

Serverless can help us solve these problems. With Serverless, we can implement aggregate clipping of individual interfaces using one function at a time. A request from the front end to the BFF is like an HTTP trigger for FaaS, triggering the execution of a function that implements the business logic for the request, such as calling multiple microservices to fetch data, and then returning the processing results to the front end. In this way, the pressure of operation and maintenance is shifted from the former BFF Server to FaaS service, and the front end no longer needs to care about the Server.

The above image is based on the BFF architecture of Serverless. In order to better manage various apis, we can also add a gateway layer to manage all apis (such as ali Cloud gateway) through the gateway, such as grouping and environment of apis. With API gateways, the front end does not execute functions directly through HTTP triggers, but instead sends requests to the gateway, which triggers specific functions to execute.

Serverless based small program development

At present, the domestic use of Serverless more scenarios may be the small process development. The specific implementation is small program cloud development, Alipay small program and wechat small program have provided cloud development functions.

In traditional small program development, we need front-end engineers to develop small program; The backend engineer develops the server side. Small program back-end development and other back-end application development, the essence is the same, need to care about the application of load balancing, backup redundancy, monitoring alarm and other deployment operations. If the development team is small, you may need a front end engineer to implement the server side.

However, based on cloud development, developers only need to focus on the implementation of the business, by a front-end engineer can complete the whole application of the front and back end development. Because cloud development encapsulates the backend as a BaaS service and provides developers with corresponding SDKS, developers can use various backend services as if they were calling functions. The operation and maintenance of applications has also shifted to cloud development providers.

Here are some examples of using Alipay’s Basement, functions defined in the FaaS service.

Operating database

// 'basement' is a global variable
// Operate the database
basement.db.collection('users')
	.insertOne({
		name: 'node'.age: 18,
	})
	.then((a)= > {
		resolve({ success: true });
	})
	.catch(err= > {
		reject({ success: false });
	});
Copy the code

To upload pictures

// Upload the image
basement.file
	.uploadFile(options)
	.then((image) = > {
		this.setData({
			iconUrl: image.fileUrl,
		});
	})
	.catch(console.error);
Copy the code

Call a function

// Call the function
basement.function
	.invoke('getUserInfo')
	.then((res) = > { 
		this.setData({ 
			user: res.result
		});
	})
	.catch(console.error}
Copy the code

Serverless development best practices

The biggest difference between Serverless development mode and traditional development mode is that in traditional development mode, we are based on application development. After development, we need to unit test and integrate test the application. Based on Serverless, the development is a function, so how should we test the Serverless function? What is the difference between testing Serverless functions and normal unit testing?

Another important point is, how does the application developed based on Serverless perform? How can I improve the performance of Serverless applications?

This chapter focuses on best practices for testing Serverless based functions and for performance of functions.

To make it easier to unit test functions, we need to separate business logic and function-dependent FaaS (such as function calculations) from BaaS (such as cloud databases). When FaaS and BaaS are separated, we can test the business logic of a function just like writing traditional unit tests. You can then write integration tests to verify that the integration of functions and other services is working properly.

Write testable functions

The above code was refactored based on the principle of separating FaaS and BaaS, which are business logic and function dependent.

class Users {
  constructor(db, mailer) {
    this.db = db;
    this.mailer = mailer;
  }

  save(email, callback) {
    const user = {
      email: email,
      created_at: Date.now()
    }

    this.db.saveUser(user, function (err) {
      if (err) {
        callback(err);
      } else {
        this.mailer.sendWelcomeEmail(email); callback(); }}); }}module.exports = Users;
Copy the code

const db = require('db').connect();
const mailer = require('mailer');
const Users = require('users');

let users = new Users(db, mailer);

module.exports.saveUser = (event, context, callback) = > {
  users.save(event.email, callback);
};
Copy the code

In the refactored code, we put all the business logic in the Users class, which does not depend on any external services. When testing, we can pass in mock services instead of real DB or mailer.

Here is an example of a simulated Mailer.

/ / simulate the mailer
const mailer = {
  sendWelcomeEmail: (email) = > {
	console.log(`Send email to ${email}success! `); }};Copy the code

This ensures that the business code runs as expected, as long as sufficient unit testing is done on Users.

You can then pass in the real DB and mailer and do a simple integration test to see if the whole function works.

The refactored code also has the benefit of facilitating function migration. When we want to migrate functions from one platform to another, we just need to change the way Users call according to the parameters provided by different platforms, without changing the business logic.

Function performance

For development with Serverless, there is also a common concern about the performance of the functions.

For traditional applications, our programs are launched and live in memory; This is not the case with the Serverless function.

When the event to be executed by the driver function arrives, the code needs to be downloaded, a container needs to be started, a runtime environment needs to be started within the container, and the code needs to be executed. The first steps are collectively called Cold Start. Traditional applications do not have a cold start process.

Here is a schematic of the function life cycle:

www.youtube.com/watch?v=oQF…

The length of the cold start time is a key factor in function performance. To optimize the performance of a function, you need to optimize it at all stages of the function life cycle.

Cold start / Warm start with AWS Lambda

There are some consistent conclusions from these tests:

• Increasing the memory of functions can reduce the cold start time
• C#, Java and other programming languages have about 100 times the startup time of node. js and Python

Based on the above conclusion, if you want Java’s cold startup time to be as small as Node.js, you can allocate more memory for Java. But more memory means more costs.

Perform context reuse

How does the above conclusion help us improve the function performance? Of course there is. Since the runtime can be preserved, it means that we can reuse the execution context within the runtime.

Here’s an example:

const mysql = require('mysql');

module.exports.saveUser = (event, context, callback) = > {

	// Initialize the database connection
	const connection = mysql.createConnection({ / *... * / });
	connection.connect();
  
	connection.query('... ');

};
Copy the code

The above example implements the initialization of a database connection in the saveUser function. The problem is that every time a function executes, it reinitializes the database connection, which is a time-consuming operation. Obviously this is not good for the performance of the function.

Since the execution context of a function can be reused for a short period of time, we can put the database connection outside the function:

const mysql = require('mysql');

// Initialize the database connection
const connection = mysql.createConnection({ / *... * / });
connection.connect();


module.exports.saveUser = (event, context, callback) = > {

	connection.query('... ');

};
Copy the code

This will only initialize the database connection the first time the runtime environment is started. When subsequent requests come in and the function is executed, connection can be directly used in the execution context, thereby improving the performance of subsequent higher functions.

In most cases, it is perfectly acceptable to sacrifice the performance of one request for the performance of a large number of requests.

summary

In general, the performance of the optimization function is to optimize the cold start time. All of these solutions are optimizations on the developer side, but also on the FaaS platform performance.

To sum up the above plans, the main points are as follows:

1. Choose a programming language with short cold startup time, such as Node.js/Python
2. Allocate appropriate running memory for the function
3. Perform context reuse
4. Preheat the function