Frontend engineers have been discussing the boundaries of the frontend. The frontend development of today is very different than in the past. Currently, frontend engineers develop web pages, applets, applications, desktop applications, and even servers. Frontend engineers are constantly expanding their boundaries and exploring more fields because they want to create more value. It is best to create value by using familiar tools and methods.
The Serverless architecture gives maximum assistance to frontend engineers as they work to achieve their goals. With Serverless, you no longer need to focus on server O&M or unfamiliar fields. You only need to focus on business development and product implementation. Serverless will certainly bring great changes to the frontend development model, and frontend engineers again will play the role of application engineers. To sum up Serverless in one sentence, we could say "Less is More."
The evolution of the frontend development model consists of four main phases.
1.1 Dynamic Page Rendering Based on Templates
In the early Internet age, web pages were simple. They were static or dynamic pages for displaying and disseminating information. At that time, it was easy to develop webpages. Technologies such as Java Server Page (JSP) and Professional Hypertext Preprocessor (PHP) were used to develop dynamic templates, and then web servers were used to parse the templates into HTML files. Browsers only needed to render these HTML files. In this phase, there was no frontend and backend division, and backend engineers usually wrote the frontend pages.
1.2 Frontend and Backend Division Based on AJAX
The Asynchronous JavaScript and XML (AJAX) technology was introduced in 2005 It opened a new chapter in web development. Based on AJAX, the web could be divided into frontend and backend. The frontend interacted with pages and the backend processed business logic. The frontend and the backend exchanged data through interfaces. It was no longer necessary to write hard-to-maintain HTML using various backend languages. The complexity of web pages also shifted from the backend web server to the browser JavaScript. Therefore, the role of frontend engineers came into being.
1.3 Frontend Engineering Based on Node.js
Node.js introduced in 2009 was a historical moment for frontend engineers. At the same time, the CommonJS specification and the Node.js package manager (NPM) were also proposed. Subsequently, a series of Node.js-based frontend development tools such as Grunt, Gulp, and Webpack have emerged.
Around 2013, the first versions of React.js, Angular, and Vue.js were released one after another. Then, page-based development transitioned to component-based development. After development, tools such as Webpack could be used for packaging and building, and build results could be published through a command line tool based on Node.js. Frontend development became normalized, standardized, and engineering-oriented.
1.4 Full-stack Development Based on Node.js
Node.js is significant because it allows JavaScript, which previously ran only in browsers, to run on servers. Therefore, frontend engineers used Node.js for full-stack development and began to become full-stack engineers.
On the other hand, both the frontend and backend were developing further. Almost from the time of Node.js' birth, the backend began changing from the monolithic application model to the microservices model. This led to a divergence in the frontend and backend division of labor. With the rise of the microservices model, backend interfaces gradually became atomic. Microservice interfaces were no longer directly oriented to pages, and frontend calls became complicated.
In response, the Backend For Frontend (BFF) model was developed. A BFF layer was added between the microservices and frontend. BFF aggregated and tailored the interfaces and then output the interfaces to the frontend. The BFF layer did not assume the underlying backend tasks and was more closely related to the frontend. Therefore, frontend engineers selected Node.js to implement the BFF. This was also part of the widespread application of Node.js on the server-side.
1.5 Summary
Revolutionary technologies have driven every change in the frontend development model. First, there was AJAX, and then Node.js. So what is the next revolutionary technology? Obviously, it is Serverless.
This article discusses the evolution of frontend development model and highlights the best practices in Serverless development and function performance.
First, let's take a look at the definitions of some key terms used in this article:
Function Compute: is an event-driven service that allows users to write and upload code without having to manage server health or consider other factors. After Function Compute allocates required computing resources, it elastically runs your code. The fees of using these resources are billed based on their actual consumption. For more information about Function Compute, visit the official product page.
Fun: is a developer tool for serverless applications. It helps you manage resources such as Function Compute, API Gateway, and Log Service. You can use Fun to develop, build, and deploy resources by describing them in the template.yml file. For more information about Fun, click here.
ROS (Resource Orchestration Service): helps you simplify the management of cloud computing resources. By following the template specifications defined by ROS, you can define the collection of required cloud computing resources and their dependencies. ROS automatically creates and configures all resources to implement automated deployment and O&M. For more documents on ROS, visit the official product page.
This article shows you how you can build a SpringBoot Application on Alibaba Cloud using Function Compute and the Fun (Funcraft) tool.
Thanks to simple APIs and excellent scalability, Object Storage Service (OSS) allows applications in different scenarios to easily store several billion object files every day. The simple data access structure of key-value pairs has greatly simplified data uploading and reading. In addition to uploading and reading, a series of new application scenarios around OSS will emerge soon. Here are some examples:
The preceding three scenarios share some common challenges:
1. Long total processing time: Even highly concurrent access to OSS takes days or more to process hundreds of millions of OSS files.
2.Handling exceptions that may occur in a large number of remote calls: Generally, OSS APIs are designed to process a single file. Therefore, processing millions to tens of millions of files requires the same number of remote calls. In a distributed system, you need to handle failures in remote calls.
3. State persistence: A checkpoint-like mechanism is required to reduce the occurrence of reprocessing upon partial failure of the original processing. This helps save the overall processing time. For example, the first 10 million of processed keys are skipped in batch processing.
This article will introduce a serverless best practice based on Serverless Workflow and Function Compute (FC) to address the preceding three scenarios.
You can use Resource Orchestration Service (ROS) to model and configure your Alibaba Cloud resources. ROS boasts improved deployment efficiency, convenient architecture optimization, cost-effectiveness, and compliance control.
Many web applications are defined based on the Express framework. Conventionally, they are deployed on cloud hosts. However, you may not want to purchase cloud hosts or invest much in O&M. Function Compute is a good choice in this case. This topic describes how to use Function Compute to create a serverless web application based on Express.
ApsaraDB for Redis: In-memory Caching To Applications On The Cloud
2,600 posts | 754 followers
FollowAlibaba Cloud Serverless - August 4, 2021
Alibaba Cloud Serverless - April 7, 2022
Alibaba Cloud Serverless - August 23, 2022
Alibaba Cloud Serverless - July 17, 2023
ProsperLabs - May 10, 2023
Alibaba Clouder - February 19, 2021
2,600 posts | 754 followers
Follow
Function Compute
Alibaba Cloud Function Compute is a fully-managed event-driven compute service. It allows you to focus on writing and uploading code without the need to manage infrastructure such as servers.
Learn More
ROS(Resource Orchestration Service)
Simplify the Operations and Management (O&M) of your computing resources
Learn MoreMore Posts by Alibaba Clouder
