14 ms·

Show HN: Django and React SaaS boilerplate tutorial

135 points by pplonski86 6y ago

notsureaboutpg 6y ago
Pretty cool! I have done most of this in the past and the documentation here is pretty good! I wonder how one will horizontally scale this app if need be. Would you separate out nginx onto a different instance and have it pass traffic back and forth between several instances running the django backend? Whatever the way to do it, it would be cool to see that added as an article here :)
mrauha 6y ago
Thanks for this! Looks useful, will be checking it out after the Christmas festivities. Coming from academia/data science and learning this from the scratch, the python backend + js frontend boilerplates are quite cryptic. The tools for sure seem useful, but there's a lot to grasp for a noob - rabbits, celeries, and so on.
- jjice 6y ago
  Agreed. A lot of boiler plates seems to back everything under the sun, when I really just want a simple reproducible template, maybe ever with docker support. This looks like it hits featureful without unnecessary complexity.
  - pplonski86 6y ago
    True, that was the purpose of this Django+React boilerplate. Provide minimal and easy to follow template. Additionally, every code added is documented in the series of articles so you can learn how it was done. There is a docker-compose provided to set up and run this boilerplate application on single server machine. It can be easily adjusted to your needs.
TekMol 6y ago
What would the typical HN startup gain from this over using just Django? Is there anything on the Demo page (https://boilerplate.saasitive.com/ https://boilerplate.saasitive.com/) that would be different? In my experience as a user, everything that uses React is always an annoyance in one way or another. But I am happy to understand if there are legit use cases.
- arvindamirtaa 6y ago
  It's a good learning tool, and if you want to use React for some specific reason this may be a good starting point. But not otherwise. Otherwise django + react makes sense when there're different people (or teams) handling the frontend and the backend.
  - pplonski86 6y ago
    Yes, this boilerplate has two main goals: (1) it is a good starting point for developing the more advanced applications (2) it is provided for learning purposes, there are step-by-step instructions how the boilerplate was created. BTW, it is still under the development. The boilerplate code runs with docker-compose on single server but in the future the frontend and backend can be easily divided, so separate teams can work on them.
- ulisesrmzroche 6y ago
  It’s really difficult to keep your data in sync with the backend, especially at scale. They also fit in well in a micro service architecture, which solves a lot of comms and maintenance problems at scale. The typical hn startup is expected to grow to that size, to an enterprise scale, so you’re not going to see a lot of people use Django. Can you list one annoyance you see as a user with React?
syndacks 6y ago
The biggest challenge to using Django with React IMO is getting the right blend of isomorphic rendering down. I don't want to go full SPA with Django as this defeats the purpose of Django IMO. Most parts of the site I want server-rendered, while in stateful parts I want React. So, let's say I have a site with 20 different React "apps" (i.e. stateful components) that I want to distribute amongst my various Django sections (Django "Apps" within the same project). And I want to do that with one webpackconfig. How do I tell my webpack where to put all those react bundles? The answer I've found is django-webpack-loader[1], however as you can see in the Issues section, one of the biggest limitations here is the inability to chunk React (and other issues). Does anyone have a solution they like for this kind of isomporphic Django problem? 1. https://github.com/owais/django-webpack-loader https://github.com/owais/django-webpack-loader
- Demiurge 6y ago
  What do you mean by "inability to chunk React"? I've done as you describe, separate Django views have different client components and those components import subcomponents which are shared as needed, throughout the site. I just have the webpack build each "root" client component individually, and you can separate subcomponents into libraries. You can even have multiple react apps rendered into their own containers that do not share state as long as you separated them cleanly.
  - syndacks 6y ago
    Sorry, "chunking" is code-splitting. https://reactjs.org/docs/code-splitting.html https://reactjs.org/docs/code-splitting.html
- bredren 6y ago
  Yes. I have large portions of a server-rendered, django web application that uses react largely as you've described. I wanted to bring a single react app into the django project using a root dom element from a django template using the same template inheritance as the rest of the site. (common navbar) Benefits of this approach on Django side were adherence to Django structure and session-based auth for the react app's API calls. My goal was to minimize customization while retaining the "spirit" of both Django and react. I decided the react app should flow from an unejected Create React App (CRA) project. This provides the developer experience of CRA's development environment hot-reload and production build bundling. It also makes it more likely the react app can be migrated to new versions of CRA. The webpack config changes needed to pull this off are not extensive but do leverage Create React App Configuration Override (CRACO). [1] CRACO is the best-supported config layer for CRA today, supporting CRA 4.*. Key aspects of my implementation are: - Use of package.json poststart to move files generated by CRA's run script and update paths made by CRA-generated files to work inside django. - Use of the package.json postbuild script to move and rename files to nestle assets into their proper place in a django static path. - Customization of HtmlWebpackPlugin to modify CRA's: - Out-of-box behavior of webpack bodyTags and headTags. - webpackConfig.output to use a project-excluded directory that facilitates hot reload during dev While my implementation doesn't currently support N react apps bundles at this time I could see it being done provided they share a single package file. Being relatively new to modern web front end toolchains I ended up rewriting much of the of the user documentation for CRACO as part of my learning process for this mash of Django and React. [2] I have not released my solution but I have stubbed out the problem and solution description [3]. If someone is very much in need of this project, please write me. I have wanted to release it but have just not had time yet, and I need to update it to CRA 4. All this said and done, having accomplished my initial goals, I am less certain now that it is worth trying to integrate a CRA-app into Django, at least if the goal is to retain shared sub templates from the rest of the Django app. Instead, I suspect the better method would be to expect to have to maintain a react-compatible implementation of say a navbar or other "common" portion of the UI on the server-rendered pages and leverage only django's session auth on the SPA. Ultimately, this integration experience made me take a hard look at my investment in Django. I know and enjoy python and the Django framework. But at least for new projects, I can't help but feel they faces an existential threat from modern web (react) paired with a node backend. [1] https://github.com/gsoft-inc/craco https://github.com/gsoft-inc/craco [2] https://github.com/gsoft-inc/craco/pull/203 https://github.com/gsoft-inc/craco/pull/203 [3] https://github.com/banagale/create-react-app-django https://github.com/banagale/create-react-app-django
sandGorgon 6y ago
unless you're doing a lot of math - where python/numpy/sklearn/scipy/BLAS/LAPACK/Tensorflow is unparalleled - you should do everything in JS/TS. something like nextjs - with built in frontend+backend is ideal.
- MoSattler 6y ago
  The JS ecosystem is unfortunately lacking anything as powerful as the Django ORM.
  - djstein 6y ago
    This is it. If you can’t connect to your database effectively and safety execute queries + migrations (looking at you people who write SQL queries by hand in Typescript) you’re just writing something that is one key stroke away from destroying your database.
    - nicoburns 6y ago
      > you’re just writing something that is one key stroke away from destroying your database. Is it any more difficult to destroy your database in Django DSL than it is in raw SQL? We're using a lot of raw SQL at day job, and the two junior developers on our team who had no priory experience of working with SQL databases at all have picked it up just fine.
      - dstep-init 6y ago
        It just seems kind of like building a car by hand to me. Why would you want to use raw SQL when you can leverage the power of your favorite programming language? Isn't it cleaner to write a Model with Pythonic field constraints, methods, and subclassing? Don't get me wrong - knowing SQL is important for every developer, but one doesn't need to be an SQL expert to be a back-end development expert.
  - nicoburns 6y ago
    The ORM space is actually getting much closer. Both TypeORM and Objection.js are good options. But if you're talking about Django as whole then I totally agree.
city41 6y ago
I was reading through the tutorial and it has you add CORS to enable api requests during development. I think using create-react-app's proxy feature might be a better fit: https://create-react-app.dev/docs/proxying-api-requests-in-development/ https://create-react-app.dev/docs/proxying-api-requests-in-d...
- Kunigaikstis 6y ago
  I always had this issue but never thought about looking it up on the CRA side of things. Thanks for the drop of knowledge!
MoSattler 6y ago
As someone who has worked daily with React (and Django) for more than 5 years, I am always surprised to see how many boilerplates and tutorials include redux. It’s a tool that solves very specific issues that most people won’t have and often adds quite a bit of complexity.
- djstein 6y ago
  I would also agree with this. These days we should be steering people to context api and react-query
  - pplonski86 6y ago
    I like the way redux divide the code into actions and reducer. In my opinion the application code is clear with redux. Off the topic, I mainly write in Python. I started programming in C/C++. I very often miss header files from C/C++ during Python programming. In C++ header files you have the full interface definition and it was easy to understand the code. Somehow, the redux and C header files are for me similar (in the sense of clear code).
    - djstein 6y ago
      I was definitely had the same feeling when writing redux! The separate of actions, types, and reducers is quite nice. You can still replicate these ideas with the Context API if you choose too.
- 4778468d 6y ago
  Redux is really not needed any more and just makes things horribly complex.
agconti 6y ago
As someone who works in Django a lot, their non-standard approach to defining models is wild. ie. Their approach in accounts models.py: https://github.com/saasitive/django-react-boilerplate/blob/main/backend/server/apps/accounts/models.py https://github.com/saasitive/django-react-boilerplate/blob/m... Over the standard approach in their notes models.py: https://github.com/saasitive/django-react-boilerplate/blob/main/backend/server/apps/notes/models.py https://github.com/saasitive/django-react-boilerplate/blob/m...
- pplonski86 6y ago
  The tutorial is still under the development and I will update the User model logic for sure (for payments and teams features). The 'wild' overwrite of User model was minimal to set email as required field in User model.
  - wbc 6y ago
    What are your thoughts on AbstractUser https://docs.djangoproject.com/en/3.1/topics/auth/customizing/#using-a-custom-user-model-when-starting-a-project https://docs.djangoproject.com/en/3.1/topics/auth/customizin...?
  - disgrunt 6y ago
    Django now just recommends a custom user model if you intend to change it. In my experience, this is now a best practice in Django. [0] [0]: https://docs.djangoproject.com/en/3.1/topics/auth/customizing/#auth-custom-user https://docs.djangoproject.com/en/3.1/topics/auth/customizin...
andretti1977 6y ago
Cory Zue has made a saas django starter kit (https://www.saaspegasus.com/ https://www.saaspegasus.com/).
ohduran 6y ago
In case you're looking for something similar, but django-boilerplate doesn't adjust, try cookiecutter-react-django instead. It has Heroku deployment, and a minimalistic approach. https://github.com/ohduran/cookiecutter-react-django https://github.com/ohduran/cookiecutter-react-django
objektif 6y ago
What framework would HN recommend for frontend development? Is React the way to go?
- arendtio 6y ago
  I prefer Vue but I think both are valid mainstream choices nowadays.
- toinbis 6y ago
  https://github.com/fabiospampinato/cash https://github.com/fabiospampinato/cash of you want to build website, vue.js if you want to build an app. In app world, vue.js (options api specifically, which is easier to understand for newcomers) can get up and running faster than react. After you master app development, it comes down to ecosystem/tooling (pros and cons here with both react and vue) and mostly - personal preference.
drcongo 6y ago
Why does this need React?
phatboyslim 6y ago
I admire the motivation here to offer a boilerplate to the community using these tools, but it feels like a lot of this has been solved by the Baas providers like AWS Amplify, Azure Static Web Apps, Firebase, etc. These services all support your choice of front-end and back-end programming language. All these providers also allow hooks into features like security, database, apis, ci/cd, and so on. You would be in a serverless architecture also which provides scalability and keeps costs low up front. Not trying to discredit the author here, which is admirable in the intent, but feels like it's trying to solve for something that several other solutions exist for unless I'm missing something critical.
- almost 6y ago
  Serverless type things are totally fine if you’re into that. But it can be nice to just have a simple backend running on a server. No different services to think about, just simple code. For me Django is the way to go because I’ve been using it for years, for others it might be some other language/framework. You should most definitely continue to do you, but for me that’s what works.
superflit 6y ago
I don't want feel like a Dinosaur. But I hope some of HNers illuminated me. I don't do React/vue . Only SRR + some javascript (modals, effects, etc). What I am missing? Serious question, Am I missing TOO much or maybe 20% productivity? 1. I am a one man shop doing Django sites, SRR only. When I need to interact with front end for more "Reactivity" I use javacript + a view exporting json. 2. About admin: It is good for me or the operator but I dont feel like my user should be using it? Then I do my own "admin" for the customer. Please what I am missing? The #1 I feel once you have 2-3 they may make sense (separating functions). The #2 the community answer was : "Not for user, only staff or operator and not for general consumption" I would glad hear your points. Thank You
- deleted 6y ago
  [deleted]
- oregontechninja 6y ago
  This is fine. I think frameworks are more useful for teams where forcing the same style on people helps the interoperability.
- peterthehacker 6y ago
  Whats SRR? I know SSR - server side rendering, but since that’s more-so a React/Vue thing I assume that you’re referring to something else.
- throwaway189262 6y ago
  If the site is mostly static then SPA isn't worth it. If you've got a lot of functionality SPA let's you make site way more interactive without hacks. The best of both worlds is a static site sprinkled with React components where they make sense. Angular can't really do this, but react is designed to work in parts of pages. So if your customer wants one really crazy sortable filterable list view you can do that in clean react code instead of a bunch of jacky jquery
- toinbis 6y ago
  Rephrasing https://www.swyx.io/svelte-sites-react-apps/ https://www.swyx.io/svelte-sites-react-apps/ : a) react/svelte/next/nuxt/gatsby/sapper/angular for apps; b) django/rails/express.js for sites;
freddref 6y ago
You could potentially remove more? I would maybe use this if it was Django and React only, there are many things in the tech stack which I just don't want to get into. For example, I would be happy with sqlite instead of postgres. I'll migrate if sqlite ever gets near capacity.
- arcturus17 6y ago
  What kind of web projects are you building that benefit from SQLite over Postgres? Adding Postgres to a Django project is like 20min of config... And it doesn't really modify the API, it only supersets it.
  - ulisesrmzroche 6y ago
    Embedded apps is the usual case, but I don’t see the point with anything else, with its limited concurrency, its highly insecure and poor user management. Using SQLite on a production environment and only migrating up when you fill it up sounds like a big wtf
theptip 6y ago
I've been evaluating potential replacements for the Django admin to provide a path for progressive evolution as apps outgrow Django, and have found https://marmelab.com/react-admin/Readme.html https://marmelab.com/react-admin/Readme.html -- anyone got other generated admin platforms they like for handling CRUD / mutations? I think the Django admin is great, I use it a lot and recommend it for new/small projects, but it's tightly coupled to the Django ORM which can be restrictive in some usecases.
dstep-init 6y ago
Wow this would've been so useful to me when I was starting out. You are a scholar.
pryelluw 6y ago
Falls a bit short: - Should use the django-env package to have a generic settings file - Models are incomplete - Where does registration happen? In the backend? Fronted? - Weird code around the user model - Unused imports Overall this needs some polish in order to be a strong boilerplate solution. I’d say request code reviews from the community in order to improve it. Also think about using cookie cutter for it as well.
albertgoeswoof 6y ago
Is there a list of these anywhere for Django and other languages? Eg rails jumpstart etc

135 points by pplonski86 6y ago

Pretty cool! I have done most of this in the past and the documentation here is pretty good! I wonder how one will horizontally scale this app if need be. Would you separate out nginx onto a different instance and have it pass traffic back and forth between several instances running the django backend? Whatever the way to do it, it would be cool to see that added as an article here :)

mrauha 6y ago

Thanks for this! Looks useful, will be checking it out after the Christmas festivities. Coming from academia/data science and learning this from the scratch, the python backend + js frontend boilerplates are quite cryptic. The tools for sure seem useful, but there's a lot to grasp for a noob - rabbits, celeries, and so on.

jjice 6y ago
Agreed. A lot of boiler plates seems to back everything under the sun, when I really just want a simple reproducible template, maybe ever with docker support. This looks like it hits featureful without unnecessary complexity.
- pplonski86 6y ago
  True, that was the purpose of this Django+React boilerplate. Provide minimal and easy to follow template. Additionally, every code added is documented in the series of articles so you can learn how it was done. There is a docker-compose provided to set up and run this boilerplate application on single server machine. It can be easily adjusted to your needs.

TekMol 6y ago

What would the typical HN startup gain from this over using just Django? Is there anything on the Demo page (https://boilerplate.saasitive.com/ https://boilerplate.saasitive.com/) that would be different? In my experience as a user, everything that uses React is always an annoyance in one way or another. But I am happy to understand if there are legit use cases.

arvindamirtaa 6y ago
It's a good learning tool, and if you want to use React for some specific reason this may be a good starting point. But not otherwise. Otherwise django + react makes sense when there're different people (or teams) handling the frontend and the backend.
- pplonski86 6y ago
  Yes, this boilerplate has two main goals: (1) it is a good starting point for developing the more advanced applications (2) it is provided for learning purposes, there are step-by-step instructions how the boilerplate was created. BTW, it is still under the development. The boilerplate code runs with docker-compose on single server but in the future the frontend and backend can be easily divided, so separate teams can work on them.
ulisesrmzroche 6y ago
It’s really difficult to keep your data in sync with the backend, especially at scale. They also fit in well in a micro service architecture, which solves a lot of comms and maintenance problems at scale. The typical hn startup is expected to grow to that size, to an enterprise scale, so you’re not going to see a lot of people use Django. Can you list one annoyance you see as a user with React?

syndacks 6y ago

The biggest challenge to using Django with React IMO is getting the right blend of isomorphic rendering down. I don't want to go full SPA with Django as this defeats the purpose of Django IMO. Most parts of the site I want server-rendered, while in stateful parts I want React. So, let's say I have a site with 20 different React "apps" (i.e. stateful components) that I want to distribute amongst my various Django sections (Django "Apps" within the same project). And I want to do that with one webpackconfig. How do I tell my webpack where to put all those react bundles? The answer I've found is django-webpack-loader[1], however as you can see in the Issues section, one of the biggest limitations here is the inability to chunk React (and other issues). Does anyone have a solution they like for this kind of isomporphic Django problem? 1. https://github.com/owais/django-webpack-loader https://github.com/owais/django-webpack-loader

Demiurge 6y ago
What do you mean by "inability to chunk React"? I've done as you describe, separate Django views have different client components and those components import subcomponents which are shared as needed, throughout the site. I just have the webpack build each "root" client component individually, and you can separate subcomponents into libraries. You can even have multiple react apps rendered into their own containers that do not share state as long as you separated them cleanly.
- syndacks 6y ago
  Sorry, "chunking" is code-splitting. https://reactjs.org/docs/code-splitting.html https://reactjs.org/docs/code-splitting.html
bredren 6y ago
Yes. I have large portions of a server-rendered, django web application that uses react largely as you've described. I wanted to bring a single react app into the django project using a root dom element from a django template using the same template inheritance as the rest of the site. (common navbar) Benefits of this approach on Django side were adherence to Django structure and session-based auth for the react app's API calls. My goal was to minimize customization while retaining the "spirit" of both Django and react. I decided the react app should flow from an unejected Create React App (CRA) project. This provides the developer experience of CRA's development environment hot-reload and production build bundling. It also makes it more likely the react app can be migrated to new versions of CRA. The webpack config changes needed to pull this off are not extensive but do leverage Create React App Configuration Override (CRACO). [1] CRACO is the best-supported config layer for CRA today, supporting CRA 4.*. Key aspects of my implementation are: - Use of package.json poststart to move files generated by CRA's run script and update paths made by CRA-generated files to work inside django. - Use of the package.json postbuild script to move and rename files to nestle assets into their proper place in a django static path. - Customization of HtmlWebpackPlugin to modify CRA's: - Out-of-box behavior of webpack bodyTags and headTags. - webpackConfig.output to use a project-excluded directory that facilitates hot reload during dev While my implementation doesn't currently support N react apps bundles at this time I could see it being done provided they share a single package file. Being relatively new to modern web front end toolchains I ended up rewriting much of the of the user documentation for CRACO as part of my learning process for this mash of Django and React. [2] I have not released my solution but I have stubbed out the problem and solution description [3]. If someone is very much in need of this project, please write me. I have wanted to release it but have just not had time yet, and I need to update it to CRA 4. All this said and done, having accomplished my initial goals, I am less certain now that it is worth trying to integrate a CRA-app into Django, at least if the goal is to retain shared sub templates from the rest of the Django app. Instead, I suspect the better method would be to expect to have to maintain a react-compatible implementation of say a navbar or other "common" portion of the UI on the server-rendered pages and leverage only django's session auth on the SPA. Ultimately, this integration experience made me take a hard look at my investment in Django. I know and enjoy python and the Django framework. But at least for new projects, I can't help but feel they faces an existential threat from modern web (react) paired with a node backend. [1] https://github.com/gsoft-inc/craco https://github.com/gsoft-inc/craco [2] https://github.com/gsoft-inc/craco/pull/203 https://github.com/gsoft-inc/craco/pull/203 [3] https://github.com/banagale/create-react-app-django https://github.com/banagale/create-react-app-django

sandGorgon 6y ago

unless you're doing a lot of math - where python/numpy/sklearn/scipy/BLAS/LAPACK/Tensorflow is unparalleled - you should do everything in JS/TS. something like nextjs - with built in frontend+backend is ideal.

MoSattler 6y ago
The JS ecosystem is unfortunately lacking anything as powerful as the Django ORM.
- djstein 6y ago
  This is it. If you can’t connect to your database effectively and safety execute queries + migrations (looking at you people who write SQL queries by hand in Typescript) you’re just writing something that is one key stroke away from destroying your database.
  - nicoburns 6y ago
    > you’re just writing something that is one key stroke away from destroying your database. Is it any more difficult to destroy your database in Django DSL than it is in raw SQL? We're using a lot of raw SQL at day job, and the two junior developers on our team who had no priory experience of working with SQL databases at all have picked it up just fine.
    - dstep-init 6y ago
      It just seems kind of like building a car by hand to me. Why would you want to use raw SQL when you can leverage the power of your favorite programming language? Isn't it cleaner to write a Model with Pythonic field constraints, methods, and subclassing? Don't get me wrong - knowing SQL is important for every developer, but one doesn't need to be an SQL expert to be a back-end development expert.
- nicoburns 6y ago
  The ORM space is actually getting much closer. Both TypeORM and Objection.js are good options. But if you're talking about Django as whole then I totally agree.

city41 6y ago

I was reading through the tutorial and it has you add CORS to enable api requests during development. I think using create-react-app's proxy feature might be a better fit: https://create-react-app.dev/docs/proxying-api-requests-in-development/ https://create-react-app.dev/docs/proxying-api-requests-in-d...

Kunigaikstis 6y ago
I always had this issue but never thought about looking it up on the CRA side of things. Thanks for the drop of knowledge!

MoSattler 6y ago

As someone who has worked daily with React (and Django) for more than 5 years, I am always surprised to see how many boilerplates and tutorials include redux. It’s a tool that solves very specific issues that most people won’t have and often adds quite a bit of complexity.

djstein 6y ago
I would also agree with this. These days we should be steering people to context api and react-query
- pplonski86 6y ago
  I like the way redux divide the code into actions and reducer. In my opinion the application code is clear with redux. Off the topic, I mainly write in Python. I started programming in C/C++. I very often miss header files from C/C++ during Python programming. In C++ header files you have the full interface definition and it was easy to understand the code. Somehow, the redux and C header files are for me similar (in the sense of clear code).
  - djstein 6y ago
    I was definitely had the same feeling when writing redux! The separate of actions, types, and reducers is quite nice. You can still replicate these ideas with the Context API if you choose too.
4778468d 6y ago
Redux is really not needed any more and just makes things horribly complex.

agconti 6y ago

As someone who works in Django a lot, their non-standard approach to defining models is wild. ie. Their approach in accounts models.py: https://github.com/saasitive/django-react-boilerplate/blob/main/backend/server/apps/accounts/models.py https://github.com/saasitive/django-react-boilerplate/blob/m... Over the standard approach in their notes models.py: https://github.com/saasitive/django-react-boilerplate/blob/main/backend/server/apps/notes/models.py https://github.com/saasitive/django-react-boilerplate/blob/m...

pplonski86 6y ago
The tutorial is still under the development and I will update the User model logic for sure (for payments and teams features). The 'wild' overwrite of User model was minimal to set email as required field in User model.
- wbc 6y ago
  What are your thoughts on AbstractUser https://docs.djangoproject.com/en/3.1/topics/auth/customizing/#using-a-custom-user-model-when-starting-a-project https://docs.djangoproject.com/en/3.1/topics/auth/customizin...?
- disgrunt 6y ago
  Django now just recommends a custom user model if you intend to change it. In my experience, this is now a best practice in Django. [0] [0]: https://docs.djangoproject.com/en/3.1/topics/auth/customizing/#auth-custom-user https://docs.djangoproject.com/en/3.1/topics/auth/customizin...

andretti1977 6y ago

Cory Zue has made a saas django starter kit (https://www.saaspegasus.com/ https://www.saaspegasus.com/).

ohduran 6y ago

In case you're looking for something similar, but django-boilerplate doesn't adjust, try cookiecutter-react-django instead. It has Heroku deployment, and a minimalistic approach. https://github.com/ohduran/cookiecutter-react-django https://github.com/ohduran/cookiecutter-react-django

objektif 6y ago

What framework would HN recommend for frontend development? Is React the way to go?

arendtio 6y ago
I prefer Vue but I think both are valid mainstream choices nowadays.
toinbis 6y ago
https://github.com/fabiospampinato/cash https://github.com/fabiospampinato/cash of you want to build website, vue.js if you want to build an app. In app world, vue.js (options api specifically, which is easier to understand for newcomers) can get up and running faster than react. After you master app development, it comes down to ecosystem/tooling (pros and cons here with both react and vue) and mostly - personal preference.

drcongo 6y ago

Why does this need React?

phatboyslim 6y ago

I admire the motivation here to offer a boilerplate to the community using these tools, but it feels like a lot of this has been solved by the Baas providers like AWS Amplify, Azure Static Web Apps, Firebase, etc. These services all support your choice of front-end and back-end programming language. All these providers also allow hooks into features like security, database, apis, ci/cd, and so on. You would be in a serverless architecture also which provides scalability and keeps costs low up front. Not trying to discredit the author here, which is admirable in the intent, but feels like it's trying to solve for something that several other solutions exist for unless I'm missing something critical.

almost 6y ago
Serverless type things are totally fine if you’re into that. But it can be nice to just have a simple backend running on a server. No different services to think about, just simple code. For me Django is the way to go because I’ve been using it for years, for others it might be some other language/framework. You should most definitely continue to do you, but for me that’s what works.

superflit 6y ago

I don't want feel like a Dinosaur. But I hope some of HNers illuminated me. I don't do React/vue . Only SRR + some javascript (modals, effects, etc). What I am missing? Serious question, Am I missing TOO much or maybe 20% productivity? 1. I am a one man shop doing Django sites, SRR only. When I need to interact with front end for more "Reactivity" I use javacript + a view exporting json. 2. About admin: It is good for me or the operator but I dont feel like my user should be using it? Then I do my own "admin" for the customer. Please what I am missing? The #1 I feel once you have 2-3 they may make sense (separating functions). The #2 the community answer was : "Not for user, only staff or operator and not for general consumption" I would glad hear your points. Thank You

deleted 6y ago
[deleted]
oregontechninja 6y ago
This is fine. I think frameworks are more useful for teams where forcing the same style on people helps the interoperability.
peterthehacker 6y ago
Whats SRR? I know SSR - server side rendering, but since that’s more-so a React/Vue thing I assume that you’re referring to something else.
throwaway189262 6y ago
If the site is mostly static then SPA isn't worth it. If you've got a lot of functionality SPA let's you make site way more interactive without hacks. The best of both worlds is a static site sprinkled with React components where they make sense. Angular can't really do this, but react is designed to work in parts of pages. So if your customer wants one really crazy sortable filterable list view you can do that in clean react code instead of a bunch of jacky jquery
toinbis 6y ago
Rephrasing https://www.swyx.io/svelte-sites-react-apps/ https://www.swyx.io/svelte-sites-react-apps/ : a) react/svelte/next/nuxt/gatsby/sapper/angular for apps; b) django/rails/express.js for sites;

freddref 6y ago

You could potentially remove more? I would maybe use this if it was Django and React only, there are many things in the tech stack which I just don't want to get into. For example, I would be happy with sqlite instead of postgres. I'll migrate if sqlite ever gets near capacity.

arcturus17 6y ago
What kind of web projects are you building that benefit from SQLite over Postgres? Adding Postgres to a Django project is like 20min of config... And it doesn't really modify the API, it only supersets it.
- ulisesrmzroche 6y ago
  Embedded apps is the usual case, but I don’t see the point with anything else, with its limited concurrency, its highly insecure and poor user management. Using SQLite on a production environment and only migrating up when you fill it up sounds like a big wtf

theptip 6y ago

I've been evaluating potential replacements for the Django admin to provide a path for progressive evolution as apps outgrow Django, and have found https://marmelab.com/react-admin/Readme.html https://marmelab.com/react-admin/Readme.html -- anyone got other generated admin platforms they like for handling CRUD / mutations? I think the Django admin is great, I use it a lot and recommend it for new/small projects, but it's tightly coupled to the Django ORM which can be restrictive in some usecases.

dstep-init 6y ago

Wow this would've been so useful to me when I was starting out. You are a scholar.

pryelluw 6y ago

Falls a bit short: - Should use the django-env package to have a generic settings file - Models are incomplete - Where does registration happen? In the backend? Fronted? - Weird code around the user model - Unused imports Overall this needs some polish in order to be a strong boilerplate solution. I’d say request code reviews from the community in order to improve it. Also think about using cookie cutter for it as well.

albertgoeswoof 6y ago

Is there a list of these anywhere for Django and other languages? Eg rails jumpstart etc