1👍
My doubt is: should routing be handled by Django or should it be handled by Vue in a SPA?
Your FE needs to know the routes if you’re going to do SPA, e.g. your FE needs to know how to update the URL if user clicks on a link/item. Otherwise there would be page refreshes or wrong URLs.
So here i’m not using Vue to handle routes, but i load individual Vue components of the same app in those Django templates where i need them. My doubt: is it a bad practice? Are there reasons for which i should avoid doing so?
I think you need to decide it you’re going to build a SPA or not. My rule-of-thumb is SPA is better if have a lot of interactions on your page or you have a team of speciallized people for FE. Having a total separation between BE/FE is definitely industry de-facto standard but rendering most stuff on BE and having a lightweight FE is not a crime either, Stack overflow itself uses such approach.
If you’re going with SPA, putting FE URLs in BE also makes not much sense (unless you’re doing something like server side rendering). BE will provide a set of API URLs (invisible to end user) and FE will consume them and provide a set of FE URLs that users would see.
Yes, the main problem is that having the apps hosted on two different domains might make me lose a lot of django benefits in terms of security. I have some doubts on storing a jwt token on local storage, i don’t think its the safest solution; there is session based auth but i don’t know how would it work on two different domains. Another thing is the lack of examples on this, and finally the biggest problem is that i already setup the app on this environment, so moving to decoupled would be quite a pivot
There are multiple answers for your concern.
1- There’s no need to have separated domain. You can prefix all your BE URLs with /api/ then on production you can use a reverse-proxy like NGINX or Traefik or your load balancer, … to separate the two. Having separate domains is easier to maintain in long run but you’ll need to handle cookie/CORS issues now and then.
2- If you have separated domains you can set cookies on the main domain from subdomain with this settings
3- There’s no need to go with JWT token in localstorage. IMO it’s inferior to having httponly cookies. Django session auth has httponly turned on by default. This way random npm libraries you installed or 3rd party scripts on your page has no way to access and steal the token.
4- On a separate note, Django CSRF protection is kinda obsolete now we have samesite cookie on browsers. Check browser support here. Newer versions of Django defaults to Lax that protects you from CSRF on supported browsers. So you can turn that protection off to have one less headache.
I personally think you can stick to Django session based auth, no need to add anything to your FE. FE will just call /api/auth/login and proper cookies will be set automatically.
To be more robust you can add an API like /api/auth/me that returns current logged in user data to FE. FE will call that when user visits your website for first time to understand if user is logged in or not.