What pain points do you have in the Rust web framework ecosystem? Happy to hear.
> What pain points do you have in the Rust web framework ecosystem? Happy to hear.
I think I have more "gripes" than strong pain-points admittedly. Off the top of my head, complaints about boilerplate to simply access path params and JSON bodies.
Currently using Rocket, but it looks dead and unsupported. It's not perfect, but I like aspects of it, such as the global error handling and relative ease of accessing params.
Probably going to seem nitpicky, but compare these 2:
Rocket ``` #[get("/chat/threads/<thread_id>")] async fn get_thread(thread_id: Uuid) -> Result<Json<ThreadResponse>, AppError> ```
Actix ``` #[get("/{name}")] async fn hello(name: web::Path<String>) -> impl Responder ```
Why can't name just be String? Why can't `hello` endpoint just indicate clearly what it returns?
I'm not 100% following. Feel free to ping me in discord (https://discord.gg/tokio) or open an issue on Toasty and we can dig into it. Toasty is also pretty new, but maturing fast.
The other points are valid. There are challenges with extracting params and a type system. This is how topcoat does it: https://docs.rs/topcoat/latest/topcoat/router/attr.path_para...
For the other part, I am basically saying I don't like, if one has a FK from Posts to Users, the ORM semantics of having user.posts automatically eagerly populated OR Deferred. I personally prefer to write SQL DSL in whatever language I am using whenever there is a join and explicitly add gather and add the posts. But I should probably get over that. Most of the time that is more cumbersome and having them eagerly there reliable is usually what I want anyways.
- Rust Fanboy; use it in several domains (embedded, PC applications, bio/chem)
- Web dev is the main thing I still use Python for, as there's nothing on Django's level.
Better to ship early and hear what people want though :)
One thing to keep in mind, the main reason for Topcoat to exist is that many organizations are already using Rust for infrastructure-level or performance sensitive reasons and often just want to build a web app using the programming language they already use.
I'm not sure that projects like Topcoat and something like their ORM is a great direction for the project, and worry that they will possibly gain outsized adoption in the community based on name recognition rather than merit.
\m/_(>.<)_\m/It is early, a lot is coming, but you can already build good stuff now.
Unfortunately, you end up bound to Python’s poor performance and poor typing stories, which Rust solves in spades.
jinja2rs::filters : https://github.com/westurner/dsport/blob/main/src/jinja2rs/s...
jinja2rs::filters::django : https://github.com/westurner/dsport/blob/main/src/jinja2rs/s...
Which Rust components are like the Django ORM and django.contrib.admin and DRF/FastAPI; with convention over configuration and tests and great docs?
dj-bolt/django-bolt: Rust-powered API framework for Django achieving 60k+ RPS. Uses Actix Web for HTTP, PyO3 for Python bridging, msgspec for serialization. Decorator-based routing with built-in auth and middleware. https://github.com/dj-bolt/django-bolt :
> Faster than FastAPI, but with Django ORM, Django Admin, and Django packages. [...] Django-Bolt is a high-performance API framework for Django, providing Rust-powered API endpoints capable of 188k+ RPS.
I don't use it personally because I don't like the look of SeaORM
This would take a long time to get feature complete with the core of those big full stack frameworks, but I'm rooting for it! Getting to use the Rust type system with a full stack web framework sounds incredible.
There already is an ORM (https://github.com/tokio-rs/toasty/). You can see a sketch of the roadmap here: https://github.com/tokio-rs/topcoat/issues/104
A decade? More like 21 years
When I see syntax like $(...), it looks like a transpiler that embeds Rust AST inside JS. I think it would make Rust's already terrible developer experience even worse. I think the actual value of the string length on the server side will differ, specifically `len()`.
And I'm not sure if bundling binaries and assets this way is the right approach. This feels less like Rust and more like a DSL that intersects Rust and JS. it feels like something different.
I like Tokio and think it's really well made, but this framework seems a bit wrong to me.
That said, if you are up to it, I would ask that you try using it and provide your thoughts after using it as an issue. Feedback is appreciated.
I'll try it out next time and give feedback later. And you're right, it's just a difference of opinion.
Also, for the API side, Unicode strings are usually 4 kinds right? I think using Rust-style snake_case, we might need separate functions like len(), utf16_len(), and so on. But I'm not sure how to handle the abstraction between libraries and browsers.
Sorry for being critical. I'm not that good of a programmer, so it might be a mistaken observation. Please check it.
htmx+ tailwindcss is the one combo that is right and I use it so seeing is the direction give me hope.
Some notes, I hope can be considered!:
- The main thing is the auto admin, then `auth`, is great that the `auth` is mean to have a one-to-one connection for your own extensions
- The main pain is that everything is tangled to the ORM and the auto-admin
What I have done informally is that with traits I have something like `ListQuery` and compose `Paginate(ListQuery)`.
Then pure descriptors of what the ui DO, but not what it looks like and not even html at all.
THEN, I inject the stucts/enums (all Ui is things like `Label{...}` with not logic at all in templating, all the server side is in charge of pre-render) into some templating and there is where the ui is alive, but replacing is 100% doable and expected.
What I miss is a way to introspect to auto-generate things more auto.
I don't think an ORM is necessary, but I do think you need to say what people are meant to do instead and how your batteries are included without it, if you're going that direction.
Re: OpenAPi you want to consume or provide an OpenAPI endpoint? I’m assuming you want to provide one. This is probably on the medium term roadmap after other stuff like UI, tighter ORM integration, email, etc…