This seems to be missing both an ORM and an argument for building without one; I'd have a hard time calling something a "full full-stack framework" without either an ORM or a very well-articulated statement for why that's a non-goal and what convention replaces it, allows for auto-generated admin pages, etc. 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…
Topcoat: The full full-stack framework for Rust
31–40 of 51 posts
Re: Topcoat: The full full-stack framework for Rust
#32Re: Topcoat: The full full-stack framework for Rust
#33Re: Topcoat: The full full-stack framework for Rust
#34I don't feel like this is solving the painpoints I feel in the Rust web framework ecosystem. And how is it full-stack if they don't have anything for the DB layer in here?
This will (very soon) integrate tighter with the Toasty ORM http://github.com/tokio-rs/toasty/ . E.g. tight form -> record flow. We are shipping now though to get usage. 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/")] async fn get_thread(thread_id: Uuid) -> Result, AppError> ```
Actix ``` #[get("/{name}")] async fn hello(name: web::Path) -> impl Responder ```
Why can't name just be String? Why can't `hello` endpoint just indicate clearly what it returns?
Re: Topcoat: The full full-stack framework for Rust
#35Exciting, but I’d give a lot for an equivalent to Django. There are very few problems I need to solve that are fixed by htmx style “full stack” apps, but many that are solved by the generated admin, authentication framework, caching, eventing etc. Unfortunately, you end up bound to Python’s poor performance and poor typing stories, which Rust solves in spades.
I don't use it personally because I don't like the look of SeaORM
Re: Topcoat: The full full-stack framework for Rust
#36This might sound dumb, but is Tokio slowly (if it hasn't already) become the Spring/Spring Boot for Rust?
Re: Topcoat: The full full-stack framework for Rust
#37How does this compare to Leptos ?
Re: Topcoat: The full full-stack framework for Rust
#38This might sound dumb, but is Tokio slowly (if it hasn't already) become the Spring/Spring Boot for Rust?
Depends on what you mean by that. Tokio the runtime is lean, and stable. Tokio the org is a collective of devs working on creating and maintaining a full ecosystem for building client and server apps with rust.
Re: Topcoat: The full full-stack framework for Rust
#39Earlier quoted context omitted.
This will (very soon) integrate tighter with the Toasty ORM http://github.com/tokio-rs/toasty/ . E.g. tight form -> record flow. We are shipping now though to get usage. What pain points do you have in the Rust web framework ecosystem? Happy to hear.
Oh cool, I will poke around Toasty. I am in the process of having LLM switch a project from some raw sqlx jank to Diesel, and mildly annoyed about some the boilerplate Diesel involves. Will have to see if Toasty solves it and whether it lets one query for arbitrary structs and add fields to structs from query results (e.g., in the README example for Toasty, explicitly joining on TODOs and mapping them to a simple fie…
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...