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.
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.
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.
There are plenty of sins people still commit and can commit when it comes to web development. Reading from disk is not the bottleneck. If site is slow most likely it’s not the disk read times, database access or anything similar, but silly code that generates the page. It’s almost always the code generating the page that’s at fault.
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.
Nothing good old cache can’t solve. Compile JS and CSS. Bundle CSS with main HTML file and send it in batches since HTTP2 supports chunkifying your output. HTTP prefers one big stream over multiple smaller anyway. So that guy was only inviting trouble for himself.
You’re telling me about compiling JS, to my story that is so old… I had to check. and yes, JS existed back then. HTTP2? Wasn’t even planned. This was still when IRC communities weren’t sure if LAMP is Perl or PHP because both were equally popular ;)
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.
There are plenty of sins people still commit and can commit when it comes to web development. Reading from disk is not the bottleneck. If site is slow most likely it’s not the disk read times, database access or anything similar, but silly code that generates the page. It’s almost always the code generating the page that’s at fault.
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.
Nothing good old cache can’t solve. Compile JS and CSS. Bundle CSS with main HTML file and send it in batches since HTTP2 supports chunkifying your output. HTTP prefers one big stream over multiple smaller anyway. So that guy was only inviting trouble for himself.
You’re telling me about compiling JS, to my story that is so old… I had to check. and yes, JS existed back then. HTTP2? Wasn’t even planned. This was still when IRC communities weren’t sure if LAMP is Perl or PHP because both were equally popular ;)