table of Contents
The evolution of the front-end development model
Serverless solutions provided by common service providers
Serverless-based front-end development model
Summary serverless-less is more
Spring's practice of serverless
Serverless and traditional stack
Why choose Spring and Serverless?
Detailed description: Spring Cloud features
There have been more and more discussions about Serverless recently. Serverless, which does not seem to have much to do with the front-end, has already had a deep connection with the front-end, and will set off new front-end technological changes. Based on personal understanding and summary, this sharing will discuss the front-end development model in Serverless from the front-end development model in serverless evolution, the solutions provided by common serverless service providers, and the serverless-based front-end development model.
The evolution of the front-end development model
image.png
First review the evolution of the front-end development model, I think there are four main stages. .
1. Dynamic pages based on template rendering
2. Front-end separation based on AJAX
3. Front-end engineering
based on Node.js 4. Full-stack development based on Node.js
Dynamic pages based on template rendering
In the early Internet era, our web pages were very simple, they were static or dynamic pages, the main purpose of which was to display and disseminate information. It is also very easy to develop a web page at this time. It is mainly to write some dynamic templates through JSP, PHP and other technologies, and then parse the templates into HTML files through Web Server (nginx, apache), and the browser is only responsible for rendering these HTML files. At this stage, there is no division of front-end and back-end labor, usually the back-end engineer wrote the front-end page by the way.
JSP: Java Server Page: Java server page, the page where Java code is written in html page
WebServer: website server or web server
AJAX-based separation of front and back ends
In 2005, AJAX technology was formally proposed, opening a new chapter in Web development. Based on AJAX, we can divide the Web into front-end and back-end. The front-end is responsible for the interface and interaction, and the back-end is responsible for the processing of business logic. The front and back ends carry out data exchange through interfaces. We no longer need to write unmaintainable HTML in various back-end languages. The complexity of the web page has also changed from the back-end Web Server to the browser-side JavaScript. Because of this, the position of front-end began.
Front-end engineering based on Node.js
The emergence of Node.js in 2009 is also a historic moment for the front end. Along with Node.js, there are CommonJS specifications and npm package management mechanism. Subsequently, a series of front-end development and construction tools based on Node.js such as Grunt, Gulp, and Webpack appeared.
Around 2013, the three front-end frameworks React.js/Angular/Vue.js successively released the first version. We can change from the previous development based on individual pages to the development based on individual components. After the development is completed, use tools such as webpack to package and build, and publish the build results online through a command line tool based on Node.js. Front-end development began to become standardized, standardized, and engineering.
Full stack development based on Node.js
The important significance of Node.js to the front-end is that js that used to only run in the browser can also be run on the server, and the front-end can write server-side code in the language most familiar to it. So the front-end began to use Node.js for full-stack development and began to shift from the front-end to the full-stack direction. This is the front-end actively breaking through its boundaries.
On the other hand, the front end is developing, and the back end is also developing. Around the time when Node.js was born, the back-end generally began 巨石应用模式to 微服务架构change. This has led to differences in the division of labor between the front and back ends in the past. With the rise of the microservice architecture, the back-end interface gradually becomes more atomic, and the micro-service interface no longer faces the page directly, and the front-end call becomes more complicated. So the BFF (Backend For Frontend) architecture appeared. Between the microservice and the front end, a BFF layer was added. After the interface was aggregated and tailored by the BFF, the interface was then output to the front end. The BFF layer is not the essential work of the back-end, and has the greatest relationship with the front-end, so the front-end naturally chose Node.js to implement it. This is also the reason why Node.js is currently widely used on the server side.
Jushi application: Most web projects package all the functional modules (service side) together and run them in a web container. Many enterprise Java applications are packaged as war packages.
Microservice architecture: Microservice architecture is an architectural concept that decomposes functions into discrete services, thereby reducing the coupling of the system and providing more flexible service support. Split a large single application and service into several or dozens of micro and small services, which can extend a single component instead of the entire application stack to meet service level agreements.
Next-generation front-end development model
After talking about these stages, we can see that every change in the front-end development model is due to a transformative technology. First AJAX, then Node.js. So what is the next transformative technology? It goes without saying, I personally think it is Serverless.
What is serverless
image.png
CNCF, the full name of the Cloud Native Computing Foundation (Cloud Native Computing Foundation), was established on July 21, 2015 (announced at OSCON 2015 in Portland, USA). Its initial slogan was to adhere to and integrate open source technologies to allow orchestration of containers as A part of the microservice architecture, as an important force dedicated to the promotion and popularization of cloud-native applications, it is necessary to understand whether you are a developer, manager or researcher of cloud-native applications.
At present, the industry may be more in the container Docker+Kubernetes, using
IaaS, PaaS and SaaS to quickly build and deploy applications
Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS).
Docker is a platform. It mainly provides some services. You can build, publish, and run your application on any machine with docker. Using docker saves money and time.
A brief introduction to Kubernetes. It is a mature commercial service orchestration solution. Kubernetes is positioned at the Paas layer, focusing on solving the service orchestration problem when microservices are deployed on a large scale.
In fact, Serverless has long been connected with the front-end, but we may not perceive it.
1. CDN: I believe that everyone has used CDN. After we have completed the development, we will directly deploy static files to the CDN, and use the CDN for content distribution and network acceleration. In this process, the front-end does not need to care about how many nodes the CDN has and how For load balancing, there is no need to know the QPS of the CDN. So from this perspective, CDN is a serverless implementation.
2. Another example is object storage. Just like CDN, we only need to upload files to object storage, and then you can use it directly. You don't need to care about how it accesses files and how to control permissions. Therefore, object storage is serverless for the front end. .
3. Even some third-party API services are also Serverless, because when we use them, we don't need to care about the server.
image.png
Of course, it's not enough to have a sense of body, we still need a more precise definition. From a technical point of view, Serverless is a combination of FaaS and BaaS.
Simply put, FaaS (Function as a Service) is a platform for running functions, such as Alibaba Cloud's function computing, AWS's Lambda, and so on.
BaaS (Backend as a Service) is some backend cloud services, such as cloud databases, object storage, message queues, etc. Using BaaS can greatly simplify the difficulty of our application development.
Serverless can be understood as running in FaaS, using BaaS functions.
The main features of Serverless are:
1. Event-driven ---- function In the FaaS platform, a series of events are required to drive function execution.
2. Stateless ---- because every time the function is executed, a different container may be used, and memory or data sharing is not possible. If you want to share data, you can only use third-party services, such as ```Redis``, etc.
Redis (full name: Remote Dictionary Server remote dictionary service) is an open source written in ANSI C language , supports the network, can be based on memory or persistence log type, Key-Value [database], and provides APIs in multiple languages. From March 15, 2010, the development of Redis is hosted by VMware. Since May 2013, the development of Redis has been sponsored by Pivotal.
3. No operation and maintenance-we don't need to care about the server or operation and maintenance when using serverless. This is also the core of the serverles idea;
4. Low cost-the cost of using Serverless is very low, because we only need to Pay for each function run. If the function does not run, no money will be spent, and server resources will not be wasted excessively
? ? ? ? Which company platforms provide these functions??? Existing service provider cloud platform Yama
Serverless solutions provided by common service providers
image.png
1. The above picture shows some of the current main serverless services and corresponding service solutions.
2. From bottom to top, they are infrastructure, development tools, and application scenarios.
Amazon-Microsoft-Google
3. The infrastructure is mainly provided by some cloud computing vendors, including cloud computing platforms and various BaaS services, as well as FaaS platforms that run functions.
The front-end is mainly serverless users, so for the front-end, the most important development tool layer, we need to rely on development tools for serverless development, debugging and deployment.
4. Framework (Framework)
currently does not have a unified serverless standard, and the serverless services provided by different cloud computing platforms are likely to be different, which causes our code to be unable to migrate smoothly. One of the main functions of the Serverless framework is to simplify the serverless development and deployment process, and the other main function is to shield the differences in different Serverless services, so that our functions can be used in other Serverless services without changing or changing only a small part. Can also run. Common serverless frameworks include Serverless Framework, ZEIT Now, Apex, etc. However, these are basically done by foreign companies, and there is no such platform in China.
5. Web IDE
and serverless closely related Web IDE are mainly Web IDEs of various cloud computing platforms. Using Web IDE, we can easily develop and debug functions in the cloud, and can directly deploy to the corresponding FaaS platform. The advantage of this is to avoid installing various development tools and configuring various environments locally. Common Web IDEs include AWS's Cloud9, Alibaba Cloud's functional computing Web IDE, and Tencent Cloud's Cloud Studio.
6. Of course, the most important development method at present is to develop locally. Therefore, it is also essential to develop serverless command line tools locally.
There are two main types of command-line tools. One is provided by cloud computing platforms, such as AWS's aws, Azure's az, and Alibaba Cloud's fun; and the other is provided by the serverless framework, such as serverless and now.
Most of the tools, such as serverless, fun, etc., are implemented in the Node.js language.
7. Application scenarios
On the layer above the development tools, there are some vertical application scenarios of Serverless. In addition to using traditional server-side development, currently serverless technology is also used for small program development, and the Internet of Things (IoT) may also be involved in the future.
Comparison of different serverless services
image.png
The above figure compares different serverless services in terms of supported languages, triggers, and prices. It can be found that there are differences and commonalities.
1. For example, almost all serverless services support languages such as Node.js/Python/Java.
2. From the perspective of supported triggers, almost all services also support triggers such as HTTP, object storage, timing tasks, and message queues. Of course, these triggers are also related to the platform’s own back-end services. For example, Alibaba Cloud’s object storage triggers are triggered based on events such as the access of Alibaba Cloud’s OSS products; while AWS’s object storage triggers are based on Triggered by AWS's S3 event, the two platforms are not common. This is also a problem currently facing Serverless, that is, the standards are not uniform.
S3: Amazon Simple Storage Service (Amazon S3) is an object storage service that provides industry-leading scalability, data availability, security and performance
From a billing point of view, the fees for each platform are basically the same. As mentioned earlier, serverless billing is based on the number of calls and the execution time.
Serverless-based front-end development model
serverless development process
image.png
1. Before starting a specific case, take a look at the traditional development process.
In the traditional development process, we need the front-end to write the page and the back-end engineer to write the interface. After the back-end has written the interface, the interface is deployed, and then the front-end and back-end joint debugging is carried out. Test and go online after the joint debugging is completed. After going online, operation and maintenance engineers are required to maintain the system. The whole process involves many different roles, the link is long, communication and coordination is also a problem.
2. Based on Serverless, the back-end becomes very simple. In the past, back-end applications were split into functions. You only need to write the functions and deploy them to the Serverless service. You don’t need to care about any server operation and maintenance in the future. . The threshold for back-end development has been greatly reduced. Therefore, all development work can be completed with only one front end.
Of course, if the front-end is based on Serverless to write the back-end, it is better to have certain back-end knowledge. Involving complex back-end systems or scenarios where Serverless is not applicable, back-end development is still required.
The value of serverless
1. Reduce operational complexity
Serverless architecture decouples software applications and servers, and servers are no longer the focus of user development and operation of applications. Before the application goes live, users no longer need to plan the number and specifications of servers in advance. In the operation and maintenance process, users no longer need to continuously monitor and maintain the status of specific servers, but only need to care about the overall status of the application. The overall complexity of application operations decreases, and users can focus more on the experience and improvement of software applications and other areas that can bring higher business value.
2. Reducing operating costs
Servers are no longer a managed resource that users pay attention to. The complexity of operations is reduced, and the time and manpower required for application operations will be greatly reduced. In the best case, a few application administrators can manage an application system that handles massive requests.
3. Shorten the time to market of the product.
Under the serverless architecture, the functions of the application are decomposed into several fine-grained stateless functions, the boundary between functions and functions becomes clearer, and the coupling between function modules is greatly reduced . This makes the development of software applications more efficient and the iterative cycle of application development is shorter.
serverless practice
Serverless-based BFF (Backend For Frontend)
image.png
Traditional BFF (Backend For Frontend) architecture
1. On the one hand, different APIs need to be used for different devices. On the other hand, due to the complexity of front-end interface calls caused by microservices, the front-end began to use BFF to aggregate and tailor the interfaces to obtain an interface suitable for the front-end .
2. The bottom layer is a variety of back-end microservices, and the top layer is a variety of front-end applications. Before microservices and applications, it was BFF, which was usually developed by the front-end.
-Mobile terminal-web terminal-embedded-
such an architecture solves the problem of interface coordination, but it also brings some new problems.
Pain points of traditional BFF (Backend For Frontend)
For example, developing a BFF application for each device will also face some repeated development problems. Moreover, in the past, the front-end only needed to develop the page and focus on the rendering on the browser side, but now it needs to maintain various BFF applications. In the past, the front end did not need to care about concurrency, but now the pressure on concurrency is concentrated on BFF. Generally speaking, the operation and maintenance cost is very high, and the front-end is usually not good at operation and maintenance.
Serverless can help us solve these problems. With Serverless, we can use functions to implement aggregation and tailoring of various interfaces. The request initiated by the front-end to BFF is equivalent to an HTTP trigger of FaaS, which triggers the execution of a function. This function implements the business logic for the request, such as calling multiple microservices to obtain data, and then returning the processing result To the front end. In this way, the pressure of operation and maintenance has shifted from the previous BFF Server to the FaaS service, and the front-end does not need to care about the server anymore.
Serverless-based BFF architecture
The picture above is based on the Serverless BFF architecture. In order to better manage various APIs, we can also add a gateway layer to manage all APIs (such as Alibaba Cloud's gateway) through the gateway, such as grouping APIs and sub-environment. Based on the API gateway, the front end does not directly execute the function through HTTP triggers, but sends the request to the gateway, and then the gateway triggers the specific function to execute.
API Gateway
in the API Gateway is not as unified export situation, the caller needs its own portfolio of services, but also easy to let the caller sense the presence of a variety of back-end services, the individual needs of each do a lot of the same work.
After joining the API Gateway,
routing, security, current limiting, caching, logging, monitoring, retries, fusing, etc. will be placed on the API gateway to do the role, and then the service layer will be completely separated from these things and purely do business. It can also ensure that the business code is clean, without worrying about safety, pressure, and other issues.
Serverless-based server-side rendering
Traditional server rendering
Based on the three most popular front-end frameworks (React.js/Anguler/Vue.js), most of the current rendering methods are client-side rendering. When the page is initialized, only a simple HTML and the corresponding JS file are loaded, and then JS will render each page. The main problem with this approach is the white screen time and SEO search engine optimization
In order to solve this problem, the front-end began to try server-side rendering again. The essential idea is actually the same as the earliest template rendering. The front-end initiates a request, and the back-end Server parses out an HTML document, and then returns it to the browser. It's just that in the past it was a template for server-side languages such as JSP and PHP, but now it is a homogeneous application based on React, Vue, etc. This is also the advantage of today's server-side rendering solution.
However, server-side rendering brings some additional problems to the front-end: operation and maintenance costs, and the front-end needs to maintain a server for rendering.
Server-side rendering based on serverless
The biggest advantage of Serverless is that it can help us reduce operation and maintenance. Can Serverless be used for server-side rendering? Of course it is also possible.
In traditional server-side rendering, each request path corresponds to each server-side route, and the route implements the rendering of the HTML document corresponding to the path. The server-side programs used for rendering are these applications that integrate these routes.
Using Serverless to do server-side rendering is to split every previous route into a function, and then deploy the corresponding function on FaaS. In this way, the path requested by the user corresponds to each individual function. In this way, the operation and maintenance operations are transferred to the FaaS platform, and the front-end is used for server-side rendering, so there is no need to care about the operation and maintenance deployment of server-side programs.
Serverless-based small program development
1. At present, the scenario where serverless is used more in China may be developed by Xiaocheng. The specific implementation is the cloud development of applets. Both Alipay applets and WeChat applets provide cloud development functions.
2. In the traditional small program development, we need the front-end to develop the small program; the back-end to develop the server. The back-end development of the applet is essentially the same as other back-end application development. It needs to be concerned with a series of deployment operation and maintenance operations such as application load balancing, backup redundancy, monitoring and alarming. If the development team is very small, you may also need the front-end to implement the server.
But based on cloud development, developers only need to focus on the realization of the business, and a front-end can complete the front-end and back-end development of the entire application. Because cloud development encapsulates the back-end as a BaaS service and provides the corresponding SDK to developers, developers can use various back-end services like calling functions. The operation and maintenance of applications has also been transferred to service providers that provide cloud development.
The following are some examples developed using Alipay Cloud. The function is the function defined in the FaaS service.
Load balance means to distribute to multiple operation units for execution, such as Web server, FTP server, enterprise key application server and other mission-critical servers, etc., so as to jointly complete work tasks.
Backup redundancy: just to prevent occurrence A backup taken for the loss of data due to damage to storage devices caused by natural or social destruction.
General serverless architecture
Based on the above several serverless development examples, a general serverless architecture can be summarized.
image.png
The bottom layer is the backend microservice (Backend) that implements complex business. Then the FaaS layer implements business logic through a series of functions and directly provides services for the front end. For front-end developers, the front-end can implement server-side logic by writing functions.
At the same time, whether it is on the back-end, FaaS or front-end, we can call the BaaS service provided by the cloud computing platform, which greatly reduces the difficulty of development and reduces the cost of development. Cloud development of applets is an example of invoking BaaS services directly on the front end.
Summary serverless-less is more
With Serverless, we don't need to pay too much attention to the operation and maintenance of the server, and we don't need to care about the areas we are not familiar with. We only need to focus on business development and product realization. There are fewer things we need to care about, but there are more things we can do.
Spring's practice of serverless
Spring's practice of Serverless is mainly Springboot and Spring Clound based on Springboot.
Serverless
Serverless applications take advantage of modern cloud computing capabilities and abstractions, allowing you to focus on logic rather than infrastructure. In a serverless environment, you can focus on writing application code, while the base platform is responsible for scaling, runtime, resource allocation, security, and other "server" details.
What is serverless?
Serverless workloads are "event-driven workloads that have nothing to do with the aspects typically handled by server infrastructure." Questions such as "how many instances to run" and "what operating system to use" are all governed by the function-as-a-service platform ( Or FaaS) management, so that developers can freely focus on business logic.
Serverless features?
Serverless applications have many specific characteristics, including:
- Event-driven code execution with triggers
- The platform handles all the chores of starting, stopping and zooming
- Scale to zero, cost as low as zero when idle
- no status
Serverless and traditional stack
Service as a Service (FaaS)
- Event-driven execution.
- Developers delegate all server-specific tasks to the FaaS platform.
- Developers only write business logic called by the platform, so that they can expand requirements more flexibly as business requirements change.
Traditional application
- The server infrastructure must be maintained (installation, configuration, patching, upgrades, etc.).
- The way the infrastructure scales may not be dynamic enough for the workload (wasting resources).
- Developers write integrated code to handle messaging platforms, HTTP requests/responses, etc.
Why choose Spring and Serverless?
The Spring product portfolio provides a powerful collection that can be used in serverless applications. Whether to use Spring Data , the enterprise integration mode with Spring Integration , or the latest reactive programming with Spring Framework and Project Reactor From day one, Spring enables developers to improve work efficiency in a serverless environment.
Spring can also help your functions avoid vendor lock-in. The adapter Spring Cloud feature provided by the platform allows you to be separated from vendor-specific APIs when running code on the platform.
Detailed description: Spring Cloud features
The features provided by the Spring Cloud feature enable Spring developers to take advantage of serverless or FaaS platforms.
java.util.functionThe software package from the core Java is the foundation of the programming model used by Spring Cloud Function. In short, Spring Cloud Function provides:
- Choice of programming style: reactive, imperative or mixed.
- Functional composition and adaptation (for example, combining imperative functions with reactivity).
- Supports reactive functions with multiple inputs and outputs to enable function processing to merge, join, and other complex stream operations.
- Transparent type conversion of input and output.
- Deployment packaging features specific to the target platform (such as Project Riff, AWS Lambda, etc.; see below).
- Functions with flexible signatures (POJO functions)-"If it looks like a function, then it is a function"
- All other benefits of Spring idioms and programming model.
Spring Cloud Function provides adapters so you can run functions on the most common FaaS services, including Amazon Lambda , Apache OpenWhisk , Microsoft Azure and Riff projects .
SpringBoot quick start: https://spring.io/quickstart
package com.example.demo;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestParam;
import org.springframework.web.bind.annotation.RestController;
@SpringBootApplication
@RestController
public class DemoApplication {
public static void main(String[] args) {
SpringApplication.run(DemoApplication.class, args);
}
@GetMapping("/hello")
public String hello(@RequestParam(value = "name", defaultValue = "World") String name) {
return String.format("Hello %s!", name);
}
}