Hacker News Reader

Hacker News

Comment by thrwwy90876 | Hacker News Reader

Parent Full thread

thrwwy90876

It's build tools. This is like complaining that Xcode is many gigabytes.

View on HN

I never had to install a new copy of xcode for every project.

So the problem is not the size, but that you want to have a single cache of all the npm modules?

And, what about OS X, it takes a huge amount of space... and they install things I never use!

It's almost as if these things run on code!

These kinds of comments are against HN guidelines FYI.

You're right, I was not in the best light last evening. My apologies to the community.

Xcode is from a single vendor, whom I trust as much as I trust the operating system.

With rails and npm I probably trust Rails and see them as license-wise ok, but due to version requirements I might get "newer" versions of a package, which hasn't been veted by Rails devs, might use different license, might do stuff I don't want it might add in even other new deps.

Then all you have to do is specify the specific version you want in your package.json, rather than a semver range, and you'll never get a version you haven't explicitly approved.

Of each of the dependencies Rails installs.

don't use an opinionated framework then?

I don't upload xcode.app to apple every time i submit an iOS app. I do npm install on every build on heroku.

Then maybe don't use Heroku and use something that can work with a finished build?

It's not complicated to set up a build container locally and ship only your final result to a service that can run it.

Just build locally and vendor the asset artefacts. That's how we did it in the "good old days". No containers in containers needed.

To be clear, you don't do "containers in containers", you build a container and you copy your assets from the other one. You then have a shippable artifact with all your dependencies, including your runtime, vendored into it.

I'm not a k8s guy, but it's a lot nicer than a tarball.

Heroku provides value in other ways for us. We run on a number of other solutions, most involve shipping a ~100mb image. This can be dramatically reduced in size with a slimmer base image, which we plan on doing eventually.

In this case, heroku handles a lot of things we otherwise need to do ourselves: - DB + backups + DR - Network security - Network routing - SSL certs - Easy scaling of resources - Access control to operations (redeploy, restart etc) - Audits of operations etc

We can do all these things, and under various compliance frameworks, outside of heroku; its just exhausting and expensive. This project we want to focus on the product so we opt for heroku as it was a few lines of bash we were all familiar with to get up and running nearly prod ready.

Reply on news.ycombinator.com