django-webpack-loader | Transparently use webpack with django | Plugin library

You have two things to do in order to get your app working the way you want.

1. Install, configure, and run a module bundler
2. Use collectstatic

Module bundler:

You have a few choices, but most use webpack because it is the most popular. I prefer rollup but it is all up to preference.

rollup quickstart: https://rollupjs.org/guide/en/#quick-start

webpack: https://webpack.js.org/concepts/

Since you are using Typescript, see the plugins for bundling Typescript

https://webpack.js.org/guides/typescript/

https://github.com/rollup/rollup-plugin-typescript

After you bundle, you should have a main.js file or equivalent. Make sure that main.js is in its own folder. Bundlers will typically do this for you.

Add that directory to your STATICFILES_DIRS in settings.py.

Note that you will need to set a STATIC_ROOT for this to work. This will be a folder that you will store your collected static files at.

Run python manage.py collectstatic

Sidenote: if you are using python manage.py runserver to start your application, you don't need to run collectstatic

Opinions may differ, but based on reading and personal experience, I consider using separate Next.js and Django apps to be preferable. This (1) helps with separation of concerns, (2) helps avoid making Django or Next.js do anything that their designers did not anticipate, and (3) is simple with Docker.

Here's an example project that uses docker-compose to manage services including a Next.js frontend, Django backend, and Postgres database: https://github.com/ModularHistory/modularhistory

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.

I don't know about django, But I know about vue..

1. is this how am I supposed to do it?

For me, I don't suggest it, you can use your django as a backend for your frontend that should mean you would have 2 servers running. 1 for your django and 1 for your vue app. use XHR request to access your django App, remember to handle CORS. IMHO I don't want vue to be used as a component based framework.

1. is there a shorter way.

YES, and this is how you do it.

add to package.json

Check the difference between root and alias nginx directives. For your case you should use

I had the same issue, also running Django with django-webpack-loader, and I also found that the webpack-stats.json file was not being generated. I fixed it by downgrading webpack-bundle-tracker to 0.4.3. I'm not sure why the latest version of this package does not work.