Exploration and thinking about web development models

In recent years, with the development of software and hardware technology, web development-related technologies have also advanced by leaps and bounds. Compared with ten years ago or even five years ago, both business complexity and technology selection have become completely different dimensions.

This article is an essay, which mainly elaborates on some of the author’s personal understanding and thinking about web development models.

　Foreword

　 Five or six years ago, or earlier, when talking about Web development, it mostly referred to a certain technology stack based on back-end languages, such as Java Web, Ruby on Rails, Php and other technology stacks. After the rapid development of web development-related technologies in recent years, it is now said that web development may be divided differently in different scenarios.

Typically, the so-called Web front-end, Web full-stack and other technical directions that have only been gradually subdivided in recent years were born in this environment.

　 Let’s get back to the subject, let’s talk about Web development, so what is Web development? What is the essence of Web development?

　 If we look at this issue at a relatively high abstract level, Web development is to process client requests and server responses. thing.

Around 2008, a web application or a standard model of web development. The main thing the backend does is to pull data from the database, generate html templates on the server side, and then send the generated templates to the client. . After the client receives the template, it injects js and css on the client, generates a dom tree, and then renders it into a page and presents it to the user.

　 This pattern is still used in the development of some web applications. This model is now more commonly known as the traditional development model, or the front-end and back-end hybrid development model. One of its main features is that the page template is spit out by the backend, and even the spit out template will have styles and interactions. The front end just throws the template to the browser to render it into a DOM tree to generate a page. Sometimes, the front end will also inject some js code to provide support for dynamic interaction of the page.

I have actually experienced this development model myself. In the past, when JavaEE and JavaWeb were relatively popular, we would often write a certain system, such as a student management system, a library management system, etc., and use Java to operate the JDBC link database on the server side, obtain the required data, and then combine the data with The jsp is assembled and sent to the client, and the client then hands it to the browser for rendering. Later, I also experienced the development model of PHP plus smarty. In fact, although these two methods use different technology stacks, the essence of the development model is the same.

　However, at this time we will find that the same developer will play several roles, needing to write server-side code, template layer code, and even some js and css code. This requires developers to switch between different roles. However, developers who focus on the server side often hate or are not good at writing templates, interactions and styles. At this time, a so-called page development model has been developed. The so-called page set means that the full-time front-end developer first cuts the static page, and then sends it to the back-end development to imitate and then write the template, and replace the parts that need dynamic changes with the back-end template syntax. This model has proven to be inefficient and does not dedicate appropriate application development resources.

When it comes to development efficiency, in a large-scale team collaboration, we should adhere to the idea that letting the right people do the right things, division of labor and collaboration, and assembly line operations are definitely the best solution.

Under the traditional development model, we do have some pain points that need to be solved. This led to the idea of ​​​​separating front-end and back-end development. Different types of work are only responsible for their own affairs, and then follow a certain collaboration agreement to achieve efficient output.

　The above is basically the evolution history of front-end and back-end separation.

In the front-end and back-end separation development mode, the server side gets metadata from the database, and directly spits out the data after processing, instead of a template. After the client side gets the data, it performs template rendering on the client side to generate a page and present it to the user.

Compared with the traditional development model, the server no longer handles the business of the template layer, but only provides data directly. Responsibilities are more singular. At this time, the server may provide services directly according to different business needs or architectural differences. The meaning of service here often refers to microservices. Even in some non-absolute front-end and back-end separation modes, the server will also provide template fragments.

　Obviously, under this mode, front-end development needs to do more things, and as the business grows, the amount of front-end logic and code may become larger and more complex. This has in turn promoted the emergence of various front-end frameworks, such as Angular, a large and comprehensive framework, React, a framework that focuses on solving a certain level of business, Webpack, a framework that makes up for the lack of building functions, and so on. Various frameworks themselves will drive the development of their surrounding communities, causing the entire front-end development circle to experience explosive technological development.

In addition to traditional web development, due to the rapid development of mobile Internet, mobile terminal development, WeChat development, h5 development and other fields are also accepted by front-end developers. Also, due to the rise of the NodeJS platform, front-end development may no longer be limited to browser-side development work. With the help of the NodeJS platform and frameworks such as Express and Koa, front-end developers already have the ability to get involved in server-side development.

　 Here is an article that is enough to get a glimpse of the breadth and update speed of front-end development technology stack.

Therefore, there is really a lot of content that can be discussed. This article will not be too divergent, but only discusses content related to web development. The following will focus on the discussion of web development models on the PC side, starting from the separation of front-end and back-end, and expounding the two development models I have experienced in order to inspire others.

　 Middle layer mode

As mentioned before, due to the activity of the NodeJS platform, especially the emergence of some mature server-side development frameworks, such as express, koa, etc., it is possible for front-end developers to use JavaScript to develop server-side programs. , you can even operate the database. This also opens up new work scenarios for front-end developers who have been developing on the browser side before. If they master some knowledge of databases, http protocols, network security, web servers, etc., then I personally feel that front-end developers can definitely It should be no problem to switch your role to a back-end developer and handle back-end development in some common scenarios.

　Obviously, this has put forward higher requirements for traditional front-end developers. The fields involved in their work content are more low-level than before. They will communicate with real back-end developers more frequently, and even participate in some The formulation of conventions and specifications will require us to have some back-end thinking. Otherwise, when you and others are communicating about things, you are not on the channel. How can you do that?!

　The title of this part is the middle layer pattern , so what is the middle layer model? My personal understanding is that starting from the separation of the front and back ends, with the help of the NodeJS platform, a middle layer is added between the web back end and the traditional front end (UI layer), which is responsible for processing data and templates. , business and other content. It is the bridge between the backend and UI layer. Some people like to call this middle layer the glue layer.

First of all, there may not be a clear backend here, instead it will be REST Server, Micro Service, etc. Their essence is still to provide data to the upper levels. These contents all belong to the category of backend.

　The upper layer of backend is frontend. The so-called frontend here is actually a broad reference, which represents a collection of operations such as responding to user requests and interactions. In this collection, the top layer is the user, then the client (browser) layer, and then the NodeJS layer below the client. There will also be an nginx layer.

　 In the first scenario, when a user initiates a page request, the browser will first accept the request and then pass it to nginx for proxy. nginx will forward the request to the corresponding NodeJS layer service based on the type of request. The NodeJS layer will internally parse the request forwarded from the nginx layer, execute the corresponding business class, assemble the data, and finally output an html template to the client (browser). After the browser gets the template, it injects the client's js and css code. Then render it into a page and present it to the user.

　 In the second scenario, when the user initiates an interactive request on the page, such as clicking a button to initiate a request, the request will eventually be thrown to the NodeJS layer. The NodeJS layer will process the request after receiving it, and then return the response to the browser.

Basically, most requests and interactions from the client (UI layer) will be processed in the NodeJS layer. The UI layer is isolated from the underlying REST services or microservices. Of course, there are special cases, such as picture verification code scenarios, where the browser will directly request the underlying REST service or microservice.

　Practice of the middle tier pattern solution

　Here I try to give a middle tier pattern solution sword-plus. Its positioning is not a large and comprehensive one-stop solution, but a collection of tools and the refinement of common functions for more convenient development of the NodeJS layer. Based on the Koa program, it provides functions such as logging, template rendering, request access, routing analysis, and business class abstraction. There is a certain degree of coupling between various functional components within it. Therefore, the premise of using sword-plus is to introduce NodeJS as the middle layer; the underlying framework is selected as Koa; the NodeJS layer provides templates for assembled data to the upper layer.

　Sword-plus includes the following components, Router, Pugger, Connector, Logger, Handler, and SwordError.

　Router is used to parse koa’s packaged requests. There are two main methods,

　parse, which parses routes

provider, generates business classes, and starts the business logic of corresponding routes

　Pugger is mainly used to assemble data and render Jade/Pug templates.

　The template here is a server-side template. During the rendering process, you can configure whether to record rendering logs through parameters.

　The main method render is used to assemble data to generate server-side templates.

　The rendering log will record any error messages during the rendering process.

　Connector encapsulates the request operations of NodeJS layer->REST layer, UI layer->NodeJS layer. Node-fetch is used internally. It also allows request logs to be recorded when operating requests. It has two methods,

　get, execute the get request

　post, execute the post request

　 Logger is a log component, Logger divides all logs into the following categories (category),

　fatal, error, warn, info

　 request, response, render, action

　 The first line is actually bunyan’s own log level alias, and the second line is abstracted based on different business scenarios.

　 request, the log of the rest API request sent by the NodeJS program to the REST server

response, the log of the rest api response returned by the REST server to the NodeJS program

render, the rendering log of the server-side template, the so-called rendering log here is actually the same as The client (browser) has nothing to do with it. It only represents the assembly and compilation process of template files and data. Action, all interaction logs generated by users, including page requests, form submissions, client ajax requests, etc.

　Each log is a record abstraction. Each record instance is also divided into levels under the category dimension. Commonly used levels include the following types of info, warn, and error.

　Handler is the top-level abstraction of the business class model. After all requests are parsed by Router, specific business classes will be derived through Handler. In Handler, you can use internal extension or external extension (Handler.inject) to add functional methods that can be used by all business classes. In addition, Handler proxies several suite instance objects so that they can be used in specific business classes. The following methods are provided in Handler,

　inherits. After the Router is parsed, the specific business class Clazz is generated in Router.provider through this method.

　Dispatch, perform adaptive forwarding of get and post request types in business classes.

　Inject, when the server starts, you can inject external extensions as needed. Once injected, it can be used in all generated business classes.

　 SwordError is the Error package of SwordPlus. Used to uniformly distribute errors.

Currently, the types of SwordPlus Error are as follows:

LACK_OF_PARAMETER

INVALID_OF_PARAMETER

404

ERROR_OF_MAKEDIR

SUFFIX_NOT_SUPPORT

　SUFFIX_IS_REQUIRED

　TIMEOUT

　MODULE_NOT_FOUND

　NO_TEMPLATE_FILE

Complete separation mode

So-called complete separation mode, that is, the front-end development in this mode is completely isolated from the back-end development in the traditional sense, and does not involve the development of the middle layer.

The front-end and back-end interact through ajax requests, and the back-end returns data to the front-end. All things on the client side, including page rendering, interaction, styles, routing, etc., are managed by the front end itself. At this time, front-end development often introduces a more mature front-end open source framework as the underlying selection. This development model has its unique applicable scenarios, such as Single Page Application, a management system within the enterprise, etc. If the front-end developer is familiar with the underlying framework, the development speed is often very fast. Basically, some problems encountered in actual development can find solutions in the framework community.

　 This kind of development also has its shortcomings. Often as demand iterates, the amount of front-end code will increase, and the various interactions and modular management of the front-end will become heavier and harder to maintain. Another point is that there are so many options to choose from, and sometimes you don’t know which one to choose.

My personal opinion is that you should select implementation solutions and technologies based on scenarios and needs, and don’t blindly pursue new technologies and trends. Several mainstream frameworks currently popular in the front-end circle, such as Angular, React, Vue, etc., all have their advantages and disadvantages. For example, Angular itself is an all-inclusive framework. Once you are familiar with it, the development speed is very fast. However, its entry threshold is low and it is complicated to get in-depth, and there are some scenarios for which it is not suitable. React only focuses on the processing of the View layer and provides a very good idea on how to interact and update the View and Data layers. However, its existing data state management solutions, such as Redux, personally feel that they are not very useful. . The author of VueJS has absorbed the advantages of many frameworks on the market. Personally, I feel that it is always under development. I have not used it in a production environment, so I will not comment too much.

But having said that, I personally think that the current rapid development of the front-end circle is very good. Although there are many new things and there may be many options to solve the same pain point, this does not affect us from learning from them and understanding their capabilities. Problem-solving thinking, and even experience their pitfalls. As for whether they should be used in a production environment, that is another matter, so I personally do not hate the current status quo of the front-end circle.

　 Summary

The main purpose of this article is to elaborate on some of my personal understanding and exploration of the current web development model. I personally think that the middle-tier development model in the article is a one-size-fits-all development model. In addition to what is mentioned in the article Content, I also gave some points for further exploration. I think the middle-tier development model can basically adapt to web development needs under any needs.