Goto stack for building SaaS is the one you know the best.
Yeah good luck getting something to market quickly if you aren’t in any way familiar with any of those technologies
Docker, Django, Traefik, and IntercoolerJS: My go-to stack for building a SaaS
161–170 of 347 posts
Re: Docker, Django, Traefik, and IntercoolerJS: My go-to stack for building a SaaS
#162Earlier quoted context omitted.
How do you debug (in dev or prod), or in production, do things such as inspecting log files, monitoring system resources, running necessary commands if there is something urgent...? In my experience, Docker just makes everything more tedious without tangible benefits. I personally lose nothing by not using Docker and am much faster in everything I do.
How much experience do you have with Docker? I am not being snarky -- all the things you say sounds like something I would have said until I pulled myself together and learned how to use it properly. And granted, that did take a bit of effort but now my perspective is that Docker is extraordinarily easy to work with. A Dockerfile is almost exactly like your requirements.txt file, only it works for everything. Need Im…
I don't have a lot of experience with Docker, but it's not what's holding me back. Here are some of my pain points:
1) Having to "docker exec" to get a shell in a running container vs just running the command (in dev) or sshing into the server (in prod).
2) Tests taking 3:30 min to run with docker vs 30 secs without. And then of course, you don't just run tests once but many times, leading to tens of minutes on a given day where I'm just twisting my thumbs.
3) Having to even spend time learning how to debug Python code inside a locally running docker container.
4) Having to deal with disk space issues caused by old docker images on my 500gb hdd.
All while not deriving any value from it in my projects.
Re: Docker, Django, Traefik, and IntercoolerJS: My go-to stack for building a SaaS
#163I really like the authors philosophy. Too many developers use a bunch of tools, and you get the impression that it's just for the sake of tooling, or because that's how you're expected to do things. You can keep scaling a single server and deploying via simple git hooks for years until you need a more fancy setup.
Especially for side projects, you want to use the minimum amount of tooling that gets out of your way so you can focus on building a great product. To me, a weekend spent doing auxiliary or unessential stuff like configuring Kubernetes or whatever feels really fatiguing and demotivating when you don't have a lot of time to work on the project otherwise.
Re: Docker, Django, Traefik, and IntercoolerJS: My go-to stack for building a SaaS
#164Can anyone answer why python is a choice anymore instead of i.e. golang for saas applications like this? I previously worked heavily with ruby and I cannot imagine building beyond >1000 LoC in interpreted, dynamically typed languages. Aside from developer familiarity which trumps all other points. It's also significantly easier to dockerize a generated binary from golang or rust, etc. Some of my worst docker headache…
You have to reach massive scale before you’re going to see a significant performance benefit from Go, but you’ll see productivity wins from Django from day one. If you’re not targeting that kind of public scale and don’t have a large team, there’s a lot to be said for picking a mature stack on a high productivity language.
Exactly this. Developers and their managers and the CTO must accept most likely their work/company does operate a huge scale.
Once you internalize that your priorities change from all the tech hype (k8s, react, whatever) to actually working on the business problems. Not solving technical ones.
Re: Docker, Django, Traefik, and IntercoolerJS: My go-to stack for building a SaaS
#165Earlier quoted context omitted.
PyEnv + Poetry — Couldn't be easier IMO.
Except plain old virtual environments instead of poetry. And pyenv only if really really necessary, and not in prod.
Ah, see, this is the perfect example of why Docker helps, especially with Python: consistency.
The team would no longer have to make these deployment decisions and argue about which tool is a better fit. They'd make the decision once, hopefully follow best Docker practices (unprivileged user, multi-stage builds, etc.), and have documentation available for how to integrate the setup with IDEs, work with volumes, etc.
Once this initial adoption hurdle is overcome, IME the productivity gains are greater than the issues of dealing with Docker. It becomes trivial to setup CI/CD, onboard new developers and integrate the app into other workflows.
Docker and containers in general have become mature enough to prove their use case and benefits, so the cargo cult argument doesn't hold weight for me.
Re: Docker, Django, Traefik, and IntercoolerJS: My go-to stack for building a SaaS
#166I don't get why people use Docker for "small SaaS apps" where "scale is not an issue". You can run everything without Docker to remove an extra level of indirection. I've been doing that exact thing with a very similar Django stack for years. Not once have I missed Docker. On the other hand, I have taken over SaaS projects where the (unnecessary) usage of Docker made it more expensive to host, decidedly more difficul…
It’s too fucking hard to setup python with all its pyenv, anaconda, poetry, pip requirements.txt and what-not, that’s the best use case for Docker here. Get it to work once and forget about it.
Is it? I've been riding on bare virtualenv and pip since around 2014, maybe longer.
Inside containers and without Docker alike.
Re: Docker, Django, Traefik, and IntercoolerJS: My go-to stack for building a SaaS
#167IntercoolerJS / htmx looks like a really cool solution for server-side rendered HTML with client-side interactivity. All the hype is currently with https://hotwire.dev/ but htmx has more features, seems more solid and even supports older browsers like IE11.
[deleted]
Re: Docker, Django, Traefik, and IntercoolerJS: My go-to stack for building a SaaS
#168IntercoolerJS / htmx looks like a really cool solution for server-side rendered HTML with client-side interactivity. All the hype is currently with https://hotwire.dev/ but htmx has more features, seems more solid and even supports older browsers like IE11.
The libraries cover a similar ground, but there are some fundamental differences. With Turbo, by default all your links/forms will use XHR to fetch new pages which do a full body swap (unless you want to use frames/streams or opt out entirely), whereas with htmx you have to be specific which links/forms and targets you want - there is an hx-boost attribute that does something similar but it lacks a corresponding data-turbo-permanent attribute (at least in the current production version) when you want to exempt certain elements. Both are valid approaches but it depends on what suits your requirements better.
Re: Docker, Django, Traefik, and IntercoolerJS: My go-to stack for building a SaaS
#169Is there a benefit of running Postgres and Django in different containers? By putting them in the same container, things could be a good bit simpler. And I don't see any downside here.
Docker monitors only main process. If side process fails docker will do nothing about it. Means if you want to put multiple apps inside single container you have to add some manager guy to keep an eye on all the processes (e.g. supervisord). Plus in case with separate containers the layers cache is reused better.
Why do you need Docker to monitor it? I would think it will only recognize a problem if the process dies. But you need to monitor your db and application for other types of failures anyhow, right? I cannot remember the last time I had a problem with the DB process dying.
Re: Docker, Django, Traefik, and IntercoolerJS: My go-to stack for building a SaaS
#170Is there a benefit of running Postgres and Django in different containers? By putting them in the same container, things could be a good bit simpler. And I don't see any downside here.
Single responsibility - that same container is gonna get shipped to prod/etc. I would hope the database isn’t in the container there!
I would think the database data does not live in the database container but is mounted into it?
If you update you database version, you do not ship the database data to production either.