Live data from Hacker News

Docker, Django, Traefik, and IntercoolerJS: My go-to stack for building a SaaS

simplecto.com

321–330 of 347 posts

Re: Docker, Django, Traefik, and IntercoolerJS: My go-to stack for building a SaaS

#321
post #316
post #281

Earlier quoted context omitted.

Denigrating any subjective experience because it's "too direct" is bordering on passive aggressive. Every suggested edit you've made to the comment completely alters the meaning of the text: you're basically saying that if you're not looking to learn and completely disregard the veracity of your own experience in every statement you do, you're better off not saying anything at all. It strikes me as exceedingly dishon…

> you're basically saying that if you're not looking to learn and completely disregard the veracity of your own experience in every statement you do, you're better off not saying anything at all. That's really not what I'm trying to say at all. If I had to condense it down to one sentence it would be: "if there's a difference in opinion between two reasonable people, it's probably because you've had different experie…

> If you're not interested in somebody's opinion, what value could there possibly be in having a discussion with them?

Not every comment on the Internet is an invitation to discussion, and the discussion is not exclusively between two people. A lot of comments are just responses about why someone disagrees or agrees with what was just said, which is allowed.

Re: Docker, Django, Traefik, and IntercoolerJS: My go-to stack for building a SaaS

#322

Earlier quoted context omitted.

"apt-get update && apt-get upgrade" You can do this exactly the same in alpine, with "apk update" and "apk add". "Secondly, all this cargo-culting around small containers is fine if you are cramming resources. I am not." The default docker python image is 885MB. python:buster-slim is 114MB which is much more reasonable. Even if you're not "cramming resources", pushing 885MB vs 115MB vs 20MB across the wire does add u…

Shouldn't the base image be cached? So you would not be pulling it all the time.

If it's cached, yes. However at my job we manage our own base images and we do update those somewhat frequently.

Re: Docker, Django, Traefik, and IntercoolerJS: My go-to stack for building a SaaS

#323
post #169
post #156

Earlier quoted context omitted.

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.

That's default behavior. Docker tracks the main process. If it dies, and your database is not the main process, then the entire container will be restarted (depends on configuration). Means your database will be forcefully killed. At some point you might run into data corruption incident.

If you make database your main process, then docker will be blind for your application death.

Re: Docker, Django, Traefik, and IntercoolerJS: My go-to stack for building a SaaS

#324
post #109

Earlier quoted context omitted.

Allow me to offer a counterpoint. Docker is useful for reasons besides scale. It allows you to (kind of) declaratively define your environment and spin it up in any number of different scenarios. It allows you to ship all your dependencies with your app and not worry about getting the host machine properly configured beyond setting up Docker and/or Kubernetes. Have other apps you want to host on the same set of machi…

Python apps have worse performance, bigger image size and longer build times on Alpine Linux: https://pythonspeed.com/articles/alpine-docker-python/

Thank you for sharing that! It has never occurred to me but that makes sense.

For my Go/Haskell binaries, I usually do need to make changes in order to get them working. The smaller image size is essential in my use case though so I pay that penalty.

Re: Docker, Django, Traefik, and IntercoolerJS: My go-to stack for building a SaaS

#325
post #117

Earlier quoted context omitted.

This kind of thinking is why engineering departments have tech debt.

I get your point but don't think you're getting mine. In a bigger project / organization? Yes, let's have those processes and tools. But for simple apps as described in the article? Use a correspondingly simple solution. As always in software development, it's all about context.

I agree. With you and with the other opinions (why should only one perspective be right?).

I've been the lead developer on teams where I introduced Docker to solve consistency/reproducibility issues in AWS and Azure.

I've also done smaller applications in DotNet Core, Go, Node, Python, and Ruby. In those cases I've use other alternatives, including:

- Known Linux version, with git push-to-deploy (my favourite)

- Packer (the server), with embedded codebase (still quite simple)

- Docker (for most non-trivial deployments)

- Known Linux version, with chef or ansible (as an alternative to Docker)

- Terraform the machine, upload the codebase, run scripts on the server (ugh)

Every method had it's place, time, and reason. If possible, for simplicity, I'd go with the first option every time and then the others in that order.

The thing is, though, I may have an order of preference but that is totally overridden by the requirements of the project and whether or not the codebase is ever to be shared. For solo projects and small sites, I've not benefited from Docker as I have never had any server/OS issues (and I've been doing dev stuff for decades).

However the moment there was a need for collaborators or for pulling in extra dependencies (and here is the crunch point for me) such as headless browsers or other such 'larger' packages, then I would move on to either Packer/Terraform for fairly slow-changing deployment targets or Docker for fast-changing targets, as otherwise I inevitably started to find subtle issues creeping in over time.

In other words keep it simple while (a) you can and (b) you don't need to share code, but complexity inevitably changes things.

Re: Docker, Django, Traefik, and IntercoolerJS: My go-to stack for building a SaaS

#326

I 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 not about docker per-se but repeatable, immutable infrastructure, a great boon to productivity and portability to local or cloud environment. "Cattle vs. pets"

Sure, you can do similar with ansible or puppet, but use something.

SSHing into boxes to fix things wasn't good enough in the 90's, one reason I looked into building .debs back before the turn of the century. cough

Re: Docker, Django, Traefik, and IntercoolerJS: My go-to stack for building a SaaS

#327
post #286

I feel like an idiot reading these kinds of posts. If this is a “simple” stack, then I’ll be jiggered. Why do you need a “control plane” like ZeroTier? What problem does it solve? Certainly not a problem I've ever had. And I have a real SaaS business which people pay real money for. I've been developing enterprise SaaS for 10 years. My go to stack for small projects where scale is not an issue is Laravel, Laravel For…

The explosion in stack choices means no one can know them all. Also, even simple apps can have one or two areas where things get a bit complicated. "Simple" is relative and inadvertently implies things the author is familiar with.

I'd guess sqlite (for example) is fine for very simple apps with one user at a time, but that bar is pretty low. Yaml itself is not an issue, and intercooler/htmx is simpler than your JS picks. shrug

Re: Docker, Django, Traefik, and IntercoolerJS: My go-to stack for building a SaaS

#328

Can 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…

If compute performance is not a requirement, python is a lot faster to develop in. Once the design has solidified, a few simple techniques can improve reliability to an acceptable degree.

Re: Docker, Django, Traefik, and IntercoolerJS: My go-to stack for building a SaaS

#329
post #136

Earlier quoted context omitted.

This is a pretty common sentiment on HN and I’m sure you have your reasons for it, but to me personally it just seems bonkers. Docker is an absolutely game-changing tool for me. I can’t count the number of times it’s saved me from completely screwed up system libraries, tools installing config files in weird places, conflicting versions of this or that, or other versions of system pollution. I write a simple docker-c…

Sure, we're all just talking about our personal experiences. I just haven't run into the problems you describe. I use virtual environments to keep my system installation clean, and PostgreSQL / Nginx are so stable that the version I happen to have on my dev machine usually works with all my projects dating back to 2014 (but kept up-to-date).

It sounds like you have a small or even solo team. That could play a big role.

Re: Docker, Django, Traefik, and IntercoolerJS: My go-to stack for building a SaaS

#330
post #38

Earlier quoted context omitted.

That is a double edged sword. Sure, that dynamically typed language of python or ruby might be quick to develop on but they often contain a lot of surprising bugs. Compilers catch a lot of bugs before your software is in production.

Tests catch bugs too. As will pylint and mypy.

Even pyflakes will catch the most numerous bugs.
Post reply on HN