Before nginx was a thing, I worked with a guy who forked apache httpd and wrote this blog in C, like, literally embedded html and css inside the server, so when he made a tpyo or was adding another post he had to recompile the source code. The performance was out of this world.
There are a lot of solutions like that in rust. You basically compile the template into your code.
yeah, templates can be parsed at compile time but these frameworks are not embeeding whole fucking prerendered static pages/assets
They are nowadays. Compiling assets and static data into rust and deliver virtual DOM via websocket to the browser is the new cool kid in the corner.
Have a look at dioxus
Compiling all assets into the binary is trivial in rust. When I have a small web server that generates everything in code I usually compile the favicon into the binary.
Does a file lookup really take that long? Id say the trick was to have just plain old html with no bloat and you're golden.
Blog content was stored in memory and it was served with zero-copy to the socket, so yea, it's way faster. It was before times of php-fpm and opcache that we're using now. Back then things were deployed and communicated using tcp sockets (tcp to rails, django or php) or reading from a disk, when the best HDDs were 5600rpm, but rare to find on shared hosting.
Couldn't the html be loaded into memory at the beginning of the program and then served whenever? I understand the reading from disk will be slow, but that only happens once in the beginning.
This reminds me of one of my older projects. I wanted to learn more about network communications, so I started working on a simple P2P chat app. It wasn't anything fancy, but I really enjoyed working on it. One challenge I faced was that, at the time, I didn't know how to listen for user input while handling network communication simultaneously. So, after I had managed to get multiple TCP sockets working on one thread, I thought, why not open another socket for HTTP communication? That way, I could incorporate a fancy web UI instead of just a CLI interface.
So, I wrote a simple HTTP server, which, in hindsight, might not have been necessary.
Ah, you met fefe.
Fefe uses a LDAP server as backend, not Apache
He also uses his own http server that in turn queries the ldap server solely for the articles. The rest is compiled into the http server binary.
He uses his own http server called gatling and an LDAP server instead of a database.
Before nginx was a thing, I worked with a guy who forked apache httpd and wrote this blog in C, like, literally embedded html and css inside the server, so when he made a tpyo or was adding another post he had to recompile the source code. The performance was out of this world.
There are a lot of solutions like that in rust. You basically compile the template into your code.
yeah, templates can be parsed at compile time but these frameworks are not embeeding whole fucking prerendered static pages/assets
They are nowadays. Compiling assets and static data into rust and deliver virtual DOM via websocket to the browser is the new cool kid in the corner.
Have a look at dioxus
Compiling all assets into the binary is trivial in rust. When I have a small web server that generates everything in code I usually compile the favicon into the binary.
Does a file lookup really take that long? Id say the trick was to have just plain old html with no bloat and you're golden.
Blog content was stored in memory and it was served with zero-copy to the socket, so yea, it's way faster. It was before times of php-fpm and opcache that we're using now. Back then things were deployed and communicated using tcp sockets (tcp to rails, django or php) or reading from a disk, when the best HDDs were 5600rpm, but rare to find on shared hosting.
Couldn't the html be loaded into memory at the beginning of the program and then served whenever? I understand the reading from disk will be slow, but that only happens once in the beginning.
This reminds me of one of my older projects. I wanted to learn more about network communications, so I started working on a simple P2P chat app. It wasn't anything fancy, but I really enjoyed working on it. One challenge I faced was that, at the time, I didn't know how to listen for user input while handling network communication simultaneously. So, after I had managed to get multiple TCP sockets working on one thread, I thought, why not open another socket for HTTP communication? That way, I could incorporate a fancy web UI instead of just a CLI interface.
So, I wrote a simple HTTP server, which, in hindsight, might not have been necessary.
Ah, you met fefe.
Fefe uses a LDAP server as backend, not Apache
He also uses his own http server that in turn queries the ldap server solely for the articles. The rest is compiled into the http server binary.
He uses his own http server called gatling and an LDAP server instead of a database.