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”.
> 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.
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.
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.
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.
It's good info as far as Dockerizing the build process of a React app, but there isn't much deploying happening in this article. docker-compose isn't really used for deployment (unless you're one of the 3 people using Swarm).
I think the deployment story for for React apps is monopolized by all the at-the-edge startups, and they don't run containers(?). Even Fly.io doesn't run containers (you make a Docker image as your "deployment artifact", and Fly creates a Firecracker-friendly VM from it).
I mean, I wouldn't deploy static content inside a docker container running nginx when you can just use a tiny busybox image for it. Let nginx sit on top of it all so you only have one instance of it running, instead of one in every image
Honest question — may be I don't know something. Is there something wrong with using Docker compose in production to deploy a simple system of ~5 services?
It's fine if you don't care about things like: redundancy/HA, zero-downtime, liveness probes, auto-scaling. So fine for smaller projects. But if you have small project it begs a question why do you have 5 services.
I suppose the phrase "react app" is there in the title just for SEO purposes. What it should have said is "how to dockerize an nginx instance" ¯\_(ツ)_/¯
I'm a bit surprised to see this on the Hacker News frontpage. It's not terrible, but it's kind of just some how-to content on what I think many would consider a fairly mundane task. On one hand, it IS a reasonable step up from SEO crap you'd read typing hot keywords like "React" and "Docker" into Google: it's relatively succinct and doesn't seem like it's doing anything wrong. On the other hand, it doesn't really build a case for why you'd do this, what the pros and cons of an approach like this is, etc. which is what I expect more people would find interesting.
Like, for example, why would you do this? It's a good question for someone who's looking to do this to ask themselves before doing it, and therefore a good question to try to answer. Like for example, if I'm trying to deploy to a service like Fly.io or into a Kubernetes cluster, then this may very well be the right thing to do.
However, if I'm a n00b and I just know people deploy things with Docker, I might miss that it'd actually be much easier to just push this stuff to Cloudflare Pages, Vercel, Netlify or another static pages hosting tool/CDN.
Some people read articles like this without having much of a basis for why you would want to add all of this complexity, and it leads them to think it's the right choice when it isn't necessarily. Generally the answer for why to do this, in my mind, is something along the lines of uniformity; having everything be an OCI image is convenient, and in the case of a PaaS or existing container cluster setup, it might be necessary if you want your frontend deployment to go alongside your other containers. It also has the benefit of being easier to test exactly how it will run locally, whereas with something like Cloudflare Pages you might need to play around to figure out how things like redirect rules will wind up working when you actually deploy it.
> It's not terrible, but it's kind of just some how-to content on what I think many would consider a fairly mundane task
I'm also a bit surprised. This is the kind of deployment you can hack together in 30 minutes if you know almost nothing about React builds, nginx, or Docker. It's one of the more trivial Docker tasks out there.
I understand the sentiment, but the point isn't "Cloud", the point is CDN/file server. The truth is though, that yes, I would generally recommend someone who has never deployed a front end application before to "default to 'cloud'" in that they should absolutely, 100% use a CDN service that handles everything for them, including deployments and rollbacks, availability, etc. Doesn't have to be any specific service: they're all just about the same. No lock-in required.
Cloud can be bad, but in this case it's barely any different from what people used to do with cPanel hosting back in the day. The point is to just drop some files somewhere and have someone else's HTTP server host them.
> Cloud can be bad, but in this case it's barely any different from what people used to do with cPanel hosting back in the day.
Yes but I don't think we should be outraged over posts that discuss deploying with an HTTP server. If anything, the concern should be over the focus on specific platforms like Vercel/Next.js, or Cloudflare Workers limiting broader understanding and options.
I have a multilayer build. On the Dev layer, we use vite and mount the react code as a volume. On the prod layer,we bundle everything using vite and serve the app using caddy. Best of both worlds. Dependencies are all containerised and handled using docker compose for local Dev. I have a local CI/CD pipeline using Task and the same pipeline using gitlab CI/CD for when we push to the repo.
I feel like this would do well to compare it to a more traditional CDN delivery method.
Other than the obvious edge benefits of a CDN, this would seem to open up issues around asset versioning. EG it's pretty standard to include asset/build hashes as part of urls, to ensure that the base app page and JS requests all get the correct build. You want JS to be cached between normal refreshes, but that to be busted on a new build.
If you were to deploy a new docker container with this pattern, you'd lose the old hashes, so potentially getting weird intermittent failures if someone's operating the old app in their browser, but the accompanying assets are no longer available due to a new build having gone out? If you don't do hashes, how do you ensure a new page load doesn't use a cached asset? ETAGS?
I think the article is a decent presentation of "docker 101" but left me with more questions than answers on what it actually means to try and do an dockerized ngnix static asset server rather than a CDN.
I mean why not? If you can subsidize your projects off of someone else's marketing budget and not have to deal with any lock in then it is a no brainer to do.
There's really nothing preventing anyone from pulling the plug when it's a free service provided as-is with no money changing hands. Especially when mergers and acquisitions are involved, this type of stuff can go down with very short notice.
I used to use rootless Podman Quadlet with autoupdate instead of docker compose. It seems to be much more stable and its integration with SystemD logs is great.
i _think_ people are missing the premise of this article, thanks to the whole "docker-compose" segment. replace that with "kubernetes", and a deployment object, et voila!
having seen sufficient images with npm install followed by a npm start, this guide is still relevant (for apps that don't do SSR anyway).
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”.