I have my backend on a different subdomain instead of a subdirectory because it solves issues at the dns level. This means I don't have to deal with setting up a reverse proxy or separate rules for cloudflare.
This applies not only to production but also for local testing. I used to have a reverse proxy for local development.
Moreover it gives you better security by default since different backends are now treated as different origins, so same-orign-policy, and same-site (for cookies) kicks in.
Yeah I used rules in Cloudfront for this. Only have one API backend so security doesn't really factor into this much. Actually I consider it slightly more secure because there was no way for me to misconfigure CORS.
This is a pretty big issue because there are a shit tonne of bad resources that poorly explain CORS - so many places just slap a wild card in 'access-control-allow-origin', and call it a day.
Even a lot of the framework middleware can be confusing and unhelpful.
FWIW, once I actually got it setup, it was very simple, very easy. I highly recommend MDN's CORS page[1] as the only source someone should read, and to read the whole thing to actually learn it rather than just grabbing a library to solve the problem in 15 minutes.
Even then, I had to start with a small test project and test things at different levels to understand what a library would be doing. My back end is golang, and I used gorilla/mux, so I did things step by step to really know what was working and what wasn't. I've done it other ways with something like Spring boot and libraries where it's just a goddamn mess because it tries to automate too much for you and it becomes way too confusing.
The article is referring to all the myriad other things an SPA will bring in. Analytics, feedback components, interactive galleries, notification components, header components... you can sew a site together from SaaS components that all live in different domains.
Well... you could. Harder now.
From the article:
> So are SPAs dead? Well – SPAs as in the UI/UX concept certainly not. SPAs as in “browser-based standalone applications that do cross-site authentication and API calls in the context of a modern identity and SSO architectures” – yes.
> I’m curious, are there any SPAs that aren’t done this way?
For…enterprise reasons…the SPAs I’ve worked on in $DAYJOB use apis hosted in a separate subdomain (and, therefore, origin) than the page itself, meaning we have all the CORS headaches. But, certainly, segregating by path rather than domain is a lot more convenient if you control both the page and the APIs it consumes.
Yes there are a ton. Actually it was a bit of a pain setting it up that way. I'm using Cloudflare to dynamically route to S3 or an ALB based on the path. If Cloudflare didn't have that option I would have had to roll my own solution to defeat CORS which could have added in another point of failure
This applies not only to production but also for local testing. I used to have a reverse proxy for local development.
Moreover it gives you better security by default since different backends are now treated as different origins, so same-orign-policy, and same-site (for cookies) kicks in.