4 ms·

But if it's an SPA, how else would you handle this case? How is the webserver supposed to know in advance which URLs the SPA is able to handle?

phanimahesh 3y ago
Handle a prefix maybe?
ch_sm 3y ago
I typically keep all my SPA routes/route names in a single JSON, and then reference those from the App, instead of repeating the routes everywhere. I can then pass those to the server to let it know what the SPA can handle.
- antihero 3y ago
  This is an opinionated approach that is out of scope really I think. Though if it works for you, awesome!
  - shkkmo 3y ago
    I'm not sure what is 'opinionated' about this approach. It seems like a pretty standard and reasonable way of correctly serving an SPA in a way that doesn't violate web standards.
    - __jonas 3y ago
      So this would mean you would have to dynamically generate your webservers configuration at the build time of your SPA? And then how are you handling routes with params inside? In your SPA they would probably be configured like /user/:id/post/:post Now you would have to translate that to something the webserver config understands, probably wildcard / glob pattern / regex stuff and splice that into the web server config? I mean it's possible, sure, but that's a lot of overhead and room for error just to deploy a simple SPA, it definitely is an opinionated approach.
      - withinboredom 3y ago
        I don’t know. Computers are pretty damn good at transforming text. It sounds pretty simple really, it’s probably less than a week to build something rock solid.
  - boredtofears 3y ago
    I'd say not handling 404's correctly and simply returning a 200 OK is pretty opinionated, too.
- rizky05 3y ago
  [dead]
Sohcahtoa82 3y ago
I'm confused here. What defines the "webserver" versus the "the SPA"? The way I've implemented SPAs is to run nginx. All my JS and CSS is in /static/ and served up by nginx. "/" returns an index.html. "/api/*" gets forwarded to a back end of some sort, usually Python's Bottle because it's lightweight and simple to use. If the route doesn't exist, Bottle returns a 404. If I have an endpoint that includes an ID of some sort in the URL, like /api/getobject/12345, but you request an object that doesn't exist, then I still return a 404. How are you implementing SPAs in a way that you can't return a 404?
- __jonas 3y ago
  > How are you implementing SPAs in a way that you can't return a 404? Not specifically me, but a lot of SPAs have their own routing. So you would go to https://my-spa.com/user/39820002/post/39811155 When you hit that route, the webserver returns /index.html with the JS bundle, the JS runs and matches the user ID and post ID from the URL and then maybe makes some API requests to fetch content of whatever, I mean the SPA doesn't have to be backed by an API anyways, could be purely static but still use a router. In the React world, react-router is (was) pretty popular: https://github.com/remix-run/react-router https://github.com/remix-run/react-router That's a library that works exactly that way, relying on every route being passed to the JS bundle for handling, so the webserver needs to be configured to never return 404 and just return the index.html for every route, here is an example of what this looks like from the docs of Caddy, another popular webserver with a pretty easy to understand config format: https://caddyserver.com/docs/caddyfile/patterns#single-page-apps-spas https://caddyserver.com/docs/caddyfile/patterns#single-page-... It's a "Single Page App", you may have many pages being rendered by this app, but it's a single html page that is responsible for doing this. Now – SPAs are not as popular as they used to be, and there is an argument to be made that they aren't the best solution in most cases with what's available now, regardless of that they do exist and this appears to be a web server specifically for them so having the option handle SPA routing as it's commonly done, does make sense. And I think for stuff like internal management apps, admin panels etc. SPAs with their own routing are still a decent solution.
  - fragmede 3y ago

phanimahesh 3y ago

Handle a prefix maybe?

ch_sm 3y ago

I typically keep all my SPA routes/route names in a single JSON, and then reference those from the App, instead of repeating the routes everywhere. I can then pass those to the server to let it know what the SPA can handle.

antihero 3y ago
This is an opinionated approach that is out of scope really I think. Though if it works for you, awesome!
- shkkmo 3y ago
  I'm not sure what is 'opinionated' about this approach. It seems like a pretty standard and reasonable way of correctly serving an SPA in a way that doesn't violate web standards.
  - __jonas 3y ago
    So this would mean you would have to dynamically generate your webservers configuration at the build time of your SPA? And then how are you handling routes with params inside? In your SPA they would probably be configured like /user/:id/post/:post Now you would have to translate that to something the webserver config understands, probably wildcard / glob pattern / regex stuff and splice that into the web server config? I mean it's possible, sure, but that's a lot of overhead and room for error just to deploy a simple SPA, it definitely is an opinionated approach.
    - withinboredom 3y ago
      I don’t know. Computers are pretty damn good at transforming text. It sounds pretty simple really, it’s probably less than a week to build something rock solid.
- boredtofears 3y ago
  I'd say not handling 404's correctly and simply returning a 200 OK is pretty opinionated, too.
rizky05 3y ago
[dead]

Sohcahtoa82 3y ago

I'm confused here. What defines the "webserver" versus the "the SPA"? The way I've implemented SPAs is to run nginx. All my JS and CSS is in /static/ and served up by nginx. "/" returns an index.html. "/api/*" gets forwarded to a back end of some sort, usually Python's Bottle because it's lightweight and simple to use. If the route doesn't exist, Bottle returns a 404. If I have an endpoint that includes an ID of some sort in the URL, like /api/getobject/12345, but you request an object that doesn't exist, then I still return a 404. How are you implementing SPAs in a way that you can't return a 404?

__jonas 3y ago
> How are you implementing SPAs in a way that you can't return a 404? Not specifically me, but a lot of SPAs have their own routing. So you would go to https://my-spa.com/user/39820002/post/39811155 When you hit that route, the webserver returns /index.html with the JS bundle, the JS runs and matches the user ID and post ID from the URL and then maybe makes some API requests to fetch content of whatever, I mean the SPA doesn't have to be backed by an API anyways, could be purely static but still use a router. In the React world, react-router is (was) pretty popular: https://github.com/remix-run/react-router https://github.com/remix-run/react-router That's a library that works exactly that way, relying on every route being passed to the JS bundle for handling, so the webserver needs to be configured to never return 404 and just return the index.html for every route, here is an example of what this looks like from the docs of Caddy, another popular webserver with a pretty easy to understand config format: https://caddyserver.com/docs/caddyfile/patterns#single-page-apps-spas https://caddyserver.com/docs/caddyfile/patterns#single-page-... It's a "Single Page App", you may have many pages being rendered by this app, but it's a single html page that is responsible for doing this. Now – SPAs are not as popular as they used to be, and there is an argument to be made that they aren't the best solution in most cases with what's available now, regardless of that they do exist and this appears to be a web server specifically for them so having the option handle SPA routing as it's commonly done, does make sense. And I think for stuff like internal management apps, admin panels etc. SPAs with their own routing are still a decent solution.
- fragmede 3y ago