4 ms·
What about the deployment benefit? Surely if you want to scale out your API you don't necessarily want to scale out your webservers - that's ludicrous! Surely t
by antihero 11y ago
What about the deployment benefit? Surely if you want to scale out your API you don't necessarily want to scale out your webservers - that's ludicrous! Surely the applications should be already decoupled enough that there's pretty much zero reason to run the backend on and serve the frontend from the same box? And it's not like an SPA really needs any power - if you're just serving up bundled JavaScript and some HTML, anyway.
- joshmanders 11y agoThis is exactly what I do. My product consists of 4 base docker containers. 1 is a nginx reverse proxy to 2 of the 3 remaining containers. 1 is a database container. The 2 other containers hold the API which is "monolithic" app. The other container is just bundled html/css/javascript. This allows me to scale the API to handle load independent of the app itself, since that's just static assets, it doesn't need it as much.
- antihero 11y agoI have basically a docker image that basically is just an nginx reverse proxy that forwards to a local socket. Then I can use it with whatever app I want, (usually node) and it provides a slightly "harder" (request buffering etc) http interface to the outside world.
- fatherlinnux 11y agoThis was exactly why I chose the workload I did. I think independent scaling and possibly enforcing decoupled behavior in the development teams are the only real reason TO decouple.... The rest are all descriptions of things that "might" make decoupling valid :-)