SPA application, authorization and what to render backend'y?

Question

Django

Good afternoon, I'm interested in the best practices for organizing a SPA application with a REST API, what does it cost, if at all, to render on the backend side?
What options I see:
1. render index.html, then render all views by the client
2. render by the login page server, log in, render by the index page server, then by the client
3. render nothing by the server, log in with REST token
which approach do you think is the best , what do you use yourself, how do you organize authentication and authorization? Thanks!

Answer 1

what does it cost, if at all, to render on the backend side?

You don't need to reddit anything at all. The server is separate, the client is separate. They shouldn't overlap. server-side rendering is used as one of the optimization options + for search engines. This is not necessary for everyone and not always.
It should also be remembered that storing secure data accessible from JS is not very convenient (browsers, alas, do not provide secure storage yet), therefore it is better to set the token by the server in the httponly cookie. Then the browser will resolve everything itself and will be a little bit more secure. Unfortunately, in the context of SPA, I don’t know how to organize this business securely. In the general case, it is normal to store in localStorage, but this confuses me. Well, of course, everything is under HTTPS, otherwise all security pens go to waste.

Answer 2

We are working on the third option. Very comfortably. We develop projects within our department, we work in pairs. I am doing a restful backend. At this time, a colleague puts fake data and makes an application in Angular. Then when the backend is ready, we remove the stubs and rejoice xD People who put the prototype of the project under development do not see the full picture, and we often made mistakes when the backend & frontend were intertwined and did everything according to their prototype. Now we can say we do it to the "maximum" as I carefully think over the backend, the necessary controllers, models. PS We rewrote a couple of projects that were in php (Yii framework): The interface became intuitive, the number of controllers was reduced to 2 - 3x with clear actions. There is no need to expand the project, since the code and architecture are transparent

Answer 3

Alexander Kondaurov Sergey Protko I'm wondering if you follow the path of 3 decisions, how do you do (if you have one) authorization. I mean auth. Here you have a button - enter through VK. In the link for this button, it is desirable (I would say - mandatory) to write STATE - a randomly generated string to protect against attacks. This STATE is then checked on the server. But how to check it if it was generated on the client?

Answer 4

we used the second option in projects. Cons are approximately the following:
1. There is no way to fully separate the frontend and backend parts. Often you have to climb into the backend in order to add / change something, etc.
2. I thought there would be a few minuses, but something seems to be missing.
If you completely separate the backend and frontend, this is of course cool, but you need to take into account some factors:
1. Extra requests.
2. Anyone can check the code that implements the functionality for authorized users.
but on the other hand, the front lives separately from the backend, and this is very, very cool, especially if you have a big project, IMHO, of course,