In the context of serverless, some "front-end engineers" will be transformed into "application delivery engineers"

The source of this article is the public number: Programmer succeeded

Hello everyone, my name is Yang Chenggong.

This is my first article of 2022. I have been thinking about what to write about. Since it is the new year and the new year is new, is it more appropriate to write about the idea of technical outlook? So the title of this article, which is the core idea of this article, came out:

the context of Serverless, some "front-end engineers" will become "application delivery engineers"

There are three nouns here:

• Serverless
• Front-end engineer
• Application Delivery Engineer

Let's talk about my outlook for the front end of 2022 from these three aspects.

Serverless

What is Serverless?

From the meaning alone, it is very obvious that has very few services.

I think this is a good understanding. Because now everyone's translation of Serverless is No service, is there really no service? No, let's take a look at its specific concept first:

[Red Hat] Serverless is a cloud-native development model that allows developers to focus on building and running applications without managing servers.

Can not understand? Translate the vernacular. That is to say, the previous services, such as the interface applications to be connected to the front end, are to be deployed on the server. For back-end students to develop a set of interfaces, they must first apply for a server, then deploy the application on this server, and use the domain name to resolve it before they can give the front-end interface URL address for the front-end to call.

But after the emergence of Serverless, even if there is no server and do not understand operation and maintenance, it becomes possible to deploy applications online.

The key point is: can deploy the application without a server.

How to deploy it? Let's take a look at the two forms of Serverless:

• BaaS : The full name Backend as a Service , translated as backend as a service.
• FaaS : The full name Function as a Service , translated as function as a service.

BaaS refers to a server-side application, also known as a cloud application. For example, our commonly used Alibaba Cloud cloud database and object storage belong to BaaS. In fact, whether it is a database or static resource storage, we can build it on the server by ourselves. But because of products like cloud database , we can bypass the server and use a cloud database directly.

This is the first layer concept of "no server": desalinates the server and directly contacts the server application .

Note: here is toned down server, not really no server . It's just that the cloud vendor has abstracted and encapsulated the server, and the application is directly exposed to the developer, so it seems to be no service to the developer.

BaaS is most widely used in the back-end, because many back-end infrastructures (such as databases, logs, etc.) do not need to be built manually. With the stable support of cloud vendor standards, you can concentrate on business logic.

But with the rapid development of the front-end and the cloud-native nature of the back-end, some whimsical bigwigs think so: "The front-end calls the back-end interface, and all requests are initiated in a function of the front-end, so it is inevitable that The back-end needs to provide an interface service. Can we directly deploy this function on the cloud and turn it into a cloud function for direct use by the front-end, so we don’t need the back-end interface?”

The big guy slapped his thigh, this idea turned out to be so wonderful. If you do this, won't the front end turn over as a serf and sing? So the big guys continued less server so FaaS appeared.

FaaS is a function-oriented way of building and deploying software, that is, cloud functions. FaaS is another upgrade to BaaS. On the basis of desalinating the server, desalinating the application and directly exposing functions to the front end. In the past, our front-end functions were all locally declared and called locally. Now cloud functions are deployed separately on the cloud for our front-end remote calls.

This is the second layer concept of "serverless": fade server, fade application, direct contact function

In fact, it was only when Serverless developed to the FaaS stage that it really had a transformative impact on the front end.

Front-end engineer

What is a front-end engineer?

In the early years, front-end engineers were more like "page engineers". Most people's work was to use the "troika" to make a design map into a web page. Until now, there are still many back-end developers who have the impression of the front-end.

But in recent years, everyone has found that front-end engineers seem to have been "outbound" and constantly expand their boundaries. Although he still wears the hat of "front-end engineer", his work has long gone beyond the traditional front-end category.

From the perspective of "expanding the boundary", it can be roughly divided into two directions:

• Forward: Relying on Product and Design
• backwards: relying on back-end and operation and maintenance

Moving forward, some front ends start to think more about "why" about what they are doing?

In the past, the product was determined to the design drawing, and the front end only needed to restore the design drawing. This is ideal, but the actual situation is that in some places the product and design cannot be considered, and it is found that it is not feasible when it is implemented in the front end, so it can only "change the demand" or "replacing it", which is the most disgusting thing in the front end.

When this happens, it will force the front-end people to think: Is the page design of reasonable? Are there any problems with interaction? If there is a problem with , then we will not answer this demand, and we will go back to the product and make it clear. This greatly reduces the useless work of the front-end, improves the development efficiency, and gradually cultivates the product thinking of the front-end.

In addition to product thinking, the front-end is also thinking about how to make it easier to turn "pictures" into "codes" at the design level. So in recent years, there have been many schemes for converting design drawings to code, such as Blue Lake, and Ali's imgcook . These practical solutions allow an application to have a front-end shadow from the very beginning of its design.

The performance of backward development is typically the ultra-lightweight framework represented by Express after the emergence of Node.js. Because it is relatively simple and JS language, it has set off a wave of "full-stack development" in the front-end circle. This is not without reason. Some small applications are suitable for writing in Node.js, and they are fast and efficient.

But in some large production applications, the front end is out of reach. Especially after the emergence of cloud native, the threshold of the back-end has risen. I believe that there are many excellent front-end engineers who use Node.js to connect to a database and write some business logic interfaces. There is no problem at all. But if you are asked to engage in some back-end advanced games and do some server operation and maintenance, you may not be able to fix it.

Which are considered advanced? I saw a very interesting description of the back-end boss on the Internet before. Here's what it said: high concurrency on the left, high availability on the right, middleware on the top, microservices on the foot, and cloud-native . This is the full battle of the boss. First.

So you see, the rear wall is high, blocking the front end, which is trying to stab across the door. So far, the back-end has been deeply cultivated, and the front-end has also found its own direction through continuous attempts. Everyone does things in their own fields without entanglement with each other.

But after the emergence of Serverless, especially FaaS, this balance has begun to change subtly.

Application Delivery Engineer

What is an "Application Delivery Engineer"?

First of all, let me state that this is not an official concept. It was born when I was thinking about the backward development of the front end.

As we mentioned above, the traditional front-end engineer's responsibility is to turn the design into a web page, but with the emergence of Node.js, the front-end has more opportunities to contact the back-end. For some small applications, some excellent front-ends can complete the front-end and interface by themselves, and then go online without the need for back-end participation.

We can call this group of people "full stack engineers". The so-called full stack is either one end is deep and the other is shallow, or both ends are shallow (of course, super big cows ignore it), so it is OK to develop small applications, but there is no full stack for large production applications.

Now, with the advent of serverless cloud functions, the server and back-end applications are shielded, which greatly reduces the threshold for back-end development. The front-end seems to see hope again. We can realize the back-end development of production applications without writing interfaces, but only need to write cloud functions.

There used to be high walls, and the front end could not be rolled in. Now that the wall is demolished, do you think we can't get in?

A typical example is WeChat applet cloud development. The front end writes cloud functions on the WeChat developer tool, and uploads and deploys with one click. Then obtain and call this remote function in the applet code, which is equivalent to implementing self-debugging at the front and back ends of the entire process until the application development is completed. This is a classic example of a "front-end engineer" turning into an "application delivery engineer".

Using serverless cloud functions can not only easily implement back-end business functions, but also monitor, concurrency, and load, which are implemented uniformly by cloud vendors. Therefore, the stability and reliability are also very guaranteed.

Another point is that at present, it may be a problem of everyone's concept. They think that a separate cloud function service needs to be paid by oneself, and it is better to deploy the application directly on the cloud server. In fact, function computing is billed according to the number of calls and access traffic, which saves resources and money than cloud servers.

I think this concept will be gradually released in 2022 under the promotion of big manufacturers, and more and more web applications will also be connected to serverless, so more front-end development engineers will become application delivery engineers.

In the past, in order to realize some of your own ideas in the front-end, you must have the interface of the back-end, and you also need the help of the back-end or operation and maintenance to deploy online. But not now, we have a chance to do it all ourselves. I think this is a huge opportunity for the front end, a good opportunity to directly produce an application from the product and your own ideas.

In addition to this, the collaboration model on the front end may also change. In a previous large application, the front-end group was developed in sub-modules. But now with Serverless, coupled with the micro-frontend that has gradually matured last year, the front-end collaboration model is likely to change from "one module, one module development" to "one application, one application development" , this is a very cool thing thing.

There is also the product thinking cultivated when expanding forward. The front-end may be the person who understands the entire application best in the future, so there is no need to say more about the prospects.

Come on, front-end folks! In 2022, I wish everyone a promotion and salary increase, and a new peak!

i want to learn more

In order to better protect the originality, this article will first publish the WeChat public front-end . This official account only does original work, at least one high-quality article per week, and the direction is practice and thinking such as front-end engineering and architecture.

In addition, I also set up a WeChat group to provide exchanges and learning for students who are interested in this direction. If you are also interested, please add me on WeChat ruidoc to pull you into the group~