←back to thread

Show HN: Rust Web Framework

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

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
kvirani ◴[22 Oct 24 14:59 UTC] No.41914951[source]▶
Nice, congratulations. It must feel so surreal launching this!

One of my biggest learnings from doing a bunch of web MVC through Rails over the years is that the framework should heavily discourage business logic in the model layer.

Some suggestions:

- Don't allow "callbacks" (what AR calls them) ie hooks like afterCreate in the data model. I know you don't have these yet in your ORM, but in case those are on the roadmap, my opinion is that they should not be.

- That only really works though if you not strongly encourage a service aka business logic layer. Most of my Rails app tend to have all of these as command aka service objects using a gem (library/package) like Interactor.*

* It's my view that MVC (and therefore Rails otb) is not ideal by itself to write a production-ready app, because of the missing service layer.

Also, curious why existing ORMs or query builders from the community weren't leveraged?

Disclaimer: I haven't written a line of Rust yet (more curious as the days go by). I'm more curious than ever now, thanks to you!

replies(7): >>41915143 #>>41915698 #>>41917900 #>>41917911 #>>41923445 #>>41923545 #>>41926524 #
ecshafer ◴[22 Oct 24 16:05 UTC] No.41915698[source]▶
> One of my biggest learnings from doing a bunch of web MVC through Rails over the years is that the framework should heavily discourage business logic in the model layer.

I am curious where this comes from, because my thinking is the absolutely opposite. As much business logic as possible should belong in the model. Services should almost all be specific more complex pieces of code that are triggered from the model. Skinny controller, Fat Model, is the logic of code organization that I find makes code the easiest to debug, organize, and discover. Heavy service use end up with a lot of spaghetti code in my experience.

The other part is that from a pure OOP pov, the model is the base object of what defines the entity. Your "User" should know everything about itself, and should communicate with other entities via messages.

> Don't allow "callbacks" (what AR calls them) ie hooks like afterCreate in the data model. I know you don't have these yet in your ORM, but in case those are on the roadmap, my opinion is that they should not be.

This I agree with. Callbacks cause a lot of weird side effects that makes code really hard to debug.

replies(9): >>41916047 #>>41916627 #>>41916992 #>>41917222 #>>41917360 #>>41918421 #>>41919930 #>>41921921 #>>41922484 #
1. Zanfa ◴[23 Oct 24 06:48 UTC] No.41922484[source]▶
> As much business logic as possible should belong in the model. Services should almost all be specific more complex pieces of code that are triggered from the model.

In my experience with fat models is that it works for trivial cases. Once you get more complex business rules that span multiple models, the question becomes which model should it be implemented on. For example in a e-commerce app you might need to evaluate User, Product, DiscountCode and InventoryRow tables as part of a single logical business case to determine the final price. At that point it doesn’t make much sense to implement it on a model since it’s not inherent to any of them, but a PriceCalculator service makes sense.

replies(1): >>41923559 #
2. cies ◴[23 Oct 24 10:14 UTC] No.41923559[source]▶
Exactly how we do services.

We have one model file per db table (a "repository") in which we define all queries that "logically belong to that table" (sure they do joins and/or sub-queries that involve other tables, but they still "logically belong to a specific table").

Once we need logic that combines queries from several "repositories", we put that in a "service" file that's named after what it does (e.g. PriceCalculator).

Most of our business logic is in the models (repositories and services), other encapsulated in the SQL queries. Repositories never call services. Model code never calls controller code. Pretty happy with it.

replies(1): >>41930662 #
3. tcfhgj ◴[24 Oct 24 00:27 UTC] No.41930662[source]▶
When you join two tables, which model does the query belong to?
replies(1): >>41933269 #
4. cies ◴[24 Oct 24 08:13 UTC] No.41933269{3}[source]▶
We'd not call it a model, we have no notion of "a model", merely a package called "models" (in line with MVC separation).

We do have repositories. And when joining it could belong to both tables, and thus to both repositories. In those cases the devs picks one: the one that it most prominent to him.