How to divide the backend and frontend in complex web applications?

How to divide the backend and frontend in complex web applications?

For example, developed complex applications using django, symfony or other frameworks. For frontend uses angularJS for example. The interaction should be completely separated should be? For example, using the REST API? Or vjushkah to connect Angular to each application? Interested in how to make a standalone application and as front-end developers develop the presentation independently of the backend developers in production in the development of complex projects.
July 2nd 19 at 17:13
5 answers
July 2nd 19 at 17:15
SPA - fully self-contained application, and therefore to make this stuff in a separate repository - quite a normal decision. Analogy - the development of mobile applications and the backend for that meter. To conduct such development in one repository will be at least uncomfortable.

And if mobile apps are all clear, the frontend can be muddied. For example, you want to make a login page just for Symfony/Django, and then you can redirect already in the SPA after having obtained the authentication token.

again, I don't see any problem in that case keep everything in different repositories and use the frontend as a dependency to backend (that would have assembled the front-end application is connected).

or even more interesting. Some preload data. For example, we may want saillant in html some data that generates the backend. Ensure that this data is available to the client before to load angular. In this case again, we can generate an entry point with the help of ready-made html template, supplied to us from the frontend and forces some twig/jninja insanity json in the body of the page:

function data() {
 return {{data | json}};
}


But it's sooooo rare cases.
Did not SPA single page aplicacin ? - Kayley.Lueilwitz62 commented on July 2nd 19 at 17:18
: nope, it is a complete self-contained application) - Durward_Osinski commented on July 2nd 19 at 17:21
: it is single page application. self-contained application. - Allene_Crona78 commented on July 2nd 19 at 17:24
July 2nd 19 at 17:17
I like works like this:
The backend in one of repe
Frontend in another
The frontend connects to turnips turnips buck as git submodule
To run the entire project you need to clone repo with the backend and run in-house script that will pull the turnip front-end, install npm and bower dependencies, and builds the frontend with gulp

Run Nginx config and everything works ))
July 2nd 19 at 17:19
It is important to understand what kind of project is considered. If this is really the app which is suitable for SPA, the Council is a fully independent development, in a separate repo - fit.

If the project content and will be part of the available search engines, anonymum and everything harder and more likely, with a strong desire to use angular will have to do a lot of SPA. And selectively.

The thing is that with the development of the project, when it comes to questions about search engines, speed and shit, it turns out that this angular absolutely worthless. Things like prerender solve the problem only in the simplest cases, and in the development of functional require non-trivial approaches and other crap. Here we are talking about the redirects, 404, possibility to put meta tags, noindex and all that.
People can say that 301/302 and 404 and prerender support, but efforts in which all this translates into 100 times greater than those required in the standardized approach when html gives the backend.

Ie, angular and others like him benefit only if applied correctly.

The question is not sounded on the specifics of the project, because maybe my words are out of place, however - forewarned, forearmed.

Thank you.
July 2nd 19 at 17:21
Just doing a RESTful API for the buck, and as a client - use everything: SPA, Nativ, mobile, etc.
Ie, never communicate: logic, communication and presentation.
By analogy with machines: the client and leverage server - a mechanism to transfer data pull.
Design - just as well, based on what and how the data should look like on the client and what "levers" to provide.
July 2nd 19 at 17:23
1 approach - 2 repository, one for frontend and one for backend.
2 approach the front inside the backend of the project. The only thing that will be in one repository commits for both parts, but I can't say that this is a big problem in the end to filter, index commits certain parts etc. so I worked, I can not say that it was not comfortable. Just you have the opportunity to raise the entire project all at once. Otherwise, you need to configure the routing etc.

Find more questions by tags FrontendBackend