“What will be hot and what to learn in 2022? This article is participating in the” Talk about 2022 Technology Trends “essay campaign.

Hello, I’m Yang Chenggong.

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

In the Serverless context, some of the “front end engineers” will become “application delivery engineers”

Here are three nouns:

  • Serverless
  • Front End engineer
  • Application Delivery Engineer

Here are my visions for the 2022 front end from those three perspectives.

Serverless

What is Serverless?

By definition, it is obvious that there are very few services.

I think that’s a good understanding. Because now everyone’s translation of Serverless is no service, really no service? Not really. Let’s take a look at the concept:

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

Don’t understand? Translate it in plain English. That is to say, the old services, such as our front-end interface applications, are deployed on the server. The back-end students want to develop a set of interfaces, first of all, to apply for a server, and then deploy the application to the server, using the domain name resolution, to give the front-end interface URL address, for the front-end call.

However, with the advent of Serverless, it is possible to deploy applications online even without a server and no knowledge of operation and maintenance.

The key is this: you can deploy applications without a server.

So how do you deploy it? Take a look at the two forms of Serverless:

  • BaaSFull name:Backend as a ServiceBack end as a service.
  • FaaSFull name:Function as a ServiceFunction as a service.

BaaS is a server application, also known as a cloud application. For example, the cloud database and object storage of Ali Cloud, which we commonly use, belong to BaaS. In fact, whether it is a database or a static resource store, we can set up our own server. But with products like the cloud database, we can bypass the server and use a database in the cloud.

This is the first layer of the “no service” concept: downplay the server and go straight to the server application.

Note: this is desalination server, not really no server. It’s just that cloud vendors have abstracted and encapsulated the server, exposing it directly to the application, so it’s like no service to the developer.

BaaS is most widely used in the back end, because the back end of many infrastructure (such as database, log, etc.) do not need to build manually, with the cloud vendor standard stable support, you can focus on the business logic.

But with the rapid development of the front end, and the cloud protogenics of the back end, some people think that: “The front end calls the back end interface, all in a function of the front end to initiate a request, so that the back end must provide an interface service. Can we just deploy this function in the cloud, make it a cloud function, and use it directly on the front end, so we don’t need the back-end interface?”

Big guy a clap thigh, this idea unexpectedly so wonderful. Wouldn’t the front end have to turn over and sing to the serfs? So the big guys moved server to less, and FaaS emerged.

FaaS is a function-oriented approach to building and deploying software, known as cloud functions. FaaS is another upgrade to BaaS, in which the server is downplayed and the application is downplayed, exposing functions directly to the front end. In the past, our front-end functions were declared locally, called locally. Now cloud functions are deployed separately on the cloud for our front-end to call remotely.

This is the second concept of “no service” : play down the server, play down the application, and touch the function directly.

In fact, it wasn’t until the FaaS stage that Serverless really had a transformative impact on the front end.

Front End engineer

What is a front-end engineer?

In the early days, front-end engineers were more like “page engineers,” and most of them worked on a “troika” of designs to make a web page, which is how many back-end developers still think of the front end.

But in recent years, it’s been found that front-end engineers have been “rolling in” and pushing the boundaries. Although still a “front-end engineer” hat, but do things already beyond the traditional front-end category.

From the perspective of “expanding boundaries”, there are roughly two directions:

  • forward: Rely on product and design
  • backward: Back end and operation and maintenance

Moving forward is when part of the front end starts thinking more about what it’s doing, “Why?”

In the past, the product was determined to the design drawing, and the front end only needed to restore the design drawing. Ideally, this is true, but the reality is that in some places the product and design are not considered, and when it comes to the front end, it is found that it is not feasible, so it has to “change the demand” or “tear down and start from scratch”, which is the most annoying thing for the front end.

This situation, will force the front end they had to think: this page design is not reasonable? Any questions about interaction? If there is a problem, we will not accept this demand, and the product will be clarified first. This greatly reduces the front end of the useless work, improve the development efficiency, but also gradually cultivate the front end of the product thinking.

In addition to product thinking, the front end is also thinking about how to make it easier to turn “graphics” into “code” at the design level. That has led to a number of code-to-design schemes in recent years, like Blue Lake and ImgCook. These practices make an application a shadow of the front end from the beginning of design.

The performance of backward development is typical after the emergence of Node.js, the ultra-lightweight framework represented by Express, because it is relatively simple and js language, has set off a wave of “full stack development” in the front end circle. This is not for nothing, some small applications are just good for 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 back end of the threshold dawdling up. I’m sure there are a lot of good front-end engineers out there who can use Node.js to connect to a database and write some business logic interfaces without a problem. But if you do some advanced back-end gameplay, do some server operations, you might not be able to do it.

Which are advanced? Before I saw the description of the backend big guy on the Internet is very interesting, it is so said: the left hand high concurrency, the right hand high availability, overhead middleware, foot micro services, embrace cloud native, this is the big guy’s full armor.

So, you see, the back wall is high enough to keep out the front end, which is trying to get in the way. At this point, the back-end ploughed deeply, and the front end also found its own direction in continuous attempts. We each did things in our respective fields without entwine.

But with the advent of Serverless and especially FaaS, the balance began to shift subtly.

Application Delivery Engineer

What is an Application Delivery Engineer?

First of all, this is not an official concept, it came to me when I was thinking about the front end and the back.

As we mentioned, the traditional front end engineer’s job is to make the design into a web page, but with node.js, the front end has more access to the back end. For some small applications, a good portion of the front end can complete the front end and interface on its own, and then go live, with no back-end involvement.

These people are what we might call “full-stack engineers.” The so-called full stack is either deep at one end and shallow at the other, or shallow at both ends, so developing small applications is fine, but large production applications are not.

Now, with the advent of Serverless cloud functions, the server and back-end application parts are shielded, making back-end development barriers significantly lower. The front end seems to see hope again, we can not write interfaces, just need to write cloud functions, but also to achieve back-end development of production applications.

There used to be high walls, you couldn’t get in at the front. Now that the walls are down, you don’t think we can get in?

The typical example is wechat small program cloud development. The front end writes cloud functions on wechat developer tools, upload and deploy with one click. This remote function is then obtained and called in the applet code, which is equivalent to the whole process of implementing their own debugging, until the application development is complete. This is a classic case of “front end engineer” turning into “application delivery engineer”.

Serverless cloud functions can not only easily realize back-end business functions, but also monitor, concurrency and load are unified by cloud vendors. Therefore, the stability and reliability are also very guaranteed.

There is another point, which may be a problem of people’s perception at present, thinking that a separate cloud function service needs to be paid, it is better to deploy the application directly on the cloud server. In fact, function calculation is based on the number of calls, access traffic billing, more resources and money saving than the cloud server.

I think this concept will be gradually opened up in 2022 under the promotion of big factories. More and more Web applications will be connected to Serverless, so more front-end development engineers will be transformed into application delivery engineers.

In the past, if the front end wanted to realize some of its own ideas, it had to have the interface of the back end, and also needed the help of the back end or operation and maintenance to deploy online. But not anymore. We have a chance to take care of this ourselves. I think this is a huge opportunity for the front end, a great opportunity to take your product and your ideas and directly produce an application.

In addition, the collaboration model on the front end may also change. Before a big application, the front end group was developed in modules. But now with Serverless, and with the micro front end that has matured over the last year, the front end collaboration model is likely to change from “module by module” to “application by application”, which is pretty cool.

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

Come on, front-end guys! In 2022, I wish you all a promotion and salary increase, and then climb to new heights!

I want to learn more

In order to better protect the original, this article will be the first wechat public number front-end woodcutter. This public account only does original work, at least one high quality article per week, the direction is front-end engineering and architecture practice and thinking.

In addition, I also set up a wechat group for students who are interested in this direction to communicate and learn. If you are also interested, please add my wechat ruidoc to pull you into the group ~