It is said that the separation of front and back ends is for the front-end staff to focus on the front end and the back-end staff to focus on the back end, but if the project is relatively simple and there are only a few people in development, is the separation of front and back ends still meaningful?
Today, we have invited 4 front-end and back-end engineers of Tao System technology to share with you some of their summary of their actual experience on the front-end and back-end of small projects based on their own experience in project operation. We hope it will be helpful to you.
01 Amoy technology – inverse kwai
Whether a small project needs to be separated from the front and back ends depends on which approach can “accomplish the current business requirements in the fastest time and at the least cost.”
It doesn’t make sense to talk about this outside of a real-world scenario, after all, the choice of technology architecture needs to serve the business.
How small is a small project? How long is its life cycle? Is it a temporary system that will last for a very short time, or does it have the potential to scale into large projects in the foreseeable future? How many technicians are there to maintain this little project? What are their respective technical jobs? These are all points that need to be taken into account. Whether a small project needs to be separated from the front and back ends depends on which approach can “accomplish the current business requirements in the fastest time and at the least cost.”
We all know that the idea of separating the front and back ends is to let technicians do their jobs and improve efficiency, and that’s how it works in mature Internet companies. In the case of abundant manpower and clear technical responsibilities, the separation of the front and back ends is obviously the most appropriate choice, whether considering development efficiency, system maintainability, or system scalability. After all, with the development of Internet technology today, the front and back end are no longer capable of being handled by one person with a shuttle. There is an obvious gap between the two technologies. The front end focuses more on interaction and experience, while the back end focuses more on data and concurrency.
Of course, going back to setting, the choice still depends on the actual situation of the developers on your team. For example, if the developer has only one PHP engineer who happens to be unfamiliar with modern front-end frameworks and spends most of his time developing PHP pages with a mixture of HTML/PHP/JS, then it doesn’t make sense to force a separation between the front and back ends.
However, from the above example description, it can also be found that the situation where the front and back ends are not separated is a relatively backward mode of production. Today, in my experience, even the studio in my school is trying to complete the project through multiple technical work. Even if one person is doing multiple jobs, the code is almost always organized in a back-to-front way. Although overdesign is a taboo area in architecture, there are plenty of examples of its advantages when it comes to separating the front and back ends.
As a front-end, the Node.js Web framework contacted by the author takes the separation of front and back ends as one of the design principles. Even the classic language without separation of front and back ends — Laravel, one of the most popular Web frameworks in PHP, recommends the use of modern front-end framework vue.js to complete page development. The reason for this is that the complexity of modern front-end technology, from the engineering architecture of development to the optimization of page performance, is not well suited to being coupled to the back end.
So, our conclusion remains the same: the need for front – and back-end separation depends on which approach can “meet current business requirements in the fastest time and at the least cost.” Of course, considering the actual situation, the front and back end separation is a more universal, advanced and reasonable way.
In addition, the popular cloud integrated application development approach seems to run counter to the separation of front and back ends, but in fact the core principles are the same. With The help of Serverless, front-end engineers can get more in-depth access to data processing rights on the basis of focusing on front-end UI. To some extent, it is a more efficient way of development. As for the more back-end concurrency, capacity expansion, server operation and maintenance, the Serverless container is handled. This is also a practice of separating the front and back ends. I think, in small projects, can boldly try cloud integrated development.
Tao technology – thousands of extinction
You can view whether the front end is separated from the back end in terms of user experience, development efficiency, and operation and maintenance efficiency.
I think in most scenarios, front and back separation is better than no separation at all.
Next, I will analyze the separation of front and back ends from three main scenarios: user experience, development efficiency, and operation efficiency.
The user experience
If you are building a store ordering system, the most basic requirements for the system are a beautiful interface and fast loading. For this project focuses on the front end effect, if one project before and after using the traditional end, interface interaction, unless there is a professional front-end programmers, general server-side programmer is to realize if the front end of the complex interaction through JSP logic, and in which combined with rich and dynamic effects, the theme of the great possibility is that the UI is porsche, Developed is Charley. You can recall the style of the website 10 years ago can be imagined. In terms of loading speed, since all resources are placed on the server, there is no browser cache for the first loading, and a large number of JS, CSS and static resources need to be loaded, which is almost unacceptable today. Even if resources are placed on the Ngnix server, it is impossible to achieve extreme acceleration. If the front and back end of the use of separate development mode, the front end is responsible for the front end project, interface interaction, you can directly use the existing front end scaffolding to achieve, the industry has a special designer designed UI framework for choice, are to achieve rich dynamic effects and complex interaction, a key can be introduced. In terms of loading speed, front-end resources are separately released and deployed, which can be preheated and accelerated by CDN.
If you’re doing a user interface of a service invocation only utility class project, the basic requirement of the user of the system which is able to understand and able to operate successfully, to this kind of project focused on the service side results, if the probability is low, function, fully integrated development model can use before and after the end, the speed of light to develop on-line! One system solves all problems.
If the project is focused on front-end interaction, it is best to use the front and back end separation. If the project is focused on server-side functions, there is no complex interaction, and the front and back end integration is faster. It server is to place an order to pay the basic logic, obviously, based on traditional side before and after the integration of the JSP model to implement the complex interactions of the front page is required is very difficult, difficult is one page development, firstly developed into the JSP, HTML and then by the service end was an extremely high complexity of functionality, beautiful degree is no guarantee that more, This has high technical requirements on the front end. The second difficulty is the smoothness. The loading page of the front-end and back-end integrated project needs to be hit to the server through Nginx. If the first access does not have the stream cache, it may need to download static resources for many times. If you choose to separate the front and back ends, the front end page can be implemented directly using the existing front end scaffolding. A variety of good front end frameworks already support most OF the UI components, integrate dynamic effects, styles, and interactions, and bind the server side data set. In terms of loading speed, front-end resources can be accelerated through CDN to achieve rapid loading. Of course, if you are developing a tool-like project for internal use, with simple front-end logic and few changes, it may be more efficient to use both front and back.
For projects that focus on front-end effects, it is recommended to separate the front and back ends.
Development efficiency
Before and after the end of the integration of the project, only in the front-end interface interaction is simple and low change frequency of a slight advantage in the service project, and for projects such as the core is service, front end is just a service call entrance, just than the postman call interface transition a little bit a little bit of interface, don’t need to put in front of human, the server can be conveniently development, Using JSP in this scenario is the cheapest and most efficient.
For any project that requires front-end interface and interaction and will be iterated for a long time, no matter the size of the project, the efficiency of using the front and back end separation is higher than that of integrating the front and back end. The front and back end separation can be developed in parallel by defining service interfaces without affecting each other to achieve double efficiency. Professional people do professional things, and professional fields have more professional tools, can achieve twice the result with half the effort.
The application scenarios of front and back end integration are very limited. Any project requiring front-end interaction should be developed in a way of front and back end separation.
Operational efficiency
Before and after the end of the integration of the project, before and after the end of the complete coupling, a deployment front end can be realized at the same time online, but once the server is down, front page cannot display, affect all users, and whether the service side or front end of the iteration needs to be released, there is no guarantee that each other before and after the end, increasing the risk of iteration.
For front end separation project, comprised different before and after the application of bearing, iteration and release can be independently, completely decoupled, almost no dependence, server downtime can reduce the influence by the front-end out page interaction, separate operations greatly reduces the risk of iteration, on the front end development until now, operational tools is very perfect, cost is low, relative to a lot of risks, The cost increase brought by separate operation and maintenance can be negligible. In most scenarios, the O&M efficiency of the separated front and rear ends is higher than that of the integrated front and rear ends.
To sum up, before and after the end of the separation techniques in the current environment has been the trend of The Times, the user experience on developing efficiency and operational efficiency, leading end before and after the integration of the plan, in the depth of the Internet technology development today, industry demand for technical personnel from technology into technical depth, breadth of professional people do professional thing, so, Separation of front and back ends is still recommended even for small projects!
Amoy technology – three and a half
Actually do it Come on, the separation is quick, just try it.
First the conclusion:
Based on the existing front-end technology and o&M capabilities, it is recommended to separate the front-end and back-end even for small projects. Of course, if the technology was not mature 10 years ago, the separation of the front and back ends is also a good way to quickly put the project online.
Let’s talk about what a small project is
- Projects with short development cycles (launch in two days)?
- Short maintenance projects (this project will be used this time as an emergency, but not next time)?
- A simple project (a simple database query with no future requirements change)?
The core question is the cost of small projects, right?
My point: no matter how big or how small, in order to realize the product function is certainly not less, basic development workload difference is not large, so is the separation of front and back end operations cost comparison, the better if there is appearing operations, according to my working experience, operational cost is not too much difference.
Now, the advantages of separation
- What must be said is coupling; The front and back end separation naturally clarifies the interaction/development boundary between the two sides, and jSON-oriented data docking
- The cost of joint adjustment is greatly saved, the front and back ends can be developed in parallel, and the problem location is faster and clearer
- It has higher maintainability and is more convenient for later reconstruction
- More readable and so on
This problem is actually quite simple, some people think that small projects how simple how to, and preconceived that no separation will be faster, in fact, real practice, separation is also very fast, try to know.
Amoy technology – Munchies
The longer the project is delivered continuously, the more obvious the advantage is when the front end is separated to the later stage
This question is often determined more by whether the project needs to have a continuous delivery purpose and the length of the development cycle. The longer the project is delivered continuously, the more obvious the advantage is when the front end is separated to the later stage.
Usually the front-end and back-end focus on and solve different problems. The front-end focuses on interaction and experience, light business relationship, need to adjust the delivery ability at any time; The back-end is focused on data logic, business logic, relatively stable to determine everything.
Then whether separation is needed depends on the project delivery requirements and frequency and the degree of impact on the project.
In a real-world business scenario, front-end and back-end development is usually a better choice:
- Synchronous development reduces delivery delay risk
- Fully documented interface, reduce the cost of understanding and communication between both parties
- Understand the risks and difficulties of the project in advance, and have a clearer psychological expectation
- Maintenance, maintenance, maintenance
For the first point, on projects with more than one person, helping to gain more development time is definitely the most effective way to reduce the risk of delays. Second, the separation of the front and back ends can better solve the dependency dilemma, through a variety of tools or documentation to carry out their own development progress, most importantly, after the separation of the front and back ends, the adoption of technology is not constrained in implementation and selection. Bring convenience for later maintenance.
conclusion
In most cases, front-end and back-end separation is a more general, advanced, and rational approach. What do you think? Leave your experiences and opinions in the comments section