Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

simplecto.com

Post reply on HN
Print view View original

301–310 of 347 posts

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

#301

Post by TekMol »

simplecto wrote: post #272
TekMol wrote: post #137

Is 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.

Putting them in the same container means I have to manage the processes myself with something like supervisord. A docker-compose file makes this trivial because it is just a matter of a few lines of YAML that link the services together. It also means I can ship updates to my application and restart it without touching the rock-solid Postgres image.

What do you mean by "manage the processes"?

Why would you need to touch postgres when updating your application?

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

#302

Post by blandflakes »

StavrosK wrote: post #299
blandflakes wrote: post #296

Earlier quoted context omitted.

Ah, so the answer to "do you interact with scientists" is no, even though scientists are responsible for a huge amount of the python code that exists. Got it, maybe consider that your experience isn't universal. I don't know why you think dismissing legacy code is valid! More code is old than new in the world, and the idea that you're only going to run into codebases with the most up to date versions of software seem…

> I don't know why you think dismissing legacy code is valid! Because everyone everywhere has legacy code. In that sense, Python isn't split between versions any more than any other language, making that statement moot. If you want to use type annotations, you can, for years now. If you want to use macros to generate macros in Rust, you can, it's not Rust's fault if you're stuck on 1.20 and don't want to upgrade.

I agree that all languages have legacy code, that was sort of my point :)

> If you want to use type annotations, you can, for years now.

Yes! And it's a cool feature. Can I expect most libraries to provide types so that I know I'm calling them correctly? Is it going to be an uphill battle for my team to use them, because the community at large doesn't find them necessary? The default for a majority of Python codebases is to not use types, and that's totally fine, but that also means that rather than type annotations solving the super-grand-OP's concern, they're going to potentially add friction.

It's likely, and that's FINE, that you're going to be in dynamic-land when you're working in Python, due to the preferences of the community, and it's cool that you can use annotations if you yourself want to get some nice signature checking.

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

#303

Post by StavrosK »

blandflakes wrote: post #302
StavrosK wrote: post #299

Earlier quoted context omitted.

> I don't know why you think dismissing legacy code is valid! Because everyone everywhere has legacy code. In that sense, Python isn't split between versions any more than any other language, making that statement moot. If you want to use type annotations, you can, for years now. If you want to use macros to generate macros in Rust, you can, it's not Rust's fault if you're stuck on 1.20 and don't want to upgrade.

I agree that all languages have legacy code, that was sort of my point :) > If you want to use type annotations, you can, for years now. Yes! And it's a cool feature. Can I expect most libraries to provide types so that I know I'm calling them correctly? Is it going to be an uphill battle for my team to use them, because the community at large doesn't find them necessary? The default for a majority of Python codebase…

But you don't need the libraries to have type annotations for them to be useful to you. You can use the libraries' classes as types, and type signatures are already very useful even if you only use them in your code. I agree that they will be even better when morelibraries declare them too, but I find that type annotations are a huge benefit in my own code either way.

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

#304

Post by blandflakes »

StavrosK wrote: post #303
blandflakes wrote: post #302

Earlier quoted context omitted.

I agree that all languages have legacy code, that was sort of my point :) > If you want to use type annotations, you can, for years now. Yes! And it's a cool feature. Can I expect most libraries to provide types so that I know I'm calling them correctly? Is it going to be an uphill battle for my team to use them, because the community at large doesn't find them necessary? The default for a majority of Python codebase…

But you don't need the libraries to have type annotations for them to be useful to you. You can use the libraries' classes as types, and type signatures are already very useful even if you only use them in your code. I agree that they will be even better when morelibraries declare them too, but I find that type annotations are a huge benefit in my own code either way.

I think we can agree on that - my point primarily is that:

1. In my own code, they are super helpful

2. I still get really frustrated when I'm calling other libraries (I had this experience when the various typed JSes were fighting it out as well) - in fact for a lot of web-style work that I do MOST of my code is calling a library, which is where I'd get most of the value.

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

#305

Post by yjftsjthsd-h »

antidocker wrote: post #211
laingc wrote: 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…

If you think Docker helps with Sandboxing, you're mistaken. Docker is a huge security hole. Oh, Crypto miners ....

Explain? I'm aware that giving a host user permission to control Docker is equivalent to root, but that's no worse than wheel/sudo in most cases, and not a "sandbox" failure. So I assume you're thinking of container escape, which I was given to believe is actually hard these days?

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

#306

Post by sofixa »

hankchinaski wrote: post #244

the issue I had with this setup is that without a systemd or any daemon you might need to firefight and manually restart your containers each time there is an issue

You can tell docker or docker-compose to always/on failure/unless stopped restart your containers.

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

#307

Post by StavrosK »

blandflakes wrote: post #304
StavrosK wrote: post #303

Earlier quoted context omitted.

But you don't need the libraries to have type annotations for them to be useful to you. You can use the libraries' classes as types, and type signatures are already very useful even if you only use them in your code. I agree that they will be even better when morelibraries declare them too, but I find that type annotations are a huge benefit in my own code either way.

I think we can agree on that - my point primarily is that: 1. In my own code, they are super helpful 2. I still get really frustrated when I'm calling other libraries (I had this experience when the various typed JSes were fighting it out as well) - in fact for a lot of web-style work that I do MOST of my code is calling a library, which is where I'd get most of the value.

Sure, I agree with that. More libraries supporting types would be great. I don't know why they don't, it's not like they need to support any Python versions that don't support types... I guess most just haven't gotten around to it.

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

#308

Post by acdha »

treis wrote: post #287
acdha wrote: post #67

Earlier quoted context omitted.

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.

I used to think the same way and still kind of do. But you're neglecting another performance benefit. You have ~100 ms to respond to a request before the user perceives slowness. With Go you can do 10-100x more stuff in that timeframe.

Or 0 to -100x more stuff. The vast, vast majority of code is limited by the application’s workload and architecture, not the language runtime. I remember a colleague spending 3 months trying to beat Python using Go, eking out a single digit increase because it turns out that the Python stdlib C code is not easy to beat. For web apps, this is especially common: if 95% of your runtime is in the database or other external services, Amdahl’s law reigns supreme.

The other experience point which a lot of people forget the first few times is maintenance: if using Go means that you have notably more code to write and integration to support, you’re shipping fewer features and have less time to optimize the architecture. That Go code I mentioned earlier was much larger and required time to identify, integrate, and debug third-party libraries for things which are in the Python standard library.

This isn’t to say that Go is a bad choice but again a cue to make sure you’re solving the problems you actually have rather than someone else’s situation. If you’re still exploring the business case you should hesitate before copying a decision made by someone with both a well understood problem, large scale, and more people working on it.

In this thread’s context, I would highly recommend focusing on keeping the architecture easy to support and replace components when the business expands to the point where you really need to hammer specific optimizations. This is especially true in the 2020s where a large fraction of problems are either never exceeding single server scale or can be handled by trivially autoscaling containers on-demand for less than it’d cost in developer time to optimize them beyond the level you can hit in a language like Python or Node.

Again, that doesn’t mean there’s anything wrong with using Go – it’s a perfectly fine choice and has some great libraries — but it usually won’t be transformative the way some advocates claim. When you hear about huge benefits from rewrites look for how often they mention rearchitecting based on what they’d learned from the first system.

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

#309

Post by acdha »

cbushko wrote: post #76
acdha wrote: post #69

Earlier quoted context omitted.

> Yes, you can patch them but with a compiled binary like go, you don't have to. > You don't have to watch security lists for vulnerabilities. These two statements are incompatible. You have fewer things to watch but you’re definitely still going to track your dependencies. Static linking still means you have to do that, and nobody else can do it for you.

Not exactly. You have to watch your libraries for vulnerabilities no matter what language you use. Link or apt-getting the library will pull in a vulnerability I am more concerned about pulling in Linux binaries that are full of vulnerabilities.

This is a valid concern but in general you should be most worried about code you actually run. If you have curl in a container but your app only uses it during the startup process, the fact that it has an issue with, say, FTP almost certainly has no effect on you. OTOH, if you’re using something like libjpeg your Go code needs to be recompiled either way and you might have to manually backport a patch just like a Linux distribution will.

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

#310

Post by danjac »

recursivedoubts wrote: post #262
danjac wrote: post #168

Earlier quoted context omitted.

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…

htmx supports the `hx-preserve` attribute since v1.1: https://htmx.org/attributes/hx-preserve/

Good to know! Didn't see it in the attribute reference list.
Post reply on HN