There are some problems ：

1. If the front and rear ends are not together , You need to deploy to the server for front-end use , If there are many problems , Then you have to upload code frequently ,run get up , A lot of time may be wasted .
2. If you work together , So it can be very convenient to communicate , It's just that communication efficiency has improved , However, the efficiency of joint commissioning has not been solved , What kind of project architecture can make the front and rear end of the project quickly conduct joint debugging of interfaces

Project framework

1. If the front and rear ends are separated , Generally, we use the front end to create a new project , Call the back-end interface in the process of writing , The project directory is as follows :
   
2. The back-end staff will also create a back-end project , Use here django give an example , The directory structure is as follows ：
   
3. The third way is to combine the two , Front end projects and back-end projects are in one , See the picture below ：
   
   above 1、2 Both of them are common development modes with front end and back end separation , The front end is responsible for the front end , The back end is responsible for the back end .
   However, the third one requires a little high level of front and back-end personnel , Front end personnel need a little django The order inside , You need to execute some commands to install some packages , You need to do some database configuration , If there is template rendering work , It will be a great test for front-end personnel , Not only the template syntax should be familiar ,model Design should also be familiar with , It is obviously very painful , But the back-end personnel also need to understand the front-end , The order to start the project , Such as yarn-server、yarn-admin( Each company may configure different commands ), As the back-end personnel, I don't want to take care of the front-end affairs , Front end personnel don't want to do back-end work , If the front-end knows a little django Back end , The back end knows a little about the front end , This mode is very convenient , The back end directly starts the front end to operate the response function , To trigger your own interface , See if there's a problem , The front end can also start the back-end services to operate the corresponding functions , To verify the correctness of the interface , The advantage is high efficiency , The bad thing is that both front and back-end personnel should have a little understanding of their respective technology stacks .

terms of settlement

The third project architecture has just been mentioned , It is also a solution in itself , But it's been tested , The front and rear end personnel still reject this mode , I'm not going to go over it here .

1. If front and back end personnel work together , Then you can access the back-end interface in the local LAN , High efficiency , If there are errors, you can modify them directly , And it doesn't take up time , Generally, we default that there is no major logic problem in the joint commissioning , Just data correctness 、 Format, etc. .
2. Not working together , Create a new code warehouse , Trust the project , Front and rear colleagues push Come down and run , If there is a problem at the back end during the joint commissioning , It can be modified and uploaded in time , Front end personnel pull Come down and verify .
3. Not working together , The project can be run remotely on a server , have access to runserver Mode for debugging , And use pycharm Connect to the remote development environment ( The synchronization function can be turned on , After local modification , The server will also change ), Subsequent deployment is also very convenient , recommend .

pycharm Remote connection server development environment address ：https://blog.csdn.net/qq_39253370/article/details/115387170