The Advent of Serverless Technology and Its Implications for the Front End
Senior Alibaba front-end engineer shares his thoughts on how serverless technology might just bring the front end back to its roots
Original article by Xie Huiqi谢慧琦, Staff Front-end Engineer of Alibaba Group New Retail Technology business group.
When I told my coworkers that I was thinking of writing an article about serverless computing, they gave me confused looks and said, “But Faxin — we work on the front end…” While it’s true that most front-end work does not involve the server, I could not help but notice the growing discussion online around “serverless” over the last six months.
The truth is that as someone who has been working in the front-end field for over a decade, I honestly think that serverless will prove to be one of those technologies that brings revolutionary changes to our field. So without further ado, in this article I will review the historical development of the front end, the background of serverless technology, and its implications for the front end.
It is my hope that this might prove useful for front-end engineers, or people thinking of working in the front end in future.
A Brief History of the Front End
Let’s start off by reviewing the key developments in front-end technology over the last decade and a half.
Birth of Ajax
I was still a sophomore when veteran User Experience designer Jesse James Garrett published the article “Ajax: A New Approach to Web Applications”, in which he coined the term “Ajax” to describe the asynchronous technology behind then-new services like Google Maps.
Strictly speaking, Ajax did not so much refer to a distinct technology at this point; rather, it described the philosophy behind a group of developing technologies. Now, Ajax is best thought of as package of technologies including XmlHttpRequest, rather than a new technology.
Ajax became a global benchmark of web development after being promoted by Google. One indirect consequence of this was that it promoted the popularity of rich internet applications (RIA) and single page applications (SPA), most of which offer a seamless experience through the use of partial refresh, and which have been a major part of the development of web 2.0. Now, Ajax is a deeply engrained concept in developers’ minds, making the JavaScript (JS) work at the front end much more complicated and much more important.
Division of labor has become more specialized as a consequence, indirectly promoting the place of full-time front-end developers in the workplace. Before Ajax, the field of web development did not make any distinction between the server and the browser in terms of workload. That is what makes Ajax one of the most important developments in the history of the front end.
Node.js
The next significant milestone for the front end came with the emergence of node.js in 2009.
The importance of node.js is not simply that it allows the server to be written quickly by JS at the front end. Its biggest contribution, I think, lies in the way commonJS and npm matured front-end development as a field, by affording developers a convenient and consistent development experience. It changed the mode of front-end development from one of primitive deployment that was incompatible with traditional software engineering into an R&D mode more closely resembling traditional enterprise applications.
Before node.js, front-end development lacked effective tools and standards for resource referencing, dependency management, and module specifications. With node.js’s popularity, commonJS-based and npm-based package deployment and dependency management became the mainstream (similarly to Apache Maven for Java) and a variety of CLI tools based on node.js were born to facilitate front-end development (such as Grunt and Gulp).
npm is currently the world’s largest package manager, and has become the standard tool for package dependency management in front-end projects. The emergence of webpack makes the deployment of front-end code easier, so that the front end can publish the application in the form of a java jar-like package, regardless of the types of resources used in the project.
React and the VDOM concept
The third revolutionary event for the front end was React, which emerged in 2013. Although the web components standard had been released before that, React was the library that really popularized the componentization concept. Two features of React make it the most forward-looking front-end library in history. The first is VDOM and the second is the abstraction of the UI.
Prior to React, all UI libraries were directly associated with DOM. React added an intermediate layer between the UI creation and rendering engine called VDOM, a protocol that describes the UI structure using lightweight JSON. VDOM’s significance goes beyond merely improving its own DOM diff performance; it signified that UI creation was now separate from rendering. This meant developers only needed to code once to create multiple UIs for different devices, including the server, mobile, PC or any other device that needed to display the UI. This idea of layering formed the basis for other tools like Reactive Native and WEEX.
The other forward-looking concept introduced in React is that the UI is a function (class), in the sense that a state input into a function will definitely return a certain view. Before this, most frameworks and libraries would separate the UI into an HTML fragment (usually supporting template writing to render data) and a JS that binds the HTML fragment to events. This approach may be easier to understand, but the abstraction of the UI in React’s case reflects the actual nature of the UI and, as we will see shortly, shares a lot of common ground with FAAS and serverless technologies.
React has profoundly impacted the development of frameworks and libraries that came after it and even some that preceded it. For example, Angular and Vue, which adopted many of React’s technical ideas, are two of the few technologies that have been adopted as fundamental parts of the field of front-end development.
To summarize:
· Ajax helped establish front-end development as a discreet role.
· node.js helped shape front-end development as an engineering discipline in accordance with the traditional model of development through programming languages.
· The emergence of React solved the problem of complaints from the back-end about the rapid pace of change in front-end technologies.
Serverless-like Technologies at the Front End
Although the term “serverless” was only proposed by Amazon a few years ago, the concept is not dramatically new. Here are some examples of technologies that are already implementing serverless-like concepts at the front end.
CDN
Content delivery networks (CDNs) can be seen as a forerunner to the serverless concept. Before CDN, web engineers would share JS resources and view files (either static or dynamic) via the server, meaning front-end engineers needed to interact with the server. Once CDN and return-to-source policies grew in popularity, the widespread use of engineering and building systems meant that the front end could easily send JS or static files to the CDN node. The return-to-source mechanism (i.e. from CDN back to a dynamic service) also made semi-dynamic view layer rendering possible. During this whole process, the front-end developer needs no server knowledge, nor do they need to know how many nodes are in the CDN or how to do load balancing. Developers who use GSLB do not need to know the QPS, because the CDN accommodates the numerous development resources of different services.
Containerization
From the perspective of application deployment, containerization is another serverless-like technology. After node.js became popular, developers realized that the deployment of applications and machines, and the associated operation and maintenance costs, would be a problem for the business side. This prompted the emergence of the idea of containerization. For example, Alibaba’s cloud business unit (CBU) released the NAGA container in 2015, whereby the business logic is reflected in plug-ins, while the container is responsible for the routing and dispatch of requests, as well as managing load and stability. This realizes the concept of serverless for developers on the business side in that they only need to write and upload the most direct business code, while those who maintain NAGA deal with the issues of deployment and operation & maintenance.
Page building and BFF
Page-building systems and the Backend-for-Frontend (BFF) layer are another pair of front-end related technologies that come close to the concept of serverless. They enable business developers to concentrate on business logic without needing to worry about deployment and operation & maintenance, whether via building systems like Zebra, Building block, and TMS, graph ql-based platforms, or products that let developers quickly write API gateways through web IDE, such as CBU’s Mbox.
How Serverless Will Change the Front End
Given the way the front end has developed so far and the way that serverless-like technologies are being used at the front end, I think that we are likely to see the following changes to the front end with the arrival of true serverless:
· A return from the role of front-end developer to web application engineer
· The rise of real-time server-side rendering
· A move to Web IDE as the mainstream development model
From front-end developer back to web application engineer
As mentioned at the beginning, the role of front-end developer first came about around 2007 as a consequence of the division of labor. Before this, people in similar roles were usually called web engineer or website engineer.
In the earliest stage, most web pages were rendered by the server via ASP, PHP, JSP and other server page technologies. JS was just one of the simple skills that web engineers needed to master. However, with the development of web 2.0, Internet, mobile Internet, and e-commerce, specialized staff are required to focus on writing UI with good cross-device compatibility and user experience. This led to the emergence of front-end engineers focused on the browser and mobile end.
Now, front-end technologies have stabilized after more than ten years of development. Various out-of-the-box libraries, vertical solutions, and engineering methods are at developers’ fingertips, and additional tools to generate UI code for designers’ visual drafts have also emerged. This means that front end staff can write UI and business logic at a very low cost without expending much energy on selecting, rebuilding, restoring visuals, handling compatibility, optimizing performance, debugging, and deployment.
In this situation, the separation of front and back end actually increases costs due to the necessity of coordination between the two, and because the back end ends up providing a de facto BFF layer. For example, when the back end encapsulates API gateways for the front-end representational layer, both ends are frequently left waiting for each other or end up jointly debugging the protocol. The BFF layer often does no more than a small amount of data processing, and front-end staff can learn its other roles quickly with a relatively small amount of training. So front end staff often end up getting involved with the BFF layer on the server side.
After node.js appeared, many node.js frameworks such as express emerged, and node.js also started being used in the production environment. Despite this, it is not used as widely as expected in 2019. I think this can be attributed to a lack of server knowledge at the front end due to over-specialization. node.js positioned itself as a server technology, and the problem that the server has to deal with is essentially no different from java. Very few people recruited from the front end are able to work on the server, unless you specifically recruit for node.js talent. For long-term operation, this means the server service will expose many issues, such as slow interfaces, sharp rises in core/CPU usage, memory leaks, etc. Additionally, most front-end staff do not have expertise in load balancing, scaling, or managing latency.
The essence of cloud computing is to let business development focus on business logic. Hardware and software facilities used by the business are purchased to demand on an out-of-the-box basis, while the serverless concept and related technologies frees developers from worrying about applications, hardware, and even data flow, thanks to automatic scaling. The operation & maintenance cost of the web developer will be greatly reduced in the future, freeing up front end staff to get involved in the development of the BFF layer, while the back end can focus on data processing, business logic, and algorithms.
This change is in line with the background that the R&D performance is improving. The cloud facilities of the future will be rich, professional and stable. Front-end developers will be able to quickly and cost-effectively build business logic on the cloud infrastructure. The division of labor will be less specialized on the front-end and server front-end. (To the entire request chain, the front-end is relative. Any role that is close to the customer request can make the case that it is a front-end role.) What used to be the browser front end will gradually take on work from the access layer and the BFF layer on the server side. Once this happens, we are more or less back where we started with the role of the web development engineer. This will be the biggest change to the front end.
While serverless technology means a return to the traditional web layer for front-end staff, it does not mean that front end staff will need to become experts in server-side technology. Simply mastering the operating system kernel and network programming knowledge is enough to help you write high-performing business applications with high availability.
The rise of real-time SSR
In the earliest days of web development, UI processing was primarily a matter of server-side rendering (SSR) using Perl, PHP and other dynamic web technologies. Once the front end had undertaken most UI development duties and the technical domain had gradually narrowed down to focus on the scope of the client end, the mainstream approach switched to static web pages and client-side rendering.
This approach was problematic for user experience, because it resulted in prolonged white-screen time. Because of this, with the abstraction of new front-end libraries such as React and Vue at the VDOM layer reducing the cost of server rendering, SSR has gradually gained popularity once again in recent years.
The trouble with SSR is, once again, the lack of server-side talents. Although node.js and VDOM have improved the efficiency of SSR implementation, it is rare for front-end staff to be well versed and have extensive experience in this area.
The popularity of serverless technology will eliminate this problem. With the help of serverless technology, the front-end can quickly build SSR scenarios, fetch data from the server, render on the server, and output HTML directly for the client, without worrying whether this rendering service can support the volume of data traffic or whether it will go down. The cloud services provider takes care of all that.
As mentioned above, the core idea of React is to regard the UI as a function. A page composed of multiple components is a page composed of multiple functions, and the combinations of those functions make up different browsing scenarios. If you regard a function as a micro service, a scenario is the aggregation of micro services, which is precisely the concept of FaaS.
With serverless, we can cost-effectively implement SSR to provide a better customer experience. With the help of algorithms and big data, we can even create thousands of customized UIs for different users.
Scenario-based cloud development with Web IDE
Web IDE is closely related to serverless, and many large Internet enterprises are investing heavily in it to provide their cloud infrastructure. Why? I believe that there are two reasons.
The first is that, like serverless, Web IDE is suited to application in vertical scenarios where the code is straightforward and standardized. Using Web IDE in such scenarios makes it possible to integrate with cloud platforms to implement one-click releases. This scenario is suited to providing end-to-end support for lightweight code that can be deployed instantly.
Another reason is that while current cloud facilities are good at solving problems relating to business operation, they do not address the problem of environments in software development. Many people will be familiar with the experience of cloning somebody else’s project only to find it will not start no matter how hard you work on it, because there are various environments that need installing. Another commonly encountered problem is the low efficiency of joint debugging because of the lack of some environment or other.
With the help of container technologies such as docker, software running and debugging environments can be quickly provided to others for reuse. Currently, the JS-based code editor is very powerful. The VSCode editor is based on JS and has developed the Monaco Editor library. The consensus that Web IDE is not as good as local IDE in terms of grammar prompts and IntelliSense is outdated.
Meanwhile, Web IDE offers fast platform integration, a high level of customizability, ability to interconnect with the business platform, and one-click deployment, which greatly improves R&D efficiency.
Web IDE can also solve issues caused by cross-border work, because it solves the old problem of environment preparation. You can quickly compose and deliver code at home, in the office, or even on the train.
Therefore, the future PaaS platform will be associated with a deeply customized Web IDE. When you need to write business logic, you can immediately compose code by entering the Web IDE. There is no need to pay attention to the local environment and you can achieve true envless. For example, if you want to develop a TMS module, click “Create New” and go to the Web IDE. The code will help you to initialize it. When you click “Run”, the server will start on the cloud to run the component. After you finish coding, you can publish it to TMS with one click.
It will be the same for all kinds of FaaS, API gateway systems and other cloud services. Web IDE will become a key part of the enterprise cloud infrastructure. This is already happening with AWS Cloud9 and Tencent’s coding.net, and Alibaba is catching up with aone IDE and data platform App Studio.
Conclusions
Serverless is the next big revolution facing cloud computing after Ajax, node.js and React. In one sense, it will bring the front end back to its web-engineering roots, since front-end staff will need to re-acquire some server-side skills to work with the access and BFF layers.
But in another sense, it stands placed to resolve once and for all the gap between front-end and back-end roles that has been growing in recent years. The server-side knowledge that front-end developers will have to acquire will take only a relatively minimal amount of training, while the rest of the gap will be filled by serverless, serverless-like and Web IDE technologies.
Alibaba Tech
First hand and in-depth information about Alibaba’s latest technology → Facebook: “Alibaba Tech”. Twitter: “AlibabaTech”.
