Hacker News Reader

Comment by bigyikes | Hacker News Reader

“Easily” — this has to be satire, right?

Why are we containerizing a React app? It’s literally just a bundle of JavaScript. I have to spin up a whole container just to run `npm start` locally?

I guess it’s kind of cool that they show how to put it behind Nginx? But it really makes me question the target audience here. You’re advanced enough to need your app behind a reverse proxy, but not advanced enough to know how to put some static files in a Docker container?

What if we just stripped away the Docker and nginx stuff? That would be how you do this “easily”.

View on HN

> I have to spin up a whole container just to run `npm start` locally?

I'm pretty sure that the intent there is to make your bundled JS/HTML/CSS be ready for deployment, not that you have to use the approach locally (outside of maybe checking whether the containers are built correctly and all of the assets are served).

If you have a container cluster that has your back end APIs and your DBs running in it, you can deploy your front end alongside those, with the web server running inside of the container that will serve the files.

Not the only way to do it, of course, but if you are already using containers (and perhaps appreciate the 12 Factor App principles), then this approach is rather pleasant. I can see myself linking a tutorial like that to someone, should I want to introduce them to the approach.

Yeah, this is a multi-stage build where the final image will have only the statically built content in it.

I agree, it's not as elegant as a fancy dedicated CDN and frontend CI setup, however in a lot of organizations the frontend is an afterthought so it has to be able to be deployed in the same way as backend services.

The frontend team will also likely need to tweak various HTTP headers, but in a lot of organizations the internet facing reverse proxy is controlled by an operations team, not the frontend team.

My personal-projects server has 30-odd docker containers for various DIY and open-source apps — adding one more container for my static React project is way easier to manage than adding special-cases to my frontend for serving static files (right now the configuration is “when you get a request for X.shish.io, forward that to the docker container named shish-X”).

Sure, in each individual case going bare-metal is easier - but once you get to N=2 (multiple languages, multiple versions of the same language installed side-by-side) I find containers to be a net positive.

(If we were in a world where every language was able to output reproducible static binaries with embedded assets I think I would prefer that, but alas we aren’t there)

You're containerizing the build utilities so you can have a CI / CD pipeline setup for releasing the bundled JS. You can basically deploy containers as-is, pull them down locally and debug production grade code without any differences.

Fully agreed. Funnily enough, I've been debating one of Vercel's team members on the next JS subreddit about this very thing. For those not aware, Next JS is fundamentally not openly usable outside of Vercel as a hosting platform. They do provide a docker image so you can feasibly use that wherever to run Next JS, but obviously... thats a docker image. Like if I wanted to use Next JS with AWS lambda, I wouldn't be able to. Even though that's what Vercel uses under the hood for hosting.

I think this is needlessly harsh.

There's plenty of people coming from a more traditional sysadmin background with close familiarity with bare-metal systems but not so much familiarity with the docker ecosystem, which is really its own thing, fairly sprawling and not entirely obvious to reason about.

> spin up a whole container just to...

A container is closer to a chroot jail than it is a VM. It's not something you need to spin up, unless you're on some convoluted cluster orchestration system... It's not intrinsic to containers.

Docker is bare metal too. As you said it is not a VM.

This is brushing over the layered lookback filesystem mount overhead

Seriously. I've been doing front end for a long time and I literally never touched Docker until last year. There's just no need for it when you're building client-side.

The higher level optimizations require dynamic rendering and streaming. Hosting next.js on your own infrastructure is generally an exercise in frustration if you are not using Vercel.

Well, now the SPA thing has run it's course, and we need a backend for our frontend, which will also to talk to our other backend.

S3/CDN

Reply on news.ycombinator.com