Earlier quoted context omitted.
Well client side routing is fundamentally broken unless you do serve a 200 and the index
You only have to serve a 200 and the index for valid routes to have frontend routing working. The complaint is serving a 200 for invalid routes, which breaks all kinds of things and violates web standards.
Show HN: Nano-web – a low latency one binary webserver designed for serving SPAs
81–90 of 119 posts
Re: Show HN: Nano-web – a low latency one binary webserver designed for serving SPAs
#82Earlier quoted context omitted.
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…
> 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 S…
What's available now that superceds them?
Re: Show HN: Nano-web – a low latency one binary webserver designed for serving SPAs
#83Earlier quoted context omitted.
Yep, returning the wrong HTTP status code is going to confuse a lot of search engines, chat app link previews, and other automated consumers of your SPA, even if you subsequently display the correct error page.
>returning the wrong HTTP status code is going to confuse a lot of search engines How is the search engine going to find a page that doesn't exist, isn't in a sitemap, isn't linked to in any nav anchors, in order to index it?
If links are never going to be used, there is no point in doing the effort of client side routing.
If links are going to used, the server needs to respond with the correct status or you break the assumptions upon which the tools people use to access the web are based.
Re: Show HN: Nano-web – a low latency one binary webserver designed for serving SPAs
#84By the way, is there a really minimal, really fast, reasonably secure, zero-cofig single-binary web server which would only support HTTP GET and just expose all the static content in a given directory over it?
Caddy [1] is a single binary. It is not minimal, but the size difference is barely noticeable. serve also comes to mind. If you have node installed, `npx serve .` does exactly that. There are a few go projects that fit your description, none of them very popular, probably because they end up being a 100-line wrapper around http frameworks. [1] https://caddyserver.com/
Re: Show HN: Nano-web – a low latency one binary webserver designed for serving SPAs
#85> SPA_MODE when set to 1 404 request will return /public/index.html as a 200. oof, as someone who frequently has to run DAST tools, returning a 200 for something that should be a 404 is the bane of my existence. The tool will try to request sensitive files by trying something as simple as fetching hxxps://example.com/../../../etc/passwd. If you return a "200 OK", it will flag as a security issue, even if the resultin…
Tripping up hare-brained security scanning tools sounds like a perk tbh. > I don't think you can convince me that [...] is ever the correct thing to do It's just a matter of trade-offs. Serving the app.js on a 404 can cause things like browser/caching issues that are confusing for the user, and 404 isn't necessarily correct since the app is both servable and recoverable from that url. And I'm not sure 302-redirecting…
Heh, not a bad criticism. Though TBH, I think all DAST tools are hare-brained. They get sold as automated penetration tests, but they really can't figure out SPAs at all, since they often only look at the immediate response to an HTTP request, when often, you'd need to see exactly what the JS code does with the response and how it gets rendered in the page. Maybe a PUT/POST request to upload data returns a blank 200 OK, but only a follow-up GET request will actually show the result.
They end up with more false negatives than false positives. At best, they'll catch the low-hanging fruits involving missing headers that often lead to Beg Bounties like Clickjacking or missing HSTS.
The only reason DAST still exists is because compliance frameworks still list it as a checkbox. Otherwise, I think they're pretty useless.
Re: Show HN: Nano-web – a low latency one binary webserver designed for serving SPAs
#86Earlier quoted context omitted.
Federation’s a non-starter when most devices people use are battery powered and don’t like to hold connections open when idle. Like, it works, but it won’t work well enough unless most devices are just going through gateways, which largely defeats the point.
What about all those desktop computers on 24/7 in the world?
Re: Show HN: Nano-web – a low latency one binary webserver designed for serving SPAs
#87Earlier quoted context omitted.
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?
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…
The problem is that when you only serve your app from `/`, and then the user navigates via the app to `/user/123`, the url gets updated, but if the user tries to reload the page, they'll end up on a 404 page because you're not serving the app from `/user/123`. There's a few ways to solve this, each again with tradeoffs, but one way is to have the server return 200 and the contents of the main page any time that the user requests an unknown route, under the assumption that the user is probably trying to navigate to a dynamic route handled by the frontend.
Re: Show HN: Nano-web – a low latency one binary webserver designed for serving SPAs
#88Earlier quoted context omitted.
> 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 S…
> they aren't the best solution in most cases with what's available now What's available now that superceds them?
For mostly static or content driven sites, there are really nice static site generators now. I find Astro[1] really pleasant to use, offering the convenience of SPA framework tooling, while allowing me to build sites that run without the need for any client-side JavaScript but the option to into client-side JS as needed.
But also NextJS has a similar static export function, and of course there are many other great SSGs outside the JavaScript world like Hugo.
For dynamic web applications like the example from my comment I would just do server side rendering using your language and framework of choice, Phoenix, Rails, Next, Django, whatever.
In both cases the issue with 404 routes is avoided.
Re: Show HN: Nano-web – a low latency one binary webserver designed for serving SPAs
#89Earlier quoted context omitted.
> 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 S…
> they aren't the best solution in most cases with what's available now What's available now that superceds them?
The mostly same stuff as before, but slightly better. SPAs were a fad that got very popular, but they were generally a poor solution in most cases and as the fad faded, they stopped being as overused.
One of the reasons why SPAs are bad solution is because they interfere with how the web works in significant ways (browser history, caching, server response statuses) and solving those issues without degrading user experience is hard.
When a SPA was actually useful, it was worth spending the time to solve those issues.
The overuse of SPAs means that most of them did not take the time to solve these issues properly so most SPAs sucked (and still do). This is why I don't understand releasing a SPA server in 2024 that doesn't even try to provide tools to solve those issues.
Re: Show HN: Nano-web – a low latency one binary webserver designed for serving SPAs
#90Earlier quoted context omitted.
Caddy [1] is a single binary. It is not minimal, but the size difference is barely noticeable. serve also comes to mind. If you have node installed, `npx serve .` does exactly that. There are a few go projects that fit your description, none of them very popular, probably because they end up being a 100-line wrapper around http frameworks. [1] https://caddyserver.com/
Depending on the environment I'm in I either use `npx serve` or `python3 -m http.server` (aka `python2 -m SimpleHTTPServer`)