Most active commenters
  • wtetzner(5)
  • stickfigure(3)

←back to thread

Show HN: Rust Web Framework

(github.com)
488 points levkk | 25 comments | 22 Oct 24 14:15 UTC | HN request time: 1.372s | source | bottom

Hi everyone,

I've been "funemployed" for a few months and with all that free time and idle hands I wrote a full web framework (think Rails, not Flask) for Rust.

It's boring old MVC, has its own ORM, templates, background jobs, auth, websockets, migrations and more. If you're keen but don't feel like rewriting your app in a different language, Rwf has a WSGI server to run Django (or Flask) inside Rust [1], letting you migrate to Rust at your own pace without disrupting your website.

I think Rust makes a great prototyping and deploy straight to production language. Now it has yet another framework for y'all to play with.

Cheers!

[1] https://levkk.github.io/rwf/migrating-from-python/

Show context
imiric ◴[22 Oct 24 21:25 UTC] No.41918890[source]▶
After years of working with web frameworks in Python and Java, and then picking up Go along the way, I've come to appreciate Go's approach much more. That is, with a rich and capable standard library, you really don't need traditional frameworks. Need an HTTP server, router, etc.? Use stdlib. Need templates? Use stdlib. Need an ORM? You don't, but you may want to consider a small 3rd party query builder library of your choice. And so on.

This avoids depending on a complex framework that may or may not exist in a few years, improves security by minimizing the amount of 3rd party dependencies, keeps the learning curve low for any new developers joining the project, and is more flexible and easier to maintain. I don't have experience with Rust, and judging by the comments here, web frameworks might still be useful for it. Which is a shame, since the batteries included stdlib approach is far superior IME.

Anyway, I don't want to shoot down your efforts. Congrats on the launch and good luck!

replies(13): >>41918959 #>>41919110 #>>41919336 #>>41919738 #>>41919823 #>>41920300 #>>41920442 #>>41921397 #>>41922584 #>>41923056 #>>41923336 #>>41924884 #>>41924982 #
1. metadaemon ◴[22 Oct 24 21:53 UTC] No.41919110[source]▶
Not needing an ORM made me laugh
replies(2): >>41919353 #>>41920132 #
2. sunrunner ◴[22 Oct 24 22:26 UTC] No.41919353[source]▶
Why is that?
replies(2): >>41919390 #>>41927294 #
3. stickfigure ◴[22 Oct 24 22:32 UTC] No.41919390[source]▶
Your programming language has objects. Your database has relational tables. By definition, you need to map between the two.

You can write your own or you can use someone else's. Those are the two choices.

replies(7): >>41919421 #>>41919544 #>>41919839 #>>41920270 #>>41920443 #>>41920482 #>>41921770 #
4. BlarfMcFlarf ◴[22 Oct 24 22:38 UTC] No.41919421{3}[source]▶
You can map objects to db updates, and map query results to objects. Neither of those objects needs to have a mapping to actual relations, like how ORMs insist on.
replies(2): >>41920405 #>>41920435 #
5. sunrunner ◴[22 Oct 24 22:54 UTC] No.41919544{3}[source]▶
By definition, you only need to do the minimum to move data from one process to another to get things read or written.

That doesn't mean you need an entire system to represent every table as an object-like thing (which is what I assume when people say ORM). It's actually possible to just emit queries to read and write the exact data that's required in the shape that makes sense for the caller.

6. wesselbindt ◴[22 Oct 24 23:30 UTC] No.41919839{3}[source]▶
> Your database has relational tables.

Mine doesn't, so I don't need an ORM. Plus, I think that when people say ORM, they mean more than just a map from the relational model to the object model and back. They refer to things like hibernate and SQLAlchemy and all the extra stuff that comes with that, like the active record antipattern, and a query builder which successfully encapsulates all trivial queries (which don't need encapsulation) but then as soon as you need to do anything even remotely complicated, the abstraction leaks. I'll be honest, not a fan of ORMs.

7. rad_gruchalski ◴[23 Oct 24 00:15 UTC] No.41920132[source]▶
Orms in go make little to no sense. As soon as one has a little bit more complex scenario, one ends up in the raw sql string mode anyway…

Like, try to build dynamic nested ands with ors using jsonb with gorm. Maybe there are two people on this planet who would like “aha, I know”. Just use your standard sql strings with prepared statements.

8. ◴[23 Oct 24 00:32 UTC] No.41920270{3}[source]▶
9. threeseed ◴[23 Oct 24 00:48 UTC] No.41920405{4}[source]▶
Only for basic objects.

The minute you add relationships your approach becomes unusable.

There is a reason ORMs have persisted for over 30 years.

replies(1): >>41920461 #
10. dragonwriter ◴[23 Oct 24 00:52 UTC] No.41920435{4}[source]▶
Query results are actual, if transitory, relations.

And db updates are either relations or tuples (and a tuple is a relation with cardinality of 1, so...)

replies(1): >>41920476 #
11. wtetzner ◴[23 Oct 24 00:53 UTC] No.41920443{3}[source]▶
There's a difference between mapping database tables to objects and just copying query results into structs.
12. wtetzner ◴[23 Oct 24 00:56 UTC] No.41920461{5}[source]▶
No it doesn't. Why would relationships matter? You handle the relationships in SQL queries, and just copy query results to structs.
replies(2): >>41920622 #>>41920907 #
13. wtetzner ◴[23 Oct 24 00:58 UTC] No.41920476{5}[source]▶
You can be pedantic if you like, but this is obviously not what anyone means by "ORM".
replies(1): >>41920490 #
14. deznu ◴[23 Oct 24 00:59 UTC] No.41920482{3}[source]▶
I kind of agree with this. Data in a database is often relational (hey it might not be, but it's still nice to represent it in a struct sometimes, rather than 10–20 different variables which can change anytime your database changes).

I've been using Go recently, and while I'm not convinced on an active-record style ORM in Go (I don't think the language is dynamic enough, and I'm not the biggest fan of codegen), I've been loading the row data from Postgres into a Result struct (pretty much a 1:1 mapping of the Postgres result set into the struct), and then using another function to load the Result struct into struct with their relationships attached (using tags on the structs to define the relationships between them). This has worked great using reflections & generics.

replies(1): >>41920846 #
15. dragonwriter ◴[23 Oct 24 01:00 UTC] No.41920490{6}[source]▶
Its literally the exact things that ORMs map between: query results -> objects and object changes -> database updates.
replies(1): >>41994256 #
16. stickfigure ◴[23 Oct 24 01:16 UTC] No.41920622{6}[source]▶
> copy query results to structs

Congratulations, you've invented an ORM.

replies(3): >>41920796 #>>41920891 #>>41994227 #
17. ursuscamp ◴[23 Oct 24 01:39 UTC] No.41920796{7}[source]▶
That’s 1% of an ORM.
replies(1): >>41926785 #
18. __mattya ◴[23 Oct 24 01:45 UTC] No.41920846{4}[source]▶
And chance this is open source?

I’m building something similar and I can’t decide on the relationship struct tag syntax to use. Would be neat to see how others are thinking about it.

19. threeseed ◴[23 Oct 24 01:51 UTC] No.41920891{7}[source]▶
Majority of ORMs really are nothing more than this.

But then it's nice to have something that generates optimised, database-specific SQL, can handle date/number conversion, supports many-many relationships, converting BLOB to binary streams etc.

20. ◴[23 Oct 24 01:53 UTC] No.41920907{6}[source]▶
21. Thaxll ◴[23 Oct 24 04:15 UTC] No.41921770{3}[source]▶
ORM by modern standard is not that, it's basically let me interact with the DB without knowing SQL.

Every language need to deserialize results into some object so by definition every language that deal with a DB do some form of ORM. So ORM is meaningless in that context.

22. stickfigure ◴[23 Oct 24 16:45 UTC] No.41926785{8}[source]▶
It's at least 30% of most ORMs. And if your homebrew ORM actually gets wide use, it'll grow from there.

Source: Wrote an ORM that other people actually use. Still adding features, twelve years later.

23. metadaemon ◴[23 Oct 24 17:28 UTC] No.41927294[source]▶
Why did it make me laugh? I thought the delivery was funny is all.
24. wtetzner ◴[30 Oct 24 12:45 UTC] No.41994227{7}[source]▶
This is clearly not what anyone means when they say they don't want an ORM.

An ORM library maps an entire relational database to a graph of objects, with the intention of abstracting away the relational database. Copying query results to structs doesn't actually do any of that.

https://en.m.wikipedia.org/wiki/Object%E2%80%93relational_ma...

25. wtetzner ◴[30 Oct 24 12:50 UTC] No.41994256{7}[source]▶
No, ORMs abstract away the relational database and present it as if it were some kind of object database. Needing to map query results to structs is just incidental, and is completely missing the point of an ORM.

If copying query results to a list of structs is enough to qualify as an ORM, then the term is so generic as to be entirely useless.