Live data from Hacker News

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

github.com

91–100 of 119 posts

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

#91
post #80

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

Ahhh...I see what you're saying.

So like, if you're on my-spa.com, and click a link to a post, the JS loads the post and updates the URL, but doesn't perform a full page load. So while you might be on https://my-spa.com/user/39820002/post/39811155, your browser likely never actually sent a GET request to /user/39820002/post/39811155. But this creates the issue that if you manually navigate to that URL, your browser WILL send a request for it.

In that case, yeah, I think the correct thing to do is to return the 200 OK with your usual index.html. When the JS makes the API requests, those requests should return a 404, and the JS will then render a page that says "That post doesn't exist" or something.

But in the case of a request that couldn't possibly exist, like a GET request for /etc/passwd, they should still be 404s. Any router should be able to do that.

EDIT: I think a better way to do this hold thing is to make the resource an anchor tag in the URL. Instead of https://my-spa.com/user/39820002/post/39811155, make it https://my-spa.com/#user/39820002/post/39811155

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

#92
If this is the nano version then let me share the pico alternatives with you:

* BusyBox httpd [1]

* thttpd [2]

* Lwan Web Server [3]

* gatling [4]

I built and maintain a super tiny Docker image (~158KB) for serving static files [5]. My current implementation is based on Busybox httpd and scratch but I also tried out thttpd in the past, which worked well but came with a high memory footprint in some cases. thttpd was used to serve big projects back in the day but it doesn't seem maintained any more. The other two projects were on my list of things to try out. All these projects should compile to binaries By comparison nano-web builds a 18.5MB image on my machine. In my experience you can't go below 5-6MB with Alpine (scratch is the way to go if you can compile statically) and you can't go below ~500KB with Golang or Rust, at least not for serving http requests (C or ASM is probably the way to go).

Note that I'm not saying that small is always better, it probably depends on your use case and there are reasons for using nginx for a static website as well.

[1] https://www.busybox.net/ [2] https://www.acme.com/software/thttpd/ [3] https://lwan.ws/ [4] https://www.fefe.de/gatling/ [5] https://github.com/lipanski/docker-static-website

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

#93
post #77

Earlier quoted context omitted.

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.

Indeed, for a cost-effective approach with a static host, why not generate placeholder HTML files for all valid routes at compile time? Alternatively, using Astro or a similar tool would be a wise choice :)

This isn’t really feasible, think about how dynamic routes can be? Can you generate a route for every ID of a thing?

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

#94
post #80

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

Yeah I mean SPAs still make lots of sense for web based applications, of which there are many. They make bugger all sense for websites, of course. I wouldn’t say they are declining in popularity, more like declining in overuse.

Also it is nice to be able to cleanly implement SPAs in such a way that the server itself is doing as little work as possible for cost and scale.

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

#95

Earlier quoted context omitted.

I just figured any savings where savings can be made is a good thing, especially if there are zero downsides, plus it means very low CPU usage as it's literally just pulling from RAM without any CPU usage. It also precaches gzipped and brotli'd versions of sensible files so that it can accept-encoding for a variety of browsers.

Linux already caches files in ram, you're probably just doing something that your OS is already doing, but worse. If you're really concerned you can MMAP the file instead, and do a read every once in a while to keep it cached. There are a lot of cases where this kind of functionality could cause big problems, and very few where it has more than a marginal improvement over what your OS is already doing. Just read the…

This doesn’t necessarily have to run on Linux.

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

#96

Are there bigger latency wins supporting HTTP/2 or HTTP/3? Is HTTP/2 or HTTP/3 even useful behind a service mesh (istio/envoy etc.)?

If you want TLS, HTTP/3, quic etc I’d suggest that’s the job of whatever is terminating the connection not the core server.

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

#97

Earlier quoted context omitted.

I mean, I think it's an interesting approach to and kind of nice to be going back to more PaaS primitives. I haven't used it in production, it does seem extremely quick and kind of simple and nice. Either way, I figure the more projects that support it natively, the bigger the ecosystem grows and the more data we'll see based on real world usage. The tooling seems pretty good, though the documentation could do with s…

> Either way, I figure the more projects that support it natively, the bigger the ecosystem grows and the more data we'll see based on real world usage. I like your approach towards this, I'm thinking the same. I appreciate the response you provided, I've been planning on playing around with it for a while when I get the time. Your comment made me even more interested. It went quite quick from seeing your comment on…

The joys of funemployment ;)

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

#98
post #80

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

Ahhh...I see what you're saying. So like, if you're on my-spa.com, and click a link to a post, the JS loads the post and updates the URL, but doesn't perform a full page load. So while you might be on https://my-spa.com/user/39820002/post/39811155 , your browser likely never actually sent a GET request to /user/39820002/post/39811155. But this creates the issue that if you manually navigate to that URL, your browser…

> So like, if you're on my-spa.com, and click a link to a post, the JS loads the post and updates the URL, but doesn't perform a full page load. So while you might be on https://my-spa.com/user/39820002/post/39811155, your browser likely never actually sent a GET request to /user/39820002/post/39811155. But this creates the issue that if you manually navigate to that URL, your browser WILL send a request for it.

Exactly, you got it. This is why SPA configurations for webservers exist, like the SPA_MODE on the one we are commenting on.

> EDIT: I think a better way to do this hold thing is to make the resource an anchor tag in the URL. Instead of https://my-spa.com/user/39820002/post/39811155, make it https://my-spa.com/#user/39820002/post/39811155

As someone else said:

https://news.ycombinator.com/item?id=39819120

Hash routes have their own problems, I don't think they are a great solution, but indeed SPA routers often support them, example from react router:

https://reactrouter.com/en/main/router-components/hash-route...

Note that they strongly suggest to not use hash routing unless you have no other choice.

I agree that returning 200 to every route isn't great for some scenarios, but realistically, SPAs exist, they usually work like this and they are deployed like this, can't really change that now. I would just not build an SPA with client side routing at this point in time since there are solutions that I personally prefer, other people may think differently though.

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

#99

If this is the nano version then let me share the pico alternatives with you: * BusyBox httpd [1] * thttpd [2] * Lwan Web Server [3] * gatling [4] I built and maintain a super tiny Docker image (~158KB) for serving static files [5]. My current implementation is based on Busybox httpd and scratch but I also tried out thttpd in the past, which worked well but came with a high memory footprint in some cases. thttpd was…

Let's say you have a personal portfolio website. Single index.html file. Written entirely in vanilla HTML/CSS/JS with zero dependencies whatsoever. Project "pages" are fullscreen slideshows of high-rez images (3200x2000) etc. So basically a handcrafted static site.

Would buying a virtual server and running any one of these mini servers to run your site make it more performant than throwing it on a regular host like Dreamhost?

Like, does the simplicity in the server itself offer ANY speed/performance/latency advantages for a site that is ultimately showcasing big imagery for a folio?

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

#100
post #75
post #11

Earlier quoted context omitted.

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?

Yes, thank you, it is now fixed :-)
Post reply on HN