7 ms·

“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

“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”.

marginalia_nu 3y ago
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.
- charcircuit 3y ago
  Docker is bare metal too. As you said it is not a VM.
- nikau 3y ago
  This is brushing over the layered lookback filesystem mount overhead
ge96 3y ago
S3/CDN
KronisLV 3y ago
> 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.
- vlunkr 3y ago
  Yeah, this is a multi-stage build where the final image will have only the statically built content in it.
deleted 3y ago
[deleted]
KRAKRISMOTT 3y ago
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.
physicsguy 3y ago
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.
rhinoceraptor 3y ago
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.
giancarlostoro 3y ago
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.
danielvaughn 3y ago
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.
Shish2k 3y ago
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)
willio58 3y ago
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.

marginalia_nu 3y ago

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.

charcircuit 3y ago
Docker is bare metal too. As you said it is not a VM.
nikau 3y ago
This is brushing over the layered lookback filesystem mount overhead

ge96 3y ago

S3/CDN

KronisLV 3y ago

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

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

deleted 3y ago

[deleted]

KRAKRISMOTT 3y ago

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.

physicsguy 3y ago

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.

rhinoceraptor 3y ago

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.

giancarlostoro 3y ago

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.

danielvaughn 3y ago

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.

Shish2k 3y ago

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)

willio58 3y ago

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.