I’m not really sure what this is trying to solve. I will admit that it may just be my web dev inexperience here. I have done a bit of web dev, but I am definitely in the « knows just enough to bee...
I’m not really sure what this is trying to solve. I will admit that it may just be my web dev inexperience here. I have done a bit of web dev, but I am definitely in the « knows just enough to bee dangerous » category.
You list the advantages as no cors issues, and simple deployments. But don’t most api servers already have the ability to serve the build artifact folder directly? What benefit does embedding the index.html file into the rust binary provide, besides a single file upload? And every server setup I have used handles folders just as well as files.
In addition, does this handle a spa with multiple files? Many frameworks chunk files for performance reasons, but I only saw index.html in there. Does this require a build process to create just one monolithic file instead of chunked files?
I think it's ease of deployment and (potentially) simpler implementation as you don't have to worry about the backend's endpoint. Yes. It's handling the whole build folder instead of a single...
What benefit does embedding the index.html file into the rust binary provide, besides a single file upload
I think it's ease of deployment and (potentially) simpler implementation as you don't have to worry about the backend's endpoint.
In addition, does this handle a spa with multiple files?
Yes. It's handling the whole build folder instead of a single index.html file.
At work, we were once trying to figure out how to serve an SPA between multiple domains and retain the experience of feeling like you are in the 'same app.' It feels like this would solve for that.
At work, we were once trying to figure out how to serve an SPA between multiple domains and retain the experience of feeling like you are in the 'same app.' It feels like this would solve for that.
A simpler approach might just be to proxy all requests via a single backend. You can set this up in a few minutes with an nginx config, or build a "backend-for-frontend" app if you've got more...
A simpler approach might just be to proxy all requests via a single backend. You can set this up in a few minutes with an nginx config, or build a "backend-for-frontend" app if you've got more complicated needs than that (e.g. auth). Although tbh if your SPA already worked without a dedicated backend, then the nginx version is probably the simplest option.
I don't think there's a difference between 2 and 3. The end result is the use receiving static ( or less dynamic) HTML that's rendered server side. Now polishing the framework to generate that...
I don't think there's a difference between 2 and 3. The end result is the use receiving static ( or less dynamic) HTML that's rendered server side. Now polishing the framework to generate that HTML is interesting, especially if it translates client side JS to server side. You'll still need something in the client browsers to take advantage of client features. Encryption keys, tokens, cookies, WASM, and local JS to do things like event monitoring all need to run client side so you'll still have a local footprint. It's an interesting project for learning Rust and web rendering though.
Edit: Don't mean to come off as a pedant. I skimmed the post initially but went back and read the end and looked at your CV. Your probably know all of this. I'm leaving it up in case anyone else finds it useful.
In web development and deployment, most software engineers are familiar with either: Separating the built SPA and the backend (Client-Side Rendering), or Return HTML directly from the backend...
In web development and deployment, most software engineers are familiar with
either:
Separating the built SPA and the backend (Client-Side Rendering), or
Return HTML directly from the backend (Server-Side Rendering)
I recently (re)discovered that there is a third way: embedding
the built SPA into the backend's binary file, and serving it directly.
@thanhnguyen2187, since the majority of your submissions to Tildes is your own content and almost all your comments have been in those posts, I think it's worth pointing out Tildes self-promotion...
@thanhnguyen2187, since the majority of your submissions to Tildes is your own content and almost all your comments have been in those posts, I think it's worth pointing out Tildes self-promotion rules. I'm not trying to totally discourage you from posting your work here on Tildes, but I wanted to point out the rules just in case you weren't aware of them, and so you don't inadvertently get banned for spamming:
Self-promotion
If you have your own site/project/channel/etc. that you'd like to share on Tildes, that's generally fine (in moderation), but it shouldn't be the primary reason that you post on the site. Tildes is a community, not a free advertising platform. Sharing your own content is welcome as long as you're involved in the community, but don't just treat Tildes as a source of an audience.
Hey thanks for the reminder. I do occasionally read other threads on Tildes, but I mostly didn't feel like I have anything to add. I'll try to engage more and keep my posting less self-promotion now 🙏
Hey thanks for the reminder. I do occasionally read other threads on Tildes, but I mostly didn't feel like I have anything to add. I'll try to engage more and keep my posting less self-promotion now 🙏
What the fuck is "an SPA"? Nowhere in this entire post is a definition provided. I'm guessing it means "Single Page Application"? You really need to provide some context here.
What the fuck is "an SPA"? Nowhere in this entire post is a definition provided. I'm guessing it means "Single Page Application"? You really need to provide some context here.
I'm a Rust developer and I occasionally get dragged into doing web dev as needed. This post could've been interesting to skim as tangentially related to my area of expertise, instead of...
I'm a Rust developer and I occasionally get dragged into doing web dev as needed. This post could've been interesting to skim as tangentially related to my area of expertise, instead of frustrating, with a single added definition.
I’m not really sure what this is trying to solve. I will admit that it may just be my web dev inexperience here. I have done a bit of web dev, but I am definitely in the « knows just enough to bee dangerous » category.
You list the advantages as no cors issues, and simple deployments. But don’t most api servers already have the ability to serve the build artifact folder directly? What benefit does embedding the index.html file into the rust binary provide, besides a single file upload? And every server setup I have used handles folders just as well as files.
In addition, does this handle a spa with multiple files? Many frameworks chunk files for performance reasons, but I only saw index.html in there. Does this require a build process to create just one monolithic file instead of chunked files?
Generally my thoughts on most rust rewrites.
I think it's ease of deployment and (potentially) simpler implementation as you don't have to worry about the backend's endpoint.
Yes. It's handling the whole build folder instead of a single
index.htmlfile.At work, we were once trying to figure out how to serve an SPA between multiple domains and retain the experience of feeling like you are in the 'same app.' It feels like this would solve for that.
A simpler approach might just be to proxy all requests via a single backend. You can set this up in a few minutes with an nginx config, or build a "backend-for-frontend" app if you've got more complicated needs than that (e.g. auth). Although tbh if your SPA already worked without a dedicated backend, then the nginx version is probably the simplest option.
I don't think there's a difference between 2 and 3. The end result is the use receiving static ( or less dynamic) HTML that's rendered server side. Now polishing the framework to generate that HTML is interesting, especially if it translates client side JS to server side. You'll still need something in the client browsers to take advantage of client features. Encryption keys, tokens, cookies, WASM, and local JS to do things like event monitoring all need to run client side so you'll still have a local footprint. It's an interesting project for learning Rust and web rendering though.
Edit: Don't mean to come off as a pedant. I skimmed the post initially but went back and read the end and looked at your CV. Your probably know all of this. I'm leaving it up in case anyone else finds it useful.
In web development and deployment, most software engineers are familiar with
either:
I recently (re)discovered that there is a third way: embedding
the built SPA into the backend's binary file, and serving it directly.
@thanhnguyen2187, since the majority of your submissions to Tildes is your own content and almost all your comments have been in those posts, I think it's worth pointing out Tildes self-promotion rules. I'm not trying to totally discourage you from posting your work here on Tildes, but I wanted to point out the rules just in case you weren't aware of them, and so you don't inadvertently get banned for spamming:
https://docs.tildes.net/policies/code-of-conduct#self-promotion
p.s. Please label this comment as Offtopic so it doesn't detract from any on-topic discussion.
Hey thanks for the reminder. I do occasionally read other threads on Tildes, but I mostly didn't feel like I have anything to add. I'll try to engage more and keep my posting less self-promotion now 🙏
👍
What the fuck is "an SPA"? Nowhere in this entire post is a definition provided. I'm guessing it means "Single Page Application"? You really need to provide some context here.
I think anyone in the target audience would immediately know, and anyone who doesn’t would not be interested in reading. Am I wrong?
I'm a Rust developer and I occasionally get dragged into doing web dev as needed. This post could've been interesting to skim as tangentially related to my area of expertise, instead of frustrating, with a single added definition.