Show HN: I'm rewriting a web server written in Rust for speed and ease of use (ferron.sh)

Edit: just tried it for serving a fastapi. It's fantastic. Instant TLS via Let's Encrypt. There may be other webservers that are equally easy, but this one is certainly easier than Apache or ngninx, which I used so far. Love it.

--

Reach out to the guys at Kamal. They wrote their own reverse proxy because they thought Traefik was too complex, but they might be super happy about yours if Ferron is more powerful yet easy to configure because it might solve more of Kamal’s problems.

Not affiliated with Kamal at all, just an idea.

what are the advantages vs something like https://caddyserver.com?

> Security is imperative

> Install with sudo curl bash

Just for curiosity there is also: https://github.com/cablehead/http-nu

Which seems like interesting UX.

I was previously waiting for River https://github.com/memorysafety/river/ to take off, it's built on top of previously open-sourced library by Cloudflare for revese-proxying, but just like many other "grant-based" projects it just died when funding stopped.

I really like the spirit and simplicity of Ferron, will try it out when I have a chance. Been waiting for gradually throw out nginx for a while now, nothing clicked all the checkboxes.

This has a good chance to succeed.

Good luck.

Hey! Sorry, I didn't get the chance to test it yet (like I promised when you launched), but can you say more about the rewrite? The title made me think you're porting it from Rust to another language :-).

Kudos!

This is great, I started working on a similar project but never had the discipline to sit through all the edge cases.

Maybe I'll start building it on top of ferron!

I would love to have a minimalistic DIY serverless platform where I can compile rust functions (or anything else, as long as it matches the type signature) to a .so, dynamically load the .so and run the code when a certain path is hit.

You could even add JS support relatively easily with v8 isolates.

Lots of potential!

There is something funny going on in the benchmarking section. If you look at the charts, they don't benchmark the same servers in 4 examples.

Each of the 4 charts have data for Ferron and Caddy, but then include data for lighttpd, apache, nginx and traefik selectively for each chart, such that each chart has exactly four selected servers.

That doesn't inspire confidence.

Looks awesome, but the docs page seems to be returning a 200 yet is completely empty and is showing `x-ferron-cache: HIT` header. Maybe a misconfiguration somewhere?

Looking at the graphs, I would recommend it would have been better to market it as "just as performant as nginx and htproxy" instead of "faster than all ...". While highlighting the simplicity as the added benefit above those all.

I know it's not popular to care about these things these days, but please consider a different installation mechanism than curl piped into sudo bash. It's irresponsible and normalizes a practice that never should've happened.

> Any feedback is welcome!

Read https://www.joelonsoftware.com/2006/12/09/simplicity/ and ask yourself if you are truly solving anyone's problem or if you are just looking for a way to rationalize the amount of time you are spending on a hobby.

I wrote my own web server from scratch last year the exact same reasons: starting from scratch with Apache and NGINX is too painful for my needs.

Here are my learnings:

* TLS (HTTPS) can be easily enabled by default, but it requires certificates. This requires a learning curve for the application developer but can be automated away from the user.

* The TLS certs will not be trusted by default until they are added to the OS and browser trust stores. In most cases this can be fully automated. This is most simple in Windows, but Firefox still makes use of its own trust store. Linux requires use of a package to add certs to each browser trust store and sudo to add to the OS. Self signed certs cannot be trusted in OSX with automation and requires the user to manually add the certs to the keychain.

* Everything executes faster when WebSockets are preferred over HTTP. An HTTP server is not required to run a WebSocket server allowing them to run in parallel. If the server is listening for the WebSocket handshake message and determines the connection to instead be HTTP it can allow both WebSocket and HTTP support from the same port.

* Complete user configuration and preferences for an HTTP or WebSocket server can be a tiny JSON object, including proxy and redirection support by a variety of addressable criteria. Traffic redirection should be identical for WebSocks and HTTP both from the users perspective as well as the internal execution.

* The server application can come online in a fraction of a second. New servers coming online will also take just milliseconds if not from certificate creation.

[dead]

That’s awesome — congrats on reaching the release candidate stage! I’m curious about the performance improvements you mentioned. Did you benchmark against other Go web servers like Caddy or fasthttp? Also really like that you’ve made automatic TLS the default — that’s one of those “quality of life” features that make a huge difference for users.

I’m working on an open-source project myself (AI-focused), and I’ve been exploring efficient ways to serve streaming responses — so I’d love to hear more about how your server handles concurrency or large responses.

Hey really cool. Am proficient in Rust if you need any help.

Great to see! Would love to try it, but I depend on graceful updates of configuration (i.e. adding and removing backends primarily). I can't find anything about that. Is it supported, either through updating configs or through API?

So I have to connect my domain to your IP adres? Why there is perfectly fine HTTP auth method for let's encrypt. This is strange and not necessary.

"I don't like nginx config so I'm going to write a whole application just so that I don't have to write nginx config".

Maybe just write an nginx config generator instead?

It's also interesting that the actual config looks quite a lot like nginx config.

Your title is confusing. It sounds like you are rewriting a web server _already_ written in Rust to a _different_ language. Now that I'd be in favor of.

"It's written in Rust so it's memory safe!"

Ferron provides a concise and efficient way to handle state management in front-end frameworks. It adopts a responsive design concept and can greatly simplify the development process of complex applications. Its clear API and lightweight architecture allow developers to quickly implement dynamic interfaces without sacrificing performance. Overall, it is a tool worth paying attention to in modern front-end development, especially for projects with high performance requirements

I don't trust the benchmarks