4 ms·

Serving Astro with Rust

59 points by skwee357 3y ago

trollied 3y ago
All of this can be achieved using nginx or apache. Crazy that rust stuff just gets upvoted. Also “server side rendering” as a term just needs to go away. Serving HTML is the way it all started.
- patmorgan23 3y ago
  Server side rendering is different from serving static HTML or template generated HTML.
  - madeofpalk 3y ago
    What's the difference between "Server side rendering" or "template generated HTML"? Stuff like React is just fancy HTML templates.
    - JimDabell 3y ago
      They are the same thing. Template-generated HTML has been called server-side rendering for decades. People immersed in development using front-end JavaScript frameworks have been sufficiently isolated from server-side rendering for long enough that it’s a foreign concept. A recent optimisation in front-end frameworks is to generate the initial HTML on the server instead of sending an empty shell that does nothing but load the JavaScript application. As you point out, this is just server-side rendering, which is a very old concept. However, if you have spent the majority of your time with front-end frameworks, “SSR” is a new concept that has recently been invented, not that old thing that people used to do before front-end JavaScript frameworks took over the world.
- jjtheblunt 3y ago
  I think you're missing the point that people don't necessarily want to deal with either nginx or apache, and might want to only have whatever application they're working on present an http(s) interface/api directly from itself. I've done that sort of thing explicitly in the past, with great results, which is why I think you overlooked such. I also think you're missing the idea that server side rendering implies a class of network traffic reductions, with resulting UX improvements. An example might would be that a subset of possible javascript, which might have been sent to a browser which was "Serving HTML", might be responsible for resulting network requests right back to the server serving the html. And this pointless network traffic which uses nothing on the browser except a javascript engine might be identified and run with no network overhead on the server, which is serving whatever in the first place. i.e., it's a network traffic 'optimization' since latency is a big deal in UX. You could read up on server side rendering ideas at https://bun.sh https://bun.sh or https://deno.com https://deno.com for just two examples.
- SPBS 3y ago
  I had to re-read OP's post multiple times just to understand that he was trying to serve static HTML pages alongside a Rust application at /api. It's not very clear, he only mentions the Rust server for the first time at the last section of the article. And yeah, he could have still used nginx.
- throwawaytodey 3y ago
  [dead]
jitl 3y ago
Reading this, I can't help but feel like the "reject modernity, embrace tradition" UI development trend of returning to untyped templating languages is throwing the baby out with the bathwater. Using jinja/htmx/go-templates helps you avoid a big Javascript bundle, but it lands you right back in this 90s/00s toil of screwing around binding your "real" programming language to some half-baked untyped meta-language that spits out something XML-like. If you're picking Rust or any other language where you like the typechecker, why throw that all away? Defining your UI as more-or-less normal functions in your main programming language that take normal arguments and return return composable UI-typed values is a massive, massive productivity win. Lots of teams pick Typescript/React over other languages/frameworks they prefer or that have better performance for only that reason! I'm very happy that many production UI systems are moving towards a React/Elm-inspired API. On Android, Jetpack Compose means I don't need to screw around copy pasting method names between XML files and Java classes. On iOS, SwiftUI means I never need to plumb delegates around Interface Builder again. In Typescript land, there's a zillion React-inspired frameworks, like Astro, that carry this learning forward. If I was in OP's position, I'd be looking for some macros / sugar (https://docs.rs/typed-html/latest/typed_html/ https://docs.rs/typed-html/latest/typed_html/ came up in a quick google search) that make it really easy to write composable UI snippets in my regular Rust files. Why introduce a new language, a new typechecker, and muck around iteroperating between Rust and Typescript, if you can do it all in Rust? You can even add a little bit of glue to make HTMX directives that eg do form things type-check against the form action they'll POST to. You should be able to rely on the Rust compiler to make function calls that return strings not error at runtime.
- deleted 3y ago
  [deleted]
- 0atman 3y ago
  This is the right answer. How can you go back to a non-typed world after Rust I don't know. I use html-node which has a typed submodule for even greater strictness. I just build some valid html, make a string and write that to the output directory and get on with my life. Eg: https://github.com/0atman/noboilerplate/ https://github.com/0atman/noboilerplate/ Templates... Rust functions Flow control... Rust match expression Abstraction... Rust modules Html validation... Rust compiler I like to think that in writing the html-node crate, Vidhan taught the compiler to speak html! https://lib.rs/crates/html-node https://lib.rs/crates/html-node
Thaxll 3y ago
Did OP read Caddy doc before throwing Rust into the mix? I'm pretty sure his use case is doable with simple Caddy config.
- deleted 3y ago
  [deleted]
dcre 3y ago
It took me a while to understand how little is ultimately going on here. If you're using Astro to generate a static site, then the question of how to serve it has nothing to do with Rust — it's a question you can ask (and which should be relatively easy to answer) for any web server.
tamimio 3y ago
Why not just use Zola at this point?! You don’t need js either.
impulser_ 3y ago
Can you embed the html files into the binary using Rust like you can with Go? One of the coolest features of Go is the embed package. You can build, and bundle a React, Vue, SvelteKit, Astro or w.e framework directly into your binary and have it serve with your API. Makes deploying very easy, just ship the single file binary.
- notaboredguy 3y ago
  Yes, check https://doc.rust-lang.org/std/macro.include_str.html https://doc.rust-lang.org/std/macro.include_str.html
  - Thaxll 3y ago
    It's a utf8 string though, Go gives you a reader which is any type of data.

59 points by skwee357 3y ago

All of this can be achieved using nginx or apache. Crazy that rust stuff just gets upvoted. Also “server side rendering” as a term just needs to go away. Serving HTML is the way it all started.

patmorgan23 3y ago
Server side rendering is different from serving static HTML or template generated HTML.
- madeofpalk 3y ago
  What's the difference between "Server side rendering" or "template generated HTML"? Stuff like React is just fancy HTML templates.
  - JimDabell 3y ago
    They are the same thing. Template-generated HTML has been called server-side rendering for decades. People immersed in development using front-end JavaScript frameworks have been sufficiently isolated from server-side rendering for long enough that it’s a foreign concept. A recent optimisation in front-end frameworks is to generate the initial HTML on the server instead of sending an empty shell that does nothing but load the JavaScript application. As you point out, this is just server-side rendering, which is a very old concept. However, if you have spent the majority of your time with front-end frameworks, “SSR” is a new concept that has recently been invented, not that old thing that people used to do before front-end JavaScript frameworks took over the world.
jjtheblunt 3y ago
I think you're missing the point that people don't necessarily want to deal with either nginx or apache, and might want to only have whatever application they're working on present an http(s) interface/api directly from itself. I've done that sort of thing explicitly in the past, with great results, which is why I think you overlooked such. I also think you're missing the idea that server side rendering implies a class of network traffic reductions, with resulting UX improvements. An example might would be that a subset of possible javascript, which might have been sent to a browser which was "Serving HTML", might be responsible for resulting network requests right back to the server serving the html. And this pointless network traffic which uses nothing on the browser except a javascript engine might be identified and run with no network overhead on the server, which is serving whatever in the first place. i.e., it's a network traffic 'optimization' since latency is a big deal in UX. You could read up on server side rendering ideas at https://bun.sh https://bun.sh or https://deno.com https://deno.com for just two examples.
SPBS 3y ago
I had to re-read OP's post multiple times just to understand that he was trying to serve static HTML pages alongside a Rust application at /api. It's not very clear, he only mentions the Rust server for the first time at the last section of the article. And yeah, he could have still used nginx.
throwawaytodey 3y ago
[dead]

jitl 3y ago

Reading this, I can't help but feel like the "reject modernity, embrace tradition" UI development trend of returning to untyped templating languages is throwing the baby out with the bathwater. Using jinja/htmx/go-templates helps you avoid a big Javascript bundle, but it lands you right back in this 90s/00s toil of screwing around binding your "real" programming language to some half-baked untyped meta-language that spits out something XML-like. If you're picking Rust or any other language where you like the typechecker, why throw that all away? Defining your UI as more-or-less normal functions in your main programming language that take normal arguments and return return composable UI-typed values is a massive, massive productivity win. Lots of teams pick Typescript/React over other languages/frameworks they prefer or that have better performance for only that reason! I'm very happy that many production UI systems are moving towards a React/Elm-inspired API. On Android, Jetpack Compose means I don't need to screw around copy pasting method names between XML files and Java classes. On iOS, SwiftUI means I never need to plumb delegates around Interface Builder again. In Typescript land, there's a zillion React-inspired frameworks, like Astro, that carry this learning forward. If I was in OP's position, I'd be looking for some macros / sugar (https://docs.rs/typed-html/latest/typed_html/ https://docs.rs/typed-html/latest/typed_html/ came up in a quick google search) that make it really easy to write composable UI snippets in my regular Rust files. Why introduce a new language, a new typechecker, and muck around iteroperating between Rust and Typescript, if you can do it all in Rust? You can even add a little bit of glue to make HTMX directives that eg do form things type-check against the form action they'll POST to. You should be able to rely on the Rust compiler to make function calls that return strings not error at runtime.

deleted 3y ago
[deleted]
0atman 3y ago
This is the right answer. How can you go back to a non-typed world after Rust I don't know. I use html-node which has a typed submodule for even greater strictness. I just build some valid html, make a string and write that to the output directory and get on with my life. Eg: https://github.com/0atman/noboilerplate/ https://github.com/0atman/noboilerplate/ Templates... Rust functions Flow control... Rust match expression Abstraction... Rust modules Html validation... Rust compiler I like to think that in writing the html-node crate, Vidhan taught the compiler to speak html! https://lib.rs/crates/html-node https://lib.rs/crates/html-node

Thaxll 3y ago

Did OP read Caddy doc before throwing Rust into the mix? I'm pretty sure his use case is doable with simple Caddy config.

deleted 3y ago
[deleted]

dcre 3y ago

It took me a while to understand how little is ultimately going on here. If you're using Astro to generate a static site, then the question of how to serve it has nothing to do with Rust — it's a question you can ask (and which should be relatively easy to answer) for any web server.

tamimio 3y ago

Why not just use Zola at this point?! You don’t need js either.

impulser_ 3y ago

Can you embed the html files into the binary using Rust like you can with Go? One of the coolest features of Go is the embed package. You can build, and bundle a React, Vue, SvelteKit, Astro or w.e framework directly into your binary and have it serve with your API. Makes deploying very easy, just ship the single file binary.

notaboredguy 3y ago
Yes, check https://doc.rust-lang.org/std/macro.include_str.html https://doc.rust-lang.org/std/macro.include_str.html
- Thaxll 3y ago
  It's a utf8 string though, Go gives you a reader which is any type of data.