Answer the question
In order to leave comments, you need to log in
Is it worth dividing the site into backend and frontend?
Good afternoon, I was
puzzled here by the issue of site division and the opinion of others is of interest.
Actually, I would like to have a separate server part, access to which will be carried out exclusively using the API. Access is required for the client side, mobile application and several sites under my control.
I plan to write the client part in angularJS. It will be located on a different domain and interact with the server side using AJAX requests. Here, of course, the question of cross-domainity arises, but the question is solvable, although not unambiguously.
Tell me, people who know, is it worth bothering at all and dividing the site, or leave it as it is, and screw the API for the mobile application and other services? Justification is of interest: how it will affect productivity, how labor-intensive it is, etc.
Thanks
Answer the question
In order to leave comments, you need to log in
It's called the Singe Page Application.
If you are not embarrassed by the hassle of indexing a site in a search engine, the approach is quite justified.
Pros:
- weakening connections within the system, simplifying the server part (in fact, you should have a beautiful REST Api there)
- general increase in system responsiveness (if you correctly design the frontend)
Cons:
- total development time may increase depending on the project.
- the need to add generation of page fragments on the server for support by search engines. Of course, there are options to use phantomjs on the server to create these very fragments.
This saves a lot of developers' resources, because you don't have any duplication of functionality in the code. I think that this is the only correct way in a situation where there are a lot of frontends.
Didn't find what you were looking for?
Ask your questionAsk a Question
731 491 924 answers to any question