Live data from Hacker News

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

simplecto.com

51–60 of 347 posts

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

#51

Earlier quoted context omitted.

Good news! Since ten years ago, you don't have to! def myfunc(foo: Dict[str, MyObject], bar: int, baz: str) -> List[MyObject]:

This would be nice if everyone used that. When I looked at the source code for mayan-edms, they weren't using that. Apache airflow? Doesn't use it. Jupyterhub? Doesn't use it. I was happy to see projects like Zulip using this, but if it's optional then I can't rely on people actually using it. It's the same thing with ruby/sorbet.

The projects that don't use it probably need to maintain compatibility with Python 2, for whatever reason. I expect that more and more codebases will be at least somewhat typed as Python 2 is deprecated everywhere.

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

#52
post #35

Earlier quoted context omitted.

For local development that debian container is fine but for production you want something small like scratch or alpine. The fewer binaries in the container, the better and more secure. This is one of the benefits of golang. You compile it into a binary and copy just the binary into your scratch container. Maybe it is 20MB in size.

This feels very hand-wavey to me. I can patch and ship my docker images the same way I might patch a server. apt-get update && apt-get upgrade rinse, repeat. Secondly, all this cargo-culting around small containers is fine if you are cramming resources. I am not. The reality is that my projects and many others are really, really over-provisioned. Looking at my graphs right now, I am on the front page of HN and my ser…

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.

You don't have to scan your docker containers because the dockerfile is 4 lines long.

You don't have to worry about a coworker adding a bad tool to your production container.

That frees up cognitive load to write your code.

Note: I am an infrastructure engineer for a small SaaS that builds and runs production.

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

#53
post #35

Earlier quoted context omitted.

For local development that debian container is fine but for production you want something small like scratch or alpine. The fewer binaries in the container, the better and more secure. This is one of the benefits of golang. You compile it into a binary and copy just the binary into your scratch container. Maybe it is 20MB in size.

This feels very hand-wavey to me. I can patch and ship my docker images the same way I might patch a server. apt-get update && apt-get upgrade rinse, repeat. Secondly, all this cargo-culting around small containers is fine if you are cramming resources. I am not. The reality is that my projects and many others are really, really over-provisioned. Looking at my graphs right now, I am on the front page of HN and my ser…

It's not only about the resources allocated to your project. Bigger images also leads to longer deployment times, which increases the feedback loop for issues. Not to mention increased costs associated with storage, bandwidth, layer caching, etc.

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

#54

Earlier quoted context omitted.

> I cannot imagine building beyond >1000 LoC in interpreted, dynamically typed languages Many have imagined and built valuable stuff in interpreted, dynamically typed languages before you, by being more focused on overall structure and making sure it's strict and resilient. One really doesn't have to search far for successful applications that are certainly way beyond 1000 LoC and still iterate pretty quickly for the…

"If you're just launching, your focus should not be on performance or how easy it is to dockerize but to figure out who your user really is." I agree here but I should note that my main focus is spending less time debugging errors at runtime and in production, and avoiding errors in the first place. This is primarily why I use rust. "Not sure the verboseness of either golang or rust" Verbosity has nothing at all to d…

I agree with you. I've worked at several startups and they start with 'productive' languages like python, ruby, and PHP. These are great for getting something up and running easily.

Everything looks great at the beginning. They have features, customers and a growing codebase full of technical debt. Debt that I think would be greatly reduced if the code was compiled.

Maybe it is the price you need to pay to be successful but I doubt it.

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

#55
post #20
post #14

He says "docker, just plain docker" but in reality uses docker-compose - in my view a significant addition. However it aligns well with my own sentiments - for anything below large scale complexity or scalability needs, docker-compose hits a beautiful simplicity vs power tradeoff.

Also, does this becoming accepted bother anyone else? "curl -s https://get.docker.com | sudo bash"

You can also just ignore that and get Docker from your package manager. At least on Debian it's in the official APT repositories and Docker.com hosts one as well.

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

#57
post #53

Earlier quoted context omitted.

This feels very hand-wavey to me. I can patch and ship my docker images the same way I might patch a server. apt-get update && apt-get upgrade rinse, repeat. Secondly, all this cargo-culting around small containers is fine if you are cramming resources. I am not. The reality is that my projects and many others are really, really over-provisioned. Looking at my graphs right now, I am on the front page of HN and my ser…

It's not only about the resources allocated to your project. Bigger images also leads to longer deployment times, which increases the feedback loop for issues. Not to mention increased costs associated with storage, bandwidth, layer caching, etc.

I'm quite opinionated here, but these things only matter at significant scale. Most one-person-SaaS or SMEs never really graduates out of the first pricing tier for this stuff.

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

#58

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…

It's most likely because of Django. Same would be for using Ruby for Rails.

It's also very unlikely you are going to write >1000 LoC (or honestly even >100 LoC) for any view function/API endpoint.

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

#59
post #43

Earlier quoted context omitted.

> I cannot imagine building beyond >1000 LoC in interpreted, dynamically typed languages Many have imagined and built valuable stuff in interpreted, dynamically typed languages before you, by being more focused on overall structure and making sure it's strict and resilient. One really doesn't have to search far for successful applications that are certainly way beyond 1000 LoC and still iterate pretty quickly for the…

> Many have imagined and built valuable stuff in interpreted, dynamically typed languages before you, by being more focused on overall structure and making sure it's strict and resilient. One really doesn't have to search far for successful applications that are certainly way beyond 1000 LoC and still iterate pretty quickly for their size. I once tried to get into a large Python project, and even the IDE (PyCharm) ha…

I agree that it's harder as the project gets bigger, but at the beginning you don't have to worry about that. By the time these problems become real limitations, you hopefully have a business and enough revenue to deal with them, which could include rewriting parts of or the entire application in a statically typed language if necessary.

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

#60
post #28

Earlier quoted context omitted.

I tried Django but I liked Laravel better. Because I knew it better. Exactly.

Fair enough. But Laravel is apparently cut from similar cloth so you'd be in agreement with the general philosophy here?

For sure as far as MVC frameworks go. Those are two of the best. I enjoyed Django when I worked on it. It was enjoyable to work in and had a lot of power. It was clearly a great framework. Also tons of big sites use it. And if a boss somewhere said they wanted the team to use it at some point in the future I would be totally happy about that decision.You cannot go wrong using django in the least as far as I'm concerned.
Post reply on HN