Can you share your experiences using Python Django for SaaS products?
If you use this in your stack can your experiences, and why you chose Django over other options? Would hugely appreciate any info fellow devs can share on this! 🙂
If you use this in your stack can your experiences, and why you chose Django over other options? Would hugely appreciate any info fellow devs can share on this! 🙂
Django is a robust, opinionated framework that could really be considered a DSL for web development in some respects. I have been using Django for 7 years now, in hobby projects, professional settings, and my own products. Additional to this, I've mentored engineers in best practices and even written a lesson on the topic that I ended up livestreaming then posting to YouTube as learning material.
With all of that in mind, here is my take.
Projects that choose not to use a robust framework like Django end up taking one of two routes:
Every framework has it's drawbacks, including Django. However, choosing a robust framework from the outset reduces the amount of discovery & planning needed to get started. You are able to plan your architecture in a more abstract sense and that can really help get going.
In my experience, Django is very maintainable with great documentation and a lot of resources to tap into.
This is a really great answer, thanks for sharing. I do feel is an area where backends written in Node can fall down (e.g. a simple REST API for serving frontend)... I know there are tons of libraries in the npm ecosystem, but a lot of projects just start out in express with little framework or guidance. Of course this can be a benefit sometimes, but it does run a greater risk of wheel reinvention perhaps...
Completely agree with the use of robust frameworks—both for frontend and backend. It’s not worth reinventing the wheel—the large communities, documentation, and time saved make frameworks so valuable.
The only exceptions are for small one-off features or specific language requirements.
Built and sold the parking enforcement SaaS, EasyALPR, using exclusively Django for the web application / backend. I chose it because it was a full-featured Python-based web framework.
I'm building another SaaS now with Django.
There is a lot of customization out-of-the-box necessary to make it function like a "modern" web application.
For example, excellent login, sign up and password reset flows require careful customization using the AllAuth package. If you want to do swifty frontend stuff, you'll need to build APIs using Django Rest Framework.
All of it sort of starts to make sense after you've worked with it a fair amount.
Depending on your existing development experience, (for example if you are a very experienced JS user and understand webpack etc well,) I might consider a Node instead.
Django doesn't make many affordances for SPAs, in fact, integrating a React SPA is a huge pain. However, if you are just looking to mostly do page-refresh type stuff, the model-view-template thing means you can build quickly.
If you are a python-y person already, Django is especially good if you are not looking to be fancy or even suck at the frontend. Boring tech, like old Bootstrap 4.x-based html templates like "Color Admin" or the like work really well with Django.
Thanks for this! And huge congrats on building and selling EasyALPR, that's super impressive!
So I'd say I'm pretty comfortable in both python and JS these days (I started with the former, but have done more with the latter of late). I'm considering options for writing a new project backend in either JS (e.g. node express) or python (django). I think the frontend will certainly be a React SPA, but the reason I'm tempted by Django (and going back to python) for the backend is that for backend logic that gets more complex the asynchronous event-driven nature of node starts to grate on me (there's the async await pattern, sure, but it constantly feels like I'm working against the language rather than with it). The other factor is that you just don't really get "batteries included" in node... I wonder whether I'd be more productive in Django.
Do you have any further tips, experiences or resources on using Django with a frontend in React?
Thank you! Perhaps I'll write up my experience building EasyALPR here at some point.
I get the frustration with writing async in frontend. I wrote a pretty substantial SPA in vanilla js early last year for a client and getting the UX behavior to wait on itself just right could be maddening at times. (This was before I started learning React)
I have not written node yet, and do not know if you commonly need to use async await to build backend in JS.
Django only recently added the option to provide for async in the backend via ASGI.
I haven't enabled async for the new SaaS I'm working on--and I haven't needed it for the many other projects I've worked on with Django. (though I have used celery for task queues of long running jobs) From what I can tell it isn't all that popular yet, so it has that going for you. :)
If you're intent on building a React SPA, but want a Python backend and you haven't already picked up the Django way of doing things, it might be worth exploring FastAPI and perhaps SQLModel.
Django was not really built with type hints in mind, (python overall is behind the curve when it comes to types but that's another discussion). So when you're creating all the API endpoints you'll need for your SPA, there's a fair amount of duplication in Django Rest Framework.
FastAPI and SQLModel are built around Pydantic, which allows these class definitions to be this single source of truth for a bunch of things. I have not built a production application using these tools, however, it is obvious to me that this simplicity is the future of web application building in Python.
There is nothing really wrong with DRF and the Django ORM, especially given how stable and how well documented they are. However, I think if you're going to lean into learning them from scratch, you probably would want to try and take advantage of leaving some user flows to Django's view-template system.
Part of Django's "battery's included" are routing to traditional full page loads based on views and the Django html templating system. While Django doesn't really recognize SPAs as a fully qualified web application concept (perhaps because Pythonistas don't like Javascript). You can put a SPA React app on a Django template.
I have used a React SPA in a single Django application (WeeVee and had to pause that project for being too ambitious.
I did successfully combine a single React view that the user can visit on WeeVee and then return to Django views seamlessly. Combining the Django view-template world with the SPA view routing of React was borderline academic work compared to "just build it" stuff.
But, it was pretty dope once it was working, and I am hoping to have some React-based SPAs inside Django projects in the future.
I stubbed out a readme for a public project that describes the benefits of Frankenstein'ing react and django here but never released it. Since then there are several projects people have shared showing how to integrate the two.
Frankly, I think the Django core team and community are downright hostile toward "modern" frontend web development. They recently caught wind of HTMX and have been on that hype train because it keeps the power in the individual page load template philosophy inherit to Django.
I continue to use Django because I know the patterns very well, and use most of the batteries including the auth system. I also have invested a lot of time building out user auth (login / signup / forgot pass) and user profile settings using Django views in an abstract way so it can be re-skinned and used in additional SaaS products in the future.
Finally, I'd say that you want to keep your CI / deployment in mind as you're making this decision. If you can already rig up, say, a webpack-based react building CI flow, and artfully navigate NPM stuff, it may be worth just making a bet on Node.
This all won't really give an answer, you may have to just pick a direction and "run that way fast."
Thanks again for the this super thoughtful answer here. Really helpful!
I'd love to read a write-up of your experience building EasyALPR! I always find posts that document the "tech stack decisions" and how it all panned out amazingly useful, and really fun to read. Please do let me know if you write something up along those lines :)
You make some really good points above about how the Django philosophy isn't perhaps the perfect match for React SPAs. I was looking at a few open source projects that are using Django on the backend and React on the front (e.g. posthogs analytics product is a great example, worth looking at if you're interested). That being said, your comments are making me rethink whether I should give node a bit more of a chance (in truth it hasn't let me down yet)
The main challenges I've found with node is that most examples to build on/get inspired by are typically very simple backend services, e.g. just stand up express, write a few endpoints and serve your react frontend with the data it needs which can be called from components, your redux actions, etc. That's all fine, but once you need more complexity (e.g. what should I do for Auth, what should I do for DB migrations, how should I run tests?) There are quite a few different ways to go and I find the batteries included nature of Django appealing here because there's a strong community and robust set of tooling to handle stuff like this. One fear I have with the NPM ecosystem is that, while it's very vibrant, there are also a lot of abandoned packages and you really don't want these sitting around as a dependency in your backend. But who knows, perhaps I'm being overly prangy on that one?
Out of interest, what are you working on now? A new SaaS product?
You’re welcome. I’ll ping you if I publish something. These kind of look back posts seem coordinated to help promote the next thing. So, maybe when that’s ready.
I am familiar with Posthog, in that I’ve integrated their frontend and backend instrumentation into the current product I’m working on, but I haven’t looked at how react is mashed in. (Previously, I used Mixpanel and Amplitude).
I really like that company, looking at it from the outside, at least, though. Thanks for that tip.
I totally get the question marks when it comes to assembling a complete stack based on Node.
I’ve been trying to track JS for a while and it can seem like a house built on sand. Not because the individual solutions aren’t good, but because best choices seem to be vying for the critical mass of developers.
You mention redux and my first thought was, "oh, have they checked out React Query?"
I don't know the best choices for auth and ORM / migrations for JS right now, but for crying out loud, Node is big enough that there aught to be a set of solid options!
Much of the momentum seems to be in next.js land these days, and I searched just a bit and they have a package called
next-auth.For ORM it looks like Prisma is the thing, again typing is the jazz and it appears intended for use with TypeScript.
BTW, I don't think you'd get the full value out of staying in JS-land if you don't pick up and use TypeScript.
Not sure how these compare to what else has existed previously, I'd have to read a bunch, look for some recent podcast episodes etc. Because the slithery JS stack has molted a few times in the past 5-8 years.
On the Django side, you have the opposite "problem" though, which is that the maintainer of the primary API framework, DRF, had to sincerely reply to a public question of whether the project was still "considered alive.".
I find that shocking, as to me API is extremely important for web stack. I want Django to have all the bells and whistles or at least have them in progress.
On the Auth side, for Django, AllAuth is the undisputed king of extending the Django auth system to handle Facebook, Google oAuth2 signup and login. However, if you followed that project closely, the Sign In with Apple option took forever to meet the requirements of the maintainer.
Many people were dependent on this package and the community was using a fork with the mildly disputed PR because of all of the hemming and hawing about implementation details. Django and its major packages are like a mule in this way.
All that said, if the goal is to build a SaaS that makes a bunch of money, and hopefully sell the thing too, probably picking the mule is the best option. You're not supposed to focus too much on cool or forward-looking tech when trying to build stuff. You're supposed to build cool stuff as fast as possible.
Again, if you haven't done a CI implementation of frontend already, I think webpack stuff is kinda nuts. I rewrote much of CRACO's documentation learning including this entire section how truly buggered it is.
If anything, I think the hangup is that you really want a React SPA for your app. I bought Kent Dodd's Epic React course before putting aside React for a bit and revisting it, there's this big FAQ item responding to a question about the author re-writing the whole course for TypeScript. :P
Looking at the author's activity, they are right now focused on rewriting his entire site in Remix. Which seems to compete with Next.js.
FFS, I think just tapping on JS stuff for this reply has convinced me not to head over to node any time soon. I almost wonder if people who sell courses like JS because it is constantly shifting and people are buying information on how to build the next thing.
Perhaps it is worth asking what is it that you need an SPA for in your product you have planned? Could it be accomplished using a mix of JS packages or even just on-page includes and for super custom stuff just whip up ES6? You know, lean into the awaits and such?
Javascript knowledge is still handy working with loading individual pages in Django. I use it extensively to customize UI and when I need a library, I am not managing it with NPM so I have yet to even build a webpack workflow into my CI.
I'm just checking libraries into the assets/js folder of the project! Funny thing is, there is nothing wrong with this, it is just so passè!
--
My new SaaS project is called Chief of Staff.
Give Chief of Staff a link to an article and it gives you a high-quality audio reading of it back.
My goal is for CoS to make it easier to digest information when you can't stare at your screen, and to be able to pause, annotate and share passages of audio way better than what can be found right now.
My ambition for it is that it act as your "personal braintrust and gatekeeper" on the internet. It finds information on topics you care about.
CoS should brief you on your topics of interest each morning (i.e. Apple product leaks) and while you're going about using the internet, CoS literally screens out comments from trolls, indicates bad or outdated information (jquery-based js solutions), etc on any page.
Anyhow, CoS is not ready yet but its getting there! I am not quite ready for the build in public thing, but maybe after I have production to a point where I'm not blowing away and rebuilding the DB every few days. :)
I am curious about what you're working on / planning.
Yeah please do ping me if you publish something (I'll send you an email now too so we can stay in touch).
Thanks for the tip on React Query I really like React Table and have used it a fair bit in projects - it's really powerful. I know redux has a lot of boiler plate, and probably could use a bit of a review of state management stuff, so I'll give React Query a whirl on a test project sometime soon!
Totally agree that using TypeScript makes sense in JS-land these days. I'm not currently on the next.js wave, but it does seem like that's super popular right now...
On the posthog stack, i'd say it's worth looking at, I quite enjoyed running it all locally on my machine and playing around... since you've got a strong background with Django you might find it interesting for sure
I think I might try and block a few weeks soon to review what's going on in JS-land and also play around with Django a bit, see which one feels more productive to use a backend right now for a React SPA...
Anyway, I'll stop writing here now and finish this off in email!
Django user since the 1.1 days.
Why I choose it? I liked python and django was (arguably still is) the best choice for a web project in the python space.
Choose a framework after the programming language you know or want to learn. Don't learn a programming language after choosing a web framework.
Django is "just python" with batteries included.
best source to learn?
Are you are new to all aspects of python web development?
If you want to learn Django but also need to learn things like creating a virtual environment and how dependencies work (must have knowledge) I recommend Tango with Django.
The most recent version focuses on Django 2.x, which is a full version back. However, all of the basics for getting started will work just fine in 3.x. The authors offer a 45 day guarantee, so its really risk free if you don't get a lot out of it. Perhaps not the hippest learning resource, but it is a good one.
Thanks, not new at all, just haven't done Django specifically since 1.x - trying not to give my age away now!
Ah, Two Scoops of Django has a 3.x edition I’m open beta rn
Cool, I've got a version from June 2020 that I was given by a co-worker...I've never opened it if you recommend it I will give ita try! Thanks
You're welcome. I think it is worthwhile to familiarize yourself with best practices there.
It is also helpful to just go through some of the bigger django community projects and read the code.
I agree with all the pro Django sentiment in this thread. It does make a lot of things very easy. It's not that hard to learn and the documentation is the best I have seen.
I have stopped using Django and switched over to Node because most the mass in web development is in Node these days, and this might a controversial opinion - JS is just fun to work with!
So this is super interesting, because I feel like I'm sort of going the other way. I really like React, and JS on the frontend is a 'must' in web dev... but I've just never gotten along with the async nature of node, and have ended up frustrated once backends got more complicated with constant async-await patterns everywhere...
How are you finding the switch from Django to JS overall, are there key areas you're finding node is working better for you?
I don’t really mind the async await pattern. I much prefer it over using callbacks.
The biggest areas, for me, in which node is an improvement over Django are
I think there is a lot of value to this. Also, with deno in the wings, js seems to have a bright future ahead on backend.
I'm curious, you did not mention typing / typescript. Have you taken advantage of this innovation In js land?
I did use TS for only one project. I haven’t used it since and for no particular reason. Just didn’t see much value for setting it up for subsequent projects.
From my understanding, it is an investment up front but moves QA "to the left" reducing the amount of bugs created and need to test for bugs in JS. May be worth another look.
Yeah totally good points here! And I agree that async await pattern is a lot better than callbacks (they generally are fine until the API method becomes more complicated, e.g. having to do a fair amount of data processing etc. I think I prefer python for that)
I'd be really interested to hear more about your go to node + extra services/libraries stack, e.g. are you using express as the base framework? building REST APIs or going with graphQL? What are you preferring to use for authentication, testing, etc? and are you doing anything with DB migrations there too? (E.g. something like knex)... Would be super interesting to hear what you think works well as the batteries (which aren't included in node but I guess do tend to come along with Django, e.g. migrations, admin panel, standard patterns for auth etc)
I agree that python is better for data processing and when that is required I generally stand up a new python service while keeping the front line web server logic in Node.
My go to stack is Express+Knex+Postgres. For auth I generally use cookie based session with Postgres to store the session data server side. If the app is or becomes highly trafficked, then I move the session storage to redis.
I haven’t found a good solution for admin panels yet. What I am looking for is a drop in library in which you can define models and register routes and it will take care of the rest for basic CRUD serverside. Client side my go to is react-admin.
And I haven’t had the time/motivation to grok graphQL yet, and I heavily use REST for building APIs
Thanks for this insight! I'm totally onboard with your express+knex+postgres choice and keeping it to REST (I've played with graphQL a bit, and mucked about with services like hasura which are neat... But still I'll default to a rest API)... When I've needed more complex Auth (e.g. mobile sign-in) I've gone with firebase and used their client and server side libraries (but only if absolutely needed)
Interesting on the suggestion of starting up a smaller python service for doing more complex data processing stuff... Thats definitely one way to go!
I’m also curious about your experience in Node as a backend. I have a lot of Django experience but have become disillusioned by what I see as an almost hermit-like mentality from the Django community. The framework is playing major catch-up—it lacks strong typing and the ORM lacks async.
Meanwhile, the actual dev community is downright nerdy compared to the bustling bazar-like feel of JS right now.
If you’re looking to make money, and build quickly, I think the boring and sort of dated nature of Django has a ton of benefits because shiny is distracting from “done.”
That said it is kind of a bummer to feel like Django could be much cooler and more modern. I mention this above but FastAPI is really showing how it’s done right now with typing.
I went with Django because I had fresh previous experience with it, and I wanted to focus on the product, not learn a new framework and language.
My other option at the time was Flask – I went with Django because it has more batteries included that I expected to need – ORM, form validation, templates, authentication system, admin. There would be more plumbing with Flask. I would have probably chosen Flask if the project was more API-focused than UI-focused.
Django is awesome and I am grateful it exists, and I can use it. Same with Python. And many other OSS projects. It's brilliant we have so many powerful tools to choose from.
Yeah totally agree! Thanks for sharing on this one.
Out of interest what's happening at the front-end layer of your current project? Are you mixing in another frontend framework or using pure Django back to front?
Pure Django – server-rendered HTML, forms run HTTP POST and reload the page. A mix of vanilla JS and jQuery. Bootstrap as a starting point for styling.