Front and back end separation, online copy in full swing. But is it really as amazing as the Internet claims? Or for the sake of chasing the new, for the sake of separation and separation? In fact, the projects I’ve worked on haven’t really brought me much convenience. In short, the front and back ends separate, and the person does not separate. After the separation of the front end to the previous higher requirements, only the front three swordsmen is far from enough. There’s a learning cost, and you have to deal with coupling, cross-domain stuff, so it doesn’t feel that convenient to me.
When it comes to front and back end separation, some technologies come out of the mouth, such as Spring, Vue, React, and Node, with which we can perform front and back end separation. But think about it, does technology cause separation, or does it need separation to have technology? Clearly, it’s not a chicken-and-egg philosophy.
Root of all evil JSP
Back then, our small team was mainly at the back end. As the core force of the project team, we were also doing front-end work. At that time, there were special front ends, but not many, also called “cutting graphics”, mainly to help the back end to collect some templates and processing some image resources. At that time, the front-end requirements are not high, the trend of web is not obvious, JSP is like wuling Hongguang in its car, playing an immeasurable role. The back end is also touted as a skilled position. But from the beginning of 2020, Party A gradually abnormal, the need for front-end display of things is also complex, JSP abuses are gradually amplified, template set template, jigsaw jigsaw, no specification, resulting in developers often wring. From the point of view of project management, this development mode greatly affects the efficiency of project development, how to do? Then decouple. “High cohesion, low coupling” is the eternal god. So the front end is more and more important, the market gap is also more and more big. The responsibility of the front end is gradually removed from the back end personnel and gradually forms a separate position and responsibility area. The front end also gradually begins to be engineering, modular and project-oriented like the back end.
Adult times have changed
My idea of separation should be non-reciprocal, with minimal coupling (just good communication of interface specifications). Standing in its own backend point of view, I use Java or PHP, regardless of how I achieve, the end to the front-end is just a string of negotiated interface data, can also be used for multiple types of front-end, such as Web, mobile web pages, small programs and so on. Once developed, everywhere used. From the perspective of the front end, I can get the data I need from the mock server, instead of waiting for the data from the back end. There is no question of who is waiting for who, and refuse to bicker to shorten the development cycle.
Graceful separation
Both the front and back ends are now mature and can be independently engineered. The separation of the front and back ends is not just developed on a project alone, but is instilled throughout the project lifecycle.
A normal project development usually has four stages, in fact, in “Software Engineering” more than four steps, but do not talk about the book of war, do not be poisoned by eight. Only the key parts. They are design, development, testing, and deployment.
Design stage: design includes system design (architecture design) and interface design. This includes but is not limited to databases, middleware, caching, and especially performance, capacity, and maintainability, both on the front and back ends. And the interface design is very important, it is the key part of the front and back end, including but not limited to request mode, data type, data format. A good interface design can be very good to avoid the front and rear end personnel tear B.
Development stage: develop separately, do not affect each other, minimize coupling. As said in front of the back-end development, use everywhere, the front end does not see the back-end eye, their own simulation data for independent development.
Test stage: the front end itself as a complete system, itself can carry out page jump, input, display, response and other tests. In addition to data interface testing, the back end also tests permissions, exceptions, consistency, and other issues.
Deployment phase: Independently deployable. I used webpack to pack the front-end and put it in the static directory of the back-end project. I also had to rewrite the path to solve the cross-domain problem. I always felt strange, which separated me from loneliness. The front end can be deployed separately using Nginx, which incidentally solves the cross-domain problem. Tomcat is used at the back end. Jenkins continues to post.
Whether or not to do it
A lot of talk, do or don’t do. The separation of the front and back ends is ultimately a matter of engineering considerations and project management. It’s not purely technical. Cost, manpower, development, tools, deployment, etc. Mishandling is a recipe for trouble, not convenience.
Speaking of people, the separation of front and back ends definitely requires more staff, is the cost acceptable? How much is acceptable? Is the risk of incomplete separation acceptable? It has to do with who you hire, it has to do with the project manager who takes the lead. Problems will be delayed, the extra cost is a loss.
But there are many benefits to the separation of the front and back ends
1, stand in the perspective of the enterprise. Develop a set, use everywhere, cost money in the early stage, make money in the late stage
2. From a development perspective. Free front-end, more flexible development, can develop more complex business, such as some page interaction effects, data processing. The back end is finally ready for high performance, high availability, and high concurrency. In a word: Improve development efficiency
3. Put yourself in the user’s shoes. Improved user experience, Tomcat finally does not need to load static resources, reducing load pressure. The front end can be loaded on demand according to the route configuration. The interactive experience must improve. The customer was satisfied
4. From a maintenance perspective. Better maintenance, not easy to shake the phenomenon of pot. Clear division of labor, problems can be quickly located. Compatibility problems, jump problems find the front end, data error, check problems find the back end
So you can roughly think: big projects, small projects are not divided.