Rust, Wasm, Evo 2024
Blazing Fast Registration @ The World's Largest E-Sports Event!
In 2022 I used Typescript (React) and Go for the Evo Registration App.
This year, 2024, my scope of work grew over the course of planning.
I became responsible for the entire onsite registration process.
My gratitude has been expressed on LinkedIn.
Daniel Clough
"By the Numbers" was compiled & analyzed by Evo's bracket directorMargot Wasserman
Quality of Life
A complete re-write of the old app was not required, there would be enough new features that using Leptos (Wasm) instead of React (Javascript) seemed justified...
Actually, let's be honest.
I really wanted to drop React.
And, Leptos makes fast Apps!
Leptos compares well to React in terms of performance, but the developer experience is incomparable. Rust is not Most Loved because of the mascot.
The Largest E-Sports Event In The World!
Evo blew it out of the park this year!
The biggest problem was the arena was too small. 😭
I'm not going to pretend that the old React app wouldn't have been able to manage the volume... of course it could.
But, the speedup from Leptos certainly didn't hurt.
Registration this year was the fastest ever!
Explosive Growth!
The growth in competition participants, vendors, and fighting game enthusiasts doesn't validate such a drastic overhaul in my software stack.
However, general app complexity does.
I wanted a fairly sophisticated PWA including accounts, state management, QR code scanning, picture taking, file upload, emails, printing, and ...
Architecture
Since I was already using Go I could have just used that to create my Wasm... but I had been playing with Leptos for a while. I created an Pure Rust LLM Chatbot (Github) to explore a Rust/Wasm stack, and I was enjoying it!
The Leptos Community (Discord) seems to generally prefer an integrated Server Side Rendered (SSR) Frontend/Backend using Cargo-Leptos (Github). This has many advantages, however I wanted to use Client Side Rendering (CSR), so my process uses Trunk (Github) for development and an Axum (Github) server for production. There is great documentation.
App Complexity
I take advantage of Rust's workspace features to isolate the Wasm and Rust code. For a small project my setup is a bit awkward compared to Cargo-Leptos (which allows all of the code to live in a single workspace member). As complexity grew however, taking advantage of the Rust workspace features started to pay off with greater organization from the code separation.
From Development to Production
In the beginning there was the word(s), trunk serve.
After 7 (or so) days of creation I was ready host for production.
I like my development and production environments to have essentially no differences. Using Trunk for Development is convenient, but the behavior of the Trunk server is not 100% the same as the Axum server that I have setup, especially w.r.t. route handling. It would be super fantastic if Trunk had production hosting built in, however, it is a pretty simple thing to host on Github, Netlify, Vercel, or a homespun solution.
Open Source?
I mentioned in the LinkedIn post that my software stack is all open source, so did I share the love and open source the Evo registration software? Not yet?
While the app I created for Evo 2024 is not open, you can check out the Fireside-Chat Bot that uses basically the same architecture.
danielclough
Commits Welcome! (AGPLv3)
Fireside-Chat was my test run to see if I wanted to build a work app with Leptos and/or HuggingFace/Candle (Github). A lot of the decisions were informed by what technologies I wanted to use and is not necessarily representative of best practices.
P.S.
While not Rust/WASM, you may be interested in open source Python code (Github) used in the production of Evo 2024, including the post linked in the LinkedIn post above.
Follow on Social Media
LinkedIn
Instagram (Photography)
Facebook (Photography)