Answer the question
In order to leave comments, you need to log in
How to organize the work of front-end and back-end developers?
Worked on the same project for several years. Unfortunately, there was no normal experience of working in a team, where one would separately deal with the front, and others with the back.
Now there is a need to take the front-ender into the project.
Could you suggest articles/books that describe exactly the details of interaction and work between the front and backend (the general concept is clear to me)?
For example, it is still not clear to me how to organize work on one task in terms of commits and branches.
Answer the question
In order to leave comments, you need to log in
There is not and will not be any kind of guide because each team, based on experience, technology, composition and architecture, organizes itself independently. It's trial and error
You have an api interface, and this is where you intersect. And so these are 2 different projects and one does not climb to the other.
> In terms of commits and branches.
And what will be wrong with them? They still do work that does not intersect.
back-end - provides api for the front.
Front works with this api. If there are any template engines, etc., then it depends on the technology that is used. I had experience developing as a full-stack application. There was also only a front-end, and we had a back-end on scala and it was not very convenient to insert the layout into scala templates, since without a back developer it was difficult for me to figure out what should be there, and it was difficult for him to insert what I wrote markup, since he did not always understand what should be where. We introduced such a project in different repositories so that, as a frontder, I would not accidentally break something in the scala templates and it would be easier for me to work, since compiling the template after each change to html is not a very pleasant thing. Therefore, it is important here to choose a technology that everyone would understand and give the team the opportunity to discuss,
You can also divide it into branches, try it, merge it there when it's ready
Didn't find what you were looking for?
Ask your questionAsk a Question
731 491 924 answers to any question