Preface: This article is based on the question “Is there a” structure “in the front end of 2018? The answer. It is said that there is a limited number of nuggets notebook to take, so spineless collated into an article posted. If you also like the Nuggets notebook, also send an article.

A skin

First, make clear the definition of architecture. In this question from Zhihu, the subject says that “the whole back-end architecture is very complex and huge, and a good architect needs to choose architecture from countless scheme combinations”. Architecture seems to be a matter of choosing among countless solution components.

So, if you answer the question, “There are a lot of solutions on the front end, so the architecture is troublesome,” you can answer this question. So, is there a lot of front-end solutions? That’s a lot, a lot more than the back end.

This is the tip of the ox.

I. Focus

The goals of the backend architecture, as stated by the title, are high performance, high availability, scalability, and security.

As to the back of so many knowledge points, although are useful, but unavoidable some of the book bag. There are various difficulties and aspects of high availability that need to be addressed, but the fact is that with the development of the back end over the years, especially with the emergence of massive user scenarios, the solutions to these problems are pretty clear. If it is not clear, it is also recognized by the industry that there is no solution for the time being, such as distributed CAP. As for the specific technical strategy of the specific problem encountered, if you need to start from scratch, the backend engineer (not called architect yet) should be unqualified. I understand that doing back-end architecture is basically a choice of scenarios that have been sorted out before.

What about the front end? Is the goal also high performance, high availability, scalability, and security? So as long as you don’t have to choose the database, you don’t have to choose the language, you have to choose the framework, the architecture is simple, right? I think this is a poor understanding of the focus of the front-end.

Second, the core focus of the front end — users

What is the focus of being a front end engineer? The first is the user, including the user side operation and user experience.

For example, an interface is presented to the user, such as red text or red input field? Loading on top or in the middle of the page? Is Loading displayed after the user clicks “Submit” or is it grayed out? Flip chrysanthemum or skeleton screen? Display a placeholder or a blank screen first?

For example, users can visit my website quickly or not, use it well or not, feel stuck or low. These are the things that determine whether your page is single or multi-page, how the URL is designed, what is the loading strategy?

I think those are the things that the front end should focus on.

So the architecture I did was not at all fancy. Just deciding how to make the site load faster, how not to introduce unnecessary code, how to eliminate unnecessary code, how to let the user load the least content, how to let the user see the results quickly, front-end or back-end rendering, synchronous or asynchronous output, etc.

Doesn’t feel like the architect is doing anything? But that’s exactly what front-end architects do. So, when you say that a front-end architect is a technical architect, it’s more of a user focused experience architect. From this perspective, the concerns of the front-end architect and the back-end architect are not in the same dimension.

Three, the difficulty of the project

The topic owner said, “At most, error monitoring, burying scheme, cache strategy and other partial operation and maintenance decisions”, as if these are simple things that can be done in one sentence.

Yes, backend error monitoring is not difficult, nothing more than try.. There are all kinds of operations tools that can save lives. But the front end? How do you monitor when an Ajax load fails, when a CSS load fails, or, more extreme, when the browser freezes, when the page crashes?

As for burying point, CAN do well I admire very much. You can’t even monitor when users close your page, but you want to get business and technical data through buried sites?

As for the cache, it is even more weird, whether it is cached, whether it is 200 or 304 or no request, whether it is the correct version, whether it is messed with by proxy, and how the magic browser handles the cache. Don’t think you can just say “add a cache” and get away with it. Every front-end engineer who plays caching well deserves respect. Don’t say more what localStorage/serviceWorker and so on.

By saying this, I don’t mean that front-end architects have a hard time doing this, you have to respect us. Rather, I want to say that these trivial things are not as easy as imagined. Most of the time, the architect is helping the engineer to explore the way or step on the pit and solve the technical solution of these things.

Fourth, team oriented

It is true that front-end engineering is not mature at this stage. When the architect chooses the project, he will put a considerable amount of energy on the selection of the engineering solution. Use Webpack, use NPM, use TypeScript, use ES6/7/8, use Babel, use PostCSS. Do YOU want CI? Do you want automatic packaging and publishing? Whether to subload, whether to extract CSS files…

These things may not exist on the back end, they may not exist on the client side, or if they do exist, the IDE quietly takes care of them. As a project selector, write a few dependencies and install to get started. But not the front end, where there is a lot of engineering selection or configuration/development.

As an architect, it’s also not easy to choose a good language/build tool that doesn’t pit.

Let me give you an example. You might think TypeScript is great, but why not just use it? However, TypeScript requires configuration of TSC or WebPack ts-loader (Babel now works as well), tsconfig files, and various.d.ts files. Of course, even then, it’s possible to write code with a bunch of unsolvable errors that require you to spend a lot of time figuring out why it’s done and how it’s not done (or not done at all). When you use TypeScript in Vue, you need to figure out how to make it recognize Vue Component types, and how to do auto-prompts and type checking. When you use Ajax, you’ll find that you have to figure out how to map the data returned by the server to a certain type (and then realize that it doesn’t work at Runtime).

Front-end architects, too, put a fair amount of effort into this.

Is this a good status quo? Not necessarily, but it is true. Who will carry the pot if not the architect?

Five, the summary

By architecture, I understand it to be a reasonable solution that not only supports business development but also satisfies the team by taking into account the objectives, industry and team. If this can be achieved, it is naturally a good architecture. Right now, it’s not easy to get a good architecture on the front end, and it does just as much work as the back end.

Whether the so-called architectural things that front-end architects do are great or not is another unanswered question.