3 ms·
At work, we build a couple SPA React application for internal tools. All of these SPAs talk to other internal APIs via REST, so you can think of these as static
by oplav 6y ago
At work, we build a couple SPA React application for internal tools. All of these SPAs talk to other internal APIs via REST, so you can think of these as static websites.
In production, we do exactly what you suggest: serve through a CDN.
However, for our dev environments and PR builds, programmatically setting up CDN to handle these use cases is not easily integrated with our CI/CD workflow. Our CI/CD environment is, however, good at quickly deploying containerized services.
For this, using an nginx container to serve the produced static bundle enables us to easily have PR builds for the dev team and product owners to see changes without having to check out and build the code.
- Symbiote 6y agoPossibly this is far too old fashioned, but all our internal static sites (and a good few external static sites) I deploy to a single Apache server.
- ebiester 6y agoIt's not old fashioned. However, it does mean you have two methods of deployment. In larger ecosystems, a suboptimal release system for some components is less harmful than multiple release systems that have to interact. I wouldn't suggest moving to docker for this use case, but if everything else was in docker, I'd want this in docker as well, even if that docker container was just running apache. (Practically, though, if I was starting from scratch, I'd be using NginX.)
- nicoburns 6y agoI highly recommend nginx over apache. It's both more performant AND much easier to configure. Other than inertia for an existing deployment I don't think there's any reason to use Apache in 2020.
- danieltillett 6y agoThese days if configured correctly there is not a huge amount of difference in performance between nginx and Apache. I have stayed with Apache because I know it and dealing with a http server is about 0.1% of my job.
- Symbiote 6y agoExactly the same for me. Milliseconds really don't matter for internal tools or legacy or low-use external websites. If someone wants to see our financial report from 2005, I'm sure they're happy to wait the extra 300ms to download it from a static site on the other side of the world. They should be happy that the link to it in the 2006 document they have still works. (The Apache server listens on 4 ports, to support redirecting various 2000s-era CMSs to their replacements.) We also have some small but important sites using obscure Apache features (semantic web stuff). I have no idea if Nginx supports the necessary configuration, but since I spend 1-2 hours per year dealing with either scenario -- usually to 'archive' another site -- I'm quite happy to use Apache.