Show HN: Rust Web Framework

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!

I do agree that models should not contain bussiness logic. Not having bussiness logic in models is what Martin Fowler and Robert C. Martin call "anemic domain models" and is contrary to how legacy OOP-heavy and pattern-heavy enterprise development used to be.

However, after +20 years of development, I've came to the conclusion that encapsulation is a burden, not a feature and data should be separated from actions that are being performed on that data. It's called data oriented design or data oriented programming, and I am far from the only one that came to the same conclusion.

I so much agree with this, I want to hug you.

All this encapsulation for sake of encapsulation, and interfaces everywhere even for implementations that the application is married to. I once heard a wise man say: most of these design pattern only add code! And we should be weary of adding code that does not add features. Sure in some cases it makes the code easier to understand/read/refactor. But in many cases it becomes a holy goal with very little actual benefits. Clean architecture being the epitome of this.

> data should be separated from actions that are being performed on that data

This view is shared by nearly all dev that prefer functional programming. I also consider this true. FP-langs help you to "keep 'm separated", and OOP-langs historically make this very hard.

If you build an app on top of a db, you biz logic will get intertwined in the queries and the some of the code that's close to those queries (i.e. model code). That code represents you business logic. Trying to write the biz logic separate from the db is --to me-- just a way to make your project go over budget and hurt your performance.

>OOP-langs historically make this very hard

I don't think is just the langs, but mostly the old culture around those. I do .NET development using a data oriented approach and nobody calls me an incompetent developer. I also teach junior colleagues to be vary of OOP-ness for the sake of OOP-ness and overusing patterns.

I am not aware of any OOP language that demands inheritance, encapsulation or method overriding. It's the people who do.

>If you build an app on top of a db, you biz logic will get intertwined in the queries and the some of the code that's close to those queries (i.e. model code). That code represents you business logic. Trying to write the biz logic separate from the db is --to me-- just a way to make your project go over budget and hurt your performance.

I tend to separate, when possible, business logic from DB logic and from other kind of input like calling into external APIs. But I do that trough layers. I put a repository over the DB and its job is to just fetch data from DB and deliver it as data structures. I use that repository in a business layer.