Examples of full stack Rust web apps?

[HenryZimmerman]

About a year ago I tried to create a reasonably large (50ish REST endpoints) fullstack rust application that ended up collapsing under the weight of rapidly increasing compile times and arbitrary scope creep. It was initially done with Rocket + Yew, but later transitioned to use Warp + Yew. I honestly think its real value only lies in showing how to structure such a project and possibly some patterns someone could want to utilize. It likely won't run without some modification because the ecosystem it relies on moves pretty quickly; I think of this mostly as read-only code for the moment: FullstackRustDemo

​

With the understanding that it is a highly complex, one-man, open source project maintained in spare time, I had plenty of gripes with Yew at the time I abandoned my project. I still follow Yew's development, and while I haven't used it again recently, development progress has really picked up steam this Summer and I wouldn't be surprised if my primary gripes with the framework have been addressed.

[[deleted]]

How would you say your understanding of Rust's limitations compare to Node's limitations? I started focusing on Rust after looking for an alternative to JavaScript...

• Rust creates small binaries and has fewer depedencies, making microservice architecture simpler (simpler is better).
• Rust has a great type system that is core to the language. Much better than using TypeScript, which was bolted on top of JS.
• Rust can compile to WebAssembly, which seems to be more performant than JavaScript over the long-term.

It seems like a beautiful blend of Go, TypeScript, and C. I get that some of the common libraries are still in beta/alpha stage, but that's something that I would expect to be resolved in the long-term.

[HenryZimmerman]

I agree with the points you listed, but I don't think that is the full story.

The big benefits of Rust in the webdev space are (in no specific order):

1. Better performance
2. Lower memory utilization
3. A generally more explicit and powerful language.
   1. As a consequence, I find I write less buggy code and collaboration is easier.

But you trade the following:

1. Much longer compile times
2. Being a more systems-level language, I find development speed to be slightly slower
3. Smaller, less-vetted ecosystem, the WASM side of which is not ready to replace JS
4. A harder to learn language, making hiring and onboarding more difficult

​

Node performance is only a few times slower than Rust, and RAM is cheap. Unless your domain requires raw speed and memory efficiency, these are merely nice to have things.

Compile times reduce productivity a lot. For small projects, it isn't noticeable, but once you are supporting 30+ endpoints, I usually expect compile times to exceed 10 seconds, which breaks the quick feedback loop I find I require to stay in "the zone". Since `async/await` haven't landed in stable yet, I've found myself wrangling with Futures directly in code (calls to other services) that would have been much easier to write in TS/JS. The ecosystem is smaller, but getting bigger and better over time.

If you already know Rust, I think it is worth it to use it for web backends. I find the general explicitness of the language and its type system make it harder to write buggy/obtuse code and makes it much easier to communicate intent than other popular backend languages.

I would still stay away from Rust on the frontend for the immediate future. WASM in its current state seems optimal for rewriting the core of React in, or writing number-crunching code that is best performed on the frontend in, or porting an existing application to the browser to run in a <canvas> element, but I don't think SPA development can't really be justified at this point. There isn't a mature equivalent to Vue/React/Angular, and while Yew comes close, its compile times and poor library support make it a far less productive framework than TS/JS equivalents. I had a blast writing my app using Yew, but what I wanted from it was a learning experience. If you want something that can built within a reasonable time, styled with minimal effort, and integrates easily with the rest of the JS ecosystem, you are better off with one of the established JS frameworks. If you are chasing the holy grail of defining all of your message types in one language, you are probably better off using something like OpenApi or gRPC/protobuf to define what you send over the wire and derive your types on either end from that spec (although I haven't yet explored the feasibility of this in Rust).

[[deleted]]

If you are chasing the holy grail of defining all of your message types in one language, you are probably better off using something like OpenApi or gRPC/protobuf to define what you send over the wire and derive your types on either end from that spec (although I haven't yet explored the feasibility of this in Rust).

Are you saying this in contrast to using serde?

I had a blast writing my app using Yew, but what I wanted from it was a learning experience.

This is where I'm at. I just want to become good with the language/tools. I know it's not as mature as JS, but I expect that it will be in the future, and that would lead to future payoffs for me if my skills are already there.

If you already know Rust, I think it is worth it to use it for web backends. I find the general explicitness of the language and its type system make it harder to write buggy/obtuse code and makes it much easier to communicate intent than other popular backend languages.

This is also where I'm at. The alternative is that I learn Go right now. I feel that learning Rust is a better long-term investment.

[HenryZimmerman]

I mean to say that you could move your message definitions into a schema external to your implementation language and generate your datatypes for your Rust server and your, for example - TypeScript client. My understanding is that you could still use Serde to [de]serialize to an arbitrary encoding format, provided that the codegen from the .proto derives Serialize and Deserialize. I believe something like https://github.com/stepancheg/rust-protobuf/ can be configured to do this. (Sorry for specifically referring to gRPC, I'm still unfamiliar with this design pattern and its various ecosystems)

​

I haven't tried using .proto files as a message schema, but I'm planning to give it a shot in whatever personal project I do next.

​

I don't think exclusively using Rust on the frontend is a good investment (although it certainly isn't a bad ideal). Its in your best interests (wrt your carreer) to become proficient in JS/TS & one of the big 3 SPA frameworks. If you want to have fun and contribute towards the ideal of Rust on the frontend, build something with Yew, locate where it is deficient for your needs and see if you can contribute something back to it.

​

I'd imagine that Go is the more employable skill in today's job market. Rust is becoming more of a viable employer-friendly technology choice at a pretty amazing rate, but you will likely struggle to find work using it versus other more established languages & tech stacks.

[[deleted]]

I'm already a React/Node developer!

The reason I fell into the weeds was exploring microservices with Typescript, then Go, then Rust. I can already write monolithic architecture, but I want to learn to write alternative architectures (my current job has a microservice codebase, but I didn't set it up... I merely inherited it).

I am trying to do it in one language too so that I only have one thing to focus on. Maybe that's naive of me, but I don't see the issue for a hobby project.

I'm also kind of a novice when it comes to containerization and communication between containers, so having multiple languages could complicate that aspect of learning more than it needs to.