8 ms·

I've spent many years working on django including production setups for 3 different companies. My strong advice is to only use Django for API calls (DRF) and th

I've spent many years working on django including production setups for 3 different companies. My strong advice is to only use Django for API calls (DRF) and the built in admin UI. Do not use Django for ANY client facing static site rendering. 1. Deploy the React static pages and JS/CSS resources completely separately from Django. Cloudfront/S3 is my personal choice. You will need to tweak the CORS_ORIGIN_WHITELIST and CORS_ALLOW_HEADERS in the django settings but that's relatively easy. 2. Use Gatsy or something similar to help you with static site generation using react. Remember: React is in charge of HTML/JS/CSS of any type and Django should not get involved. 3. Use https://github.com/ctrlplusb/react-async-component https://github.com/ctrlplusb/react-async-component or something similar to help break up your SPA so the browser doesn't have to load all of it at once and only loads smaller components on an as needed basis. Don't mess with webpack and eject unless you have a very specialized need that cannot be addressed with everything out there.

bredren 6y ago
That's a nice idea for new projects but how would you handle a company with large existing Django sites that want to bring in one or two react-based SPAs?
- deleted 6y ago
  [deleted]
- nickserv 6y ago
  We did this with Vue.js, not sure if it applies to React (I haven't used React). The way we did it was to start with a few parts of the page that really benefited from having Vue.js, using a simple `script src=`. So no components or anything fancy. For this we just put the JS stuff using Django's template system. Once we had proved that this improved the site, we went all in and started to use the "proper" way, building the JS and deploying to a CDN. In parallel to this we set up Django Rest Framework and set up alternate routes to fetch the view data as JSON. In retrospect I would probably skip the hybrid system and just start building view components, but it was done this way so we could more easily revert if it didn't work out.
robofanatic 6y ago
>> Do not use Django for ANY client facing static site rendering. why?
benatkin 6y ago
So don't use Django is your advice to people interested in using Django? Django's frontend rendering is still a major part of the framework, so advising everyone not to use it in a post about Django is a bit misgiving.
- krzepah 6y ago
  It is not. If you intend to have a react front-end then this front-end becomes the "V" in the MVC, while django becomes only the M & C; Having something cohesive is much more reliable than having some template there, some js there, some template there again. If you stick up to one way of doing things, testing and debugging becomes trivial because you are not mixing up three different way of doing something
- arcturus17 6y ago
  I’m currently building an SPA with the above approach and it most definitely isn’t “not using Django”. There’s plenty of Django if you use DRF. You’re also still exposed to templating if you use Django Admin like they suggest and I’m also doing.
vagrantJin 6y ago
This smells of overcomplication turned up to 11. Can you give me a solid usecase of why not to use djangos templating and use - as per your example - an SSG? Seems like the usecases are edge cases. Why use Django just to make api calls when smaller and nimbler alternatives abound. Its no wonder React devs command such a strong hourly fee. They'll mostly be fixing dung with more dung and hooks. Pardon the rant. Im at a job where no one seems to be listening to my case against react when plain whole JS would do. The code will be verbose but there is no magic or illusion. Anyone from junior intern to senior dev can understand the codebase without much help. Its not that big either. grrr
- nickserv 6y ago
  Not the OP but this approach is great if you're starting a new project that is intended to grow. Django has lots of stuff besides the template system, in particular the admin, authentication, and ORM which allow rapid iteration and getting your product into production. After some growth though, you may find yourself constrained by the framework: a mixture of difficulty implementing functionalities, performance problems, and organizational/deployment problems (i.e. several teams wanting to deploy simultaneously). Around that time you'll probably start looking at taking your (obviously well-designed) monolith apart and peeling off the business domains out into separate services. Maybe rewrite some parts Go or Rust? Anyway if you use the template system, you'll have a much harder time doing this than if you're only slinging JSON around. Another advantage is that you get right from the start is having the ability to modify purely display parts of the UI without having to touch the back-end, it doesn't sound like much but is incredibly useful when prototyping/testing new ideas. For an SSG though, for me that's the wrong use case. For that I would use Zola which is incredibly fast and uses a template system that's basically a Rust port of Jinja, so a Django developer is right at home. https://www.getzola.org/ https://www.getzola.org/
  - ttymck 6y ago
    How does "several teams wanting to deploy simultaneously" cause problems in a monolith? Do you mean "merge code changes simultaneously"?
- 6y ago
arcturus17 6y ago
I’m doing this and so far it’s great. I’m not using Gatsby or hosting the React app separately though... serving from the Django server is good enough for my use case.

bredren 6y ago

That's a nice idea for new projects but how would you handle a company with large existing Django sites that want to bring in one or two react-based SPAs?

deleted 6y ago
[deleted]
nickserv 6y ago
We did this with Vue.js, not sure if it applies to React (I haven't used React). The way we did it was to start with a few parts of the page that really benefited from having Vue.js, using a simple `script src=`. So no components or anything fancy. For this we just put the JS stuff using Django's template system. Once we had proved that this improved the site, we went all in and started to use the "proper" way, building the JS and deploying to a CDN. In parallel to this we set up Django Rest Framework and set up alternate routes to fetch the view data as JSON. In retrospect I would probably skip the hybrid system and just start building view components, but it was done this way so we could more easily revert if it didn't work out.

robofanatic 6y ago

>> Do not use Django for ANY client facing static site rendering. why?

benatkin 6y ago

So don't use Django is your advice to people interested in using Django? Django's frontend rendering is still a major part of the framework, so advising everyone not to use it in a post about Django is a bit misgiving.

krzepah 6y ago
It is not. If you intend to have a react front-end then this front-end becomes the "V" in the MVC, while django becomes only the M & C; Having something cohesive is much more reliable than having some template there, some js there, some template there again. If you stick up to one way of doing things, testing and debugging becomes trivial because you are not mixing up three different way of doing something
arcturus17 6y ago
I’m currently building an SPA with the above approach and it most definitely isn’t “not using Django”. There’s plenty of Django if you use DRF. You’re also still exposed to templating if you use Django Admin like they suggest and I’m also doing.

vagrantJin 6y ago

This smells of overcomplication turned up to 11. Can you give me a solid usecase of why not to use djangos templating and use - as per your example - an SSG? Seems like the usecases are edge cases. Why use Django just to make api calls when smaller and nimbler alternatives abound. Its no wonder React devs command such a strong hourly fee. They'll mostly be fixing dung with more dung and hooks. Pardon the rant. Im at a job where no one seems to be listening to my case against react when plain whole JS would do. The code will be verbose but there is no magic or illusion. Anyone from junior intern to senior dev can understand the codebase without much help. Its not that big either. grrr

nickserv 6y ago
Not the OP but this approach is great if you're starting a new project that is intended to grow. Django has lots of stuff besides the template system, in particular the admin, authentication, and ORM which allow rapid iteration and getting your product into production. After some growth though, you may find yourself constrained by the framework: a mixture of difficulty implementing functionalities, performance problems, and organizational/deployment problems (i.e. several teams wanting to deploy simultaneously). Around that time you'll probably start looking at taking your (obviously well-designed) monolith apart and peeling off the business domains out into separate services. Maybe rewrite some parts Go or Rust? Anyway if you use the template system, you'll have a much harder time doing this than if you're only slinging JSON around. Another advantage is that you get right from the start is having the ability to modify purely display parts of the UI without having to touch the back-end, it doesn't sound like much but is incredibly useful when prototyping/testing new ideas. For an SSG though, for me that's the wrong use case. For that I would use Zola which is incredibly fast and uses a template system that's basically a Rust port of Jinja, so a Django developer is right at home. https://www.getzola.org/ https://www.getzola.org/
- ttymck 6y ago
  How does "several teams wanting to deploy simultaneously" cause problems in a monolith? Do you mean "merge code changes simultaneously"?
6y ago

arcturus17 6y ago

I’m doing this and so far it’s great. I’m not using Gatsby or hosting the React app separately though... serving from the Django server is good enough for my use case.