Live data from Hacker News

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

simplecto.com

81–90 of 347 posts

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

#81
post #38

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…

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.

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

#83
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.

There's no difference between a 1000MB or 10MB image, aside from how much time it takes to download new versions and how much disk space it uses.

Debian slim is certainly not 1GB. It is maybe 50-60MB larger than Alpine. And that is shared if you have multiple containers based on Debian slim.

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

#84

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…

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

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

#85
post #65

Earlier quoted context omitted.

What's the Django/Rails equivalent in Go? The value from Python isn't Python itself (though it might be easier to write in - trading off reliability for ease of use compared to a compiled language) but the ecosystem. Fully-featured frameworks such as Django, Rails, etc give you lots of functionality out of the box which is very valuable especially at the early stages of the project where performance isn't a concern y…

Honestly, frameworks like Rails or Django are an anti-pattern for Golang. The standard library makes it very easy to build web services and there’s a couple or popular packages for making routes and dealing with HTTP requests/responses simple. There’s projects like Micro that try to do a little more batteries included but I wouldn’t consider them to be pervasive in the way Django or Rails are. Beyond that, it’s just…

Contrary perspective: only avoid frameworks when you can be assured your project is (and will remain) so narrow that it has no need of validation libraries and the like.

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

#86
post #65

Earlier quoted context omitted.

What's the Django/Rails equivalent in Go? The value from Python isn't Python itself (though it might be easier to write in - trading off reliability for ease of use compared to a compiled language) but the ecosystem. Fully-featured frameworks such as Django, Rails, etc give you lots of functionality out of the box which is very valuable especially at the early stages of the project where performance isn't a concern y…

Honestly, frameworks like Rails or Django are an anti-pattern for Golang. The standard library makes it very easy to build web services and there’s a couple or popular packages for making routes and dealing with HTTP requests/responses simple. There’s projects like Micro that try to do a little more batteries included but I wouldn’t consider them to be pervasive in the way Django or Rails are. Beyond that, it’s just…

>Honestly, frameworks like Rails or Django are an anti-pattern for Golang.

Which is, IMHO, the biggest thing holding Go back. The standard library does a lot but a lot is also missing. Authentication, db migration, admin panels, ORM, Asset pipeline and probably more. It's a lot of custom work to do or pulling in various libraries.

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

#87
post #65

Earlier quoted context omitted.

What's the Django/Rails equivalent in Go? The value from Python isn't Python itself (though it might be easier to write in - trading off reliability for ease of use compared to a compiled language) but the ecosystem. Fully-featured frameworks such as Django, Rails, etc give you lots of functionality out of the box which is very valuable especially at the early stages of the project where performance isn't a concern y…

Honestly, frameworks like Rails or Django are an anti-pattern for Golang. The standard library makes it very easy to build web services and there’s a couple or popular packages for making routes and dealing with HTTP requests/responses simple. There’s projects like Micro that try to do a little more batteries included but I wouldn’t consider them to be pervasive in the way Django or Rails are. Beyond that, it’s just…

Can golang auto generate forms based on database models?

An alternative explanation for why there is no Django for Go is that Go is not expressive enough to support such levels of abstraction.

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

#88
post #86
post #65

Earlier quoted context omitted.

Honestly, frameworks like Rails or Django are an anti-pattern for Golang. The standard library makes it very easy to build web services and there’s a couple or popular packages for making routes and dealing with HTTP requests/responses simple. There’s projects like Micro that try to do a little more batteries included but I wouldn’t consider them to be pervasive in the way Django or Rails are. Beyond that, it’s just…

>Honestly, frameworks like Rails or Django are an anti-pattern for Golang. Which is, IMHO, the biggest thing holding Go back. The standard library does a lot but a lot is also missing. Authentication, db migration, admin panels, ORM, Asset pipeline and probably more. It's a lot of custom work to do or pulling in various libraries.

I don't think Go will see something even close to Django until generics are merged.

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

#90
post #43

Earlier quoted context omitted.

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

> It's absolutely not scalable. And yet, somehow YouTube muddled along through and made it work.

And Instagram, and Dropbox (backend and client), and ...
Post reply on HN