I believe that when it comes to front-end engineering, everyone has more or less their own understanding
Engineering: specification, process…
Specification: code specification, Git branch specification, component specification…
Process: interface definition, development, testing, build, release…
Many tools and platforms are involved in the r&d process
Tools: scaffolding, mock, Webpack, ESLint…
Platform: GitLab, LowCode, Web IDE…
Although involved in so many aspects, but the purpose of engineering is the same
More recently, convergence and constraint, precipitation and cost reduction and efficiency
Further, maintainability/stability/quality…
In terms of current (2019/11) common development patterns, the CLI is the hinge between developers and engineering at the tool level, and this article will talk about engineering from the perspective of CLI design
Causes and reflections
In the process of ground-to-ground engineering, everyone may have encountered some problems. The following are the two points that I have experienced deeply (of course, everyone’s experience is different and cannot represent the current situation of all companies. This paper only puts forward some thoughts from these two points).
- For historical reasons, and perhaps some companies have encountered mixed stacks, frame-specific tools such as VUe-CLI/create-react-app/Bigfish are not suitable
- “Irresponsible” appeared on a scaffold making a lot of scaffolding, but now the basic all tepid, investigate its reason, most of the scaffolding inside do not convergence, directly exposed a lot of configuration file, if the scaffolding updated, it is hard to notice to the user, this led to in all projects to be born some new engineering best practices, The cost is high, especially for some large teams, which may approach hundreds of front-end projects, which brings the problem of 1+1 < 2
Is there a solution to both of these? The answer is yes
- The NUT: Nut is more thorough in design. The micro front end is just a branch of nut technology stack fusion scene. Nut does not emphasize the concept of base/sub-application, and each NUT application can be used as a base or sub-application. Inside each NUT application is also allowed to be developed with a mixed stack. Frameless and fusion are two genes that are carved into the bone
- RDE: CLI tool for converging scaffolding, encapsulating scaffolding with Docker and masking internal implementation details
These solve part of the problem to some extent
but
- NUT has some good features, but all its design concepts need to be accepted in order to access it. Some existing projects have migration costs, but if part of NUT’s capabilities are removed instead of providing a complete set of solutions, more projects will benefit and the resistance to landing will be smaller
- RDE is missing two important engineering features: Precipitation and incubation Because the underlying too open, can’t do more granular precipitation, lack of standards also make it difficult to participate in build and in the position to students settling things down, which means that the novel engineered it classmates want to participate in, is only a one-time reverse feeding, still can’t precipitation and ground in the form of a simple best practices, but compared with the previous process, The RDE does point the way
How to design
Before we begin, what does a traditional single-layer plug-in architecture look like
A core corresponds to plug-ins, and the core provides capabilities to plug-ins
But in this particular case of engineering, we need to think about, what should core be?
The answer is not the only, grunt/gulp/webpack/rollup/parcel – bundler, build relevant alone there are so many, how much more engineering point is far more than that, such as a mock/lint and so on a series of research and development process
But if it’s just a build package for business engineering, you might say, well, webPack, there are so many people using webpack, the good model is the right one for the moment. In a horizontal comparison, WebPack really comes out on top
But here are some thoughts
- What about further customization based on WebPack? For example, wePack + Vue, a tool like VUE-CLI, tends to be more customized and efficient, but what if you need to move the technology stack to React later? Write another react-CLI, and the ecosystem accumulated on vue-CLI will be lost, and the usage will probably change if not developed by the same people
- If a better tool than WebPack comes along in the future, the cost of porting the previous plug-in architecture and the issue of smoothing the migration of old plug-ins
Q: Is Webpack easy to use?
A: Yes.
Q: Is Webpack the future?
A: Not necessarily. Just like GULP, there are always better tools. Tools are just means.
Redux has a quote on Twitter that I agree with
Don’t write modules that are too flexible because you can never predict future changes. Write modules that are easy to remove
We need to design a more general model, a single layer plug-in architecture is not well suited to business needs and future changes, we are looking for more than just today’s usability
Follow these basic principles when designing:
- We don’t believe in the permanence of something, whether it’s a tool or a frame, and we need to dig deep in some vertical area, but we don’t want to stick to one tree
- Do not expose the underlying capabilities directly to the project, exposing the underlying capabilities is “evil” for the future migration work.
This is the layered plug-in architecture mentioned in the title
In this architecture, engineering is a building, each floor has its own ecology, the lower floor can use the upper ecology, in this case, even if the lowest floor is destroyed, the building will continue to exist
(N, M, X are the number of independent plug-ins for each layer respectively)
Such ability, smart as you, should think of the concept of the medium, right, he provides the CLI medium ability, you can directly use the upper layer driver to quickly customize the engineering tools suitable for their own scenes, And you own the upper-level driver ecosystem (typically, driver-webpack, which you can customize to driver-vue/driver-react/driver-microfrontends, You can also inherit all plugins from the driver-Webpack layer.
Write in the last
Finally, what do you want your engineering to look like
Developers only need to focus on the development of the page dimension, and common processes, platforms and scenarios access are shielded at the framework level (login authentication, error reporting, performance monitoring, PC, H5, single page, multi-page, applets…).
Similar to Serverless, the end of engineering may be engineeringless, so that developers can not perceive the existence of professional tools. Web IDE is a good breakthrough in this matter. Before web IDE, CLI is the hub connecting developers and engineering in the core process of r&d. After the Web IDE, the platform can take care of this, but of course the underlying framework and specification are needed to support it