1. There are two main types of front-end and back-end collaboration. One is the back-end writing interface, the front-end uses artTemplate or vue.js to render data, and the front-end and back-end are separated;
2. The other is that the project uses The back-end template engine, such as PHP's smarty or Java's freemarker, if the front-end and back-end are separated, the back-end is responsible for writing documents and performing functions, and the front-end needs to learn the usage of the back-end template engine and make modifications in the dynamic environment.
3. Mainly for the second type. In the past, the back-end was always responsible for configuring the pages. From time to time, there would be problems with the pages sent by the front-end. As a result, the front-end still needed to assemble the pages. Upgrading, the cost of joint debugging of front-end and back-end is relatively high
4. Will it be more troublesome to let the front-end integrate with the back-end template engine now? I would like to ask what the front-end and back-end collaboration is like in your company? Or a better way to collaborate
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
Our company is relatively simple and straightforward and adopts your second option.
The PHP framework is used. The front-end only needs to write the page, and then the back-end logic is processed. If you need to use
framework syntaxorphp syntaxto set pages, let the back-end staff output the rendering page (some js is also written by the back-end, and the front-end only needs to write the static page).The front-end pages can be written without any problems, and the back-end pages are generally pretty fast. If the back-end staff finds a problem with the style when rendering the view data, they submit it to the problem system (yes, we have a problem system project, which is limited to internal use and is used by front-end and back-end personnel to submit bugs), and then all front-end and back-end personnel End developers will check whether there are any problems of their own on the problem system every day and then solve them.
In fact, as long as the rules are set and everything follows the rules, the cooperation between the front and back ends will be convenient and clear.
The real front-end and back-end must be JS to get the interface data and then traverse it. If the page is changed, it must also be a front-end thing
The first is to implement the MVVM mode, which means front-end and back-end separation. The front-end does not need to master the background framework or background methods to render the page. The advantage is that the back-end code can be completely separated from the page, making maintenance easier. Moreover, the backend API interface can be used on more platforms and does not require secondary development. The disadvantage is that if the page is the homepage, it requires a lot of APIs to obtain data and render it. But the MVC architecture is much more convenient
The second way to implement MVC is that the backend is responsible for setting the logic, and the frontend is responsible for rendering the page, but the frontend must have some understanding of the templates in MVC backend development. Personally, I think this actually makes the backend more convenient and makes the frontend more difficult. Way.
The third explanation.
In fact, there is another kind of front-end and back-end work. Of course, this is an aspect that is not widely applicable to projects. For example, NODE.JS
actually mainly depends on your company's front-end and back-end configuration and project. For example, a company like ours that has one more B in the backend and one less front-end may use an MVC architecture, and the front-end rendering is handled by the backend. Of course, if you have many front-end people, the MVVM model is definitely more suitable. Of course this is just a superficial problem
This seems to be just a human problem, I think there is nothing wrong with it
Our company uses both of the two you mentioned. Regarding the first one, I wonder if your company has pulled the front-end pages out of the Java or PHP projects or are they still nested in them? If it is nested in a java or php project, it will not be troublesome if you use the front-end template engine to embed the back-end. Our company's back-end projects are all nested in java projects and are not moved out separately. I often use the front-end There is nothing wrong with the writing method of the back-end template engine. As for the second type, the cost of joint debugging is relatively high. I personally think it is not high. I don’t know under what circumstances joint debugging is more troublesome for you.
Give them a static and let them play ajax by themselves
Same as the original poster, mixed development, although there are many problems, but there is nothing you can do about it. If you don’t do it later, you can’t beat them up.
There are many ways to separate the front and back ends. Of course, the most ideal thing is to connect the front and back ends with pure interfaces, so that they will not be mixed together.
But the reality is not. For example, if the company has an existing back-end and a front-end, then you can only adjust the page in the back-end code.
Our solution is to stop the backend from moving the page.
The advantages are
1. Exclusive front-end control of the page
2. Separation of front-end and back-end responsibilities
The disadvantages are
1. Need to learn the back-end template
2. Debugging is inconvenient
3. Many front-end scaffolding cannot be used
Many domestic companies are unprofessional, there is nothing we can do about it, the environment is like this, we can only do our best
I think either there is no separation, the front-end only designs static pages, and the back-end is responsible for it;
Or the front-end and back-end are completely separated, and the back-end writes APIs, and the front-end uses jquery ajax or react or vue to call these APIs, and the page is completely written by the front-end.
In the case of complete separation, the backend must write a standardized interface, and each interface must provide clear documentation (both data instances returned by normal flows and data instances of abnormal flows! Mainly the hierarchical structure of the return value and the naming of variables) , to facilitate front-end development to use these data), when the interface changes, the document must be updated in time, and it is best to notify the front-end developer. If you don't do this, the front and back cooperation will become a mess! !
The interface document is given in the background. When the front end writes a static page, it can mock some fake data according to the interface document. Finally, wait until the interface is written to cancel the mock operation
The first type has more requirements on the front end. Page data is rendered through the connection between API interfaces, and the back end only needs to provide the interface. In this way, the division of labor is clearer, and each position only needs to do what it is good at;
The second one has more requirements on the back-end. The front-end only needs to provide static template pages, and the back-end renders data through the template framework. Some necessary effects also need to be written with some ajax and Js to achieve. When a problem occurs, joint debugging of the front-end and back-end is required.
I work in back-end PHP. Personally, if the company has more experience in front-end development and has used anglajs, ajax and other frameworks, it can use the first method, which separates the front-end and back-end. On the contrary, using the second method, the front end only needs to create static pages, and the back end will render and process the data