Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Nano-web – a low latency one binary webserver designed for serving SPAs

github.com

Post reply on HN
Print view View original

71–80 of 119 posts

Re: Show HN: Nano-web – a low latency one binary webserver designed for serving SPAs

#71

Post by shawabawa3 »

eddd-ddde wrote: post #67
hombre_fatal wrote: post #44

Earlier quoted context omitted.

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…

If I make a typo and get a 200 for some url that doesn't actually exist, my browser will now happily suggest that url when I'm typing something in the future. Is there a benefit for doing so?

It's not a benefit but a side effect of client side routing

If your main routing logic is in your JS app your server can't know if a route exists or not unless you duplicate routing code across front end and backend

Re: Show HN: Nano-web – a low latency one binary webserver designed for serving SPAs

#72

Post by treve »

leptons wrote: post #58
kijin wrote: post #22

Earlier 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?

Perhaps the page existed in the past but now it doesn't. Or at some point a link was misspelled.

Re: Show HN: Nano-web – a low latency one binary webserver designed for serving SPAs

#73

Post by antihero »

eddd-ddde wrote: post #67
hombre_fatal wrote: post #44

Earlier quoted context omitted.

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…

If I make a typo and get a 200 for some url that doesn't actually exist, my browser will now happily suggest that url when I'm typing something in the future. Is there a benefit for doing so?

Well client side routing is fundamentally broken unless you do serve a 200 and the index

Re: Show HN: Nano-web – a low latency one binary webserver designed for serving SPAs

#74

Post by Sohcahtoa82 »

__jonas wrote: post #41
Sohcahtoa82 wrote: post #40

> 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…

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 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?

Re: Show HN: Nano-web – a low latency one binary webserver designed for serving SPAs

#75

Post by xprueg »

rkeene2 wrote: post #11
qwerty456127 wrote: post #5

By 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?

I wrote filed[0] for this. It is VERY fast in terms of low-latency (it doesn't even open the file its serving if it can help it) -- although it doesn't generate a dynamic directory listing, so it may not meet your needs if you want any dynamic content like that. [0] https://filed.rkeene.org/

Should "test/plain" be "text/plain" "in mime.types?

Re: Show HN: Nano-web – a low latency one binary webserver designed for serving SPAs

#77

Post by shkkmo »

antihero wrote: post #73
eddd-ddde wrote: post #67

Earlier quoted context omitted.

If I make a typo and get a 200 for some url that doesn't actually exist, my browser will now happily suggest that url when I'm typing something in the future. Is there a benefit for doing so?

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.

Re: Show HN: Nano-web – a low latency one binary webserver designed for serving SPAs

#78

Post by eddd-ddde »

beklein wrote: post #14
qwerty456127 wrote: post #5

By 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?

I can recommend redbean[1], it's basically a webserver and your static files in a zip file that is executable on basically any computer. It's also super small, includes TLS and reasonably fast. [1] https://redbean.dev

TIL you can actually get a single binary to execute in multiple operating systems.

Redbean in general seems great and really interesting.

Re: Show HN: Nano-web – a low latency one binary webserver designed for serving SPAs

#79

Post by shkkmo »

antihero wrote: post #53
ch_sm wrote: post #51

Earlier quoted context omitted.

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.

This is an opinionated approach that is out of scope really I think. Though if it works for you, awesome!

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.

Re: Show HN: Nano-web – a low latency one binary webserver designed for serving SPAs

#80

Post by __jonas »

Sohcahtoa82 wrote: post #74
__jonas wrote: post #41

Earlier 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…

> 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

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-...

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.

Post reply on HN