The only way this feels like an improvement over Axum (a library this is built on) is a tiny syntactical change in how one hooks up a route handler function to a route.

Otherwise, it feels like it adds nothing on top of Axum. In fact, I don't see a way to do statically typed query param extraction with this, so I'm not even sure if the tiny syntactical change is worth it.

Am I missing something?

To me, most of these things are (well look) too dynamic; I like prototyping in clojure where I can write vomit to try things out fast, but when it has been done and dusted, I want to cast it in concrete and steel, which includes statically typed query/body params. It is vital to how we work because any changes there would probably mean something is very wrong (malicious most likely).

I never really drank the clojure (which I really like by the way and, like said, I use for prototyping/spelunking) creator koolaid that web apis are changing all the time so you need to be flexible. This, in practice, with companies that don’t fall over tomorrow, doesn’t happen that often.

you can statically type query param extraction with c.parse_params() and c.parse_query()

let value: Json<MyStruct> = match c.parse_params().await

< https://github.com/graphul-rs/graphul#-resource >

Thanks! But you haven't convinced me that this adds any value right now on top of Axum, at all. Perhaps this is sort of an early release, since you mention elsewhere that the plan is to support GraphQL (and that would be the value-add)?

the idea is not to convince you, if you like another web framework like Axum, hyper, or actix you can use it, this framework is for other developers ( javascript, python, or rust developer that wants to start building microservices with rust with a friendly syntax like express or flask)

I now understand the primary value-prop of this project is the friendlier syntax. Thanks for clearing that up!

or you can use an extractor in function base handlers, in struct base handlers you can use context c.parse_query()

I agree that Axum already fits the bill on its own.

ok great, continue using your favorite tools, graphul is for other developers; the idea is to receive positive feedback; I don't like discussions about what programming languages or frameworks are better than another, Golang vs Rust, etc

Graphul is an Express inspired web framework using a powerful extractor system built on top of Tokio, Tower, Axum, and Hyper. Designed to improve, speed, and scale your microservices with a friendly syntax, Graphul is built with Rust.that means Graphul gets memory safety, reliability, concurrency, and performance for free.

https://github.com/graphul-rs/graphul

Nice, I’ve been wondering when somebody would come along and do this.

> Designed to improve, >>> speed <<<

How does it speed if it’s built on top of other frameworks?

why is it called Graphul?

because, it will support graphql

Is there actually any html templating here? At least I didn’t see any examples in the linked page. I wouldn’t call it a web framework if it’s just dishing out more or less raw HTTP responses. That said, even just an API framework for the front edge is probably already a bit past the point where I draw the line in terms of Rust being a good fit. It’s not that Rust can’t be good at it, but I think there are many more productive ways to accomplish all the API-level crap without really sacrificing anything.

Hi. Is it something that comes with HTML templating? Im curious what people user if (any) use Rust as their ‘web backend’. Assume the app is only for web app. Do people just separate rust as API , and use something like Nextjs, etc.. or there’s full featured framrework for building website in Rust? Thanks

In strongly typed languages like Rust, composing smaller libraries is usually quite painless, so you don't need a large framework.

Personally for backend Rust I use rouille[0] for the server (it's very simple and async-free), askama[1] for compile-time HTML templates and (if a SPA is unavoidable, as that is of course always to be avoided if at all possible) yew[2] for client-side WASM.

Now this stack is what I like personally, but there are many options that you can combine, some more full-featured than others. Check out https://www.arewewebyet.org/ for a partial overview.

[0]: https://github.com/tomaka/rouille

[1]: https://github.com/djc/askama

[2]: https://yew.rs/

anyway do you go with a specific full featured framework? or you just combine things?

wow thanks for all the refrences! appreciate it!

you can use HTML template with Graphul and askama

the readme.md has been updated https://github.com/graphul-rs/graphul

https://github.com/graphul-rs/graphul#-templates

Looks like another Flask analog. I love Rust. Use it for most of my projects - but not websites. This doesn't threaten Python and Django; would be more interested in something robust like Django, vice a Flask analog.

Note: if you are using your favorite Rust framework like actix, rocket, etc, and don't have a positive feedback, graphul is not for you, graphul is for javascript, python, ruby, or rust developer that wants to start building microservices with rust with a friendly syntax like express or flask.

I don't like discussions about what programming languages or frameworks are better than another, Golang vs Rust, etc

thanks, be positive :)

We don't need Rust frameworks that act like javascript.

As others have said, this doesn't seem to add more to Axum, in fact, it seems to remove features?

I dig poem-openapi, personally.

remove features? Graphul has all features that you need to build an API, the next release will support Graphql

Slightly off topic, but: i noticed more and more rust frameworks using async. I was under the impression that most of the time async makes programming much harder, while increasing peak performance. But is that trade off worth it for most people?

I never use async when given the choice. The syntax hides away the asynchronous nature of the code so well that I frequently use it incorrectly.

I much prefer threads, which are convenient to use in Rust anyway. Is it possible to go faster? Maybe, but how often is it really a bottleneck given how fast Rust already is?