Show HN: Rust Web Framework

> 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.

What even is a "model" if it doesn't have business logic? It sounds like you just want your model to be built from structs (that you call models) and procedures (that you call services). You can do that, but it can be quite hard to reason about what ways an entity can be updated, because any number of procedures could do it and all have their own ideas about what the business rules are. At this point your procedures might as well write back to the db themselves and just get rid of the "models".

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.

> * 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.

This is quite the claim. I despise service objects, personally. They end up scattering things around and hurt discoverability. There are other ways to do modelling that scale very well. There are a few blog posts on it, here's one from someone at Basecamp: https://dev.37signals.com/vanilla-rails-is-plenty/

This is of course very OO which I'm not a huge fan of. Elixir's Phoenix framework, for example, uses "contexts" which is meant to group all related functionality. In short they could be considered a "facade."

In any event, if you like services you like services, they can work, but saying MVC isn't enough for production-grade is a bit misguided.

I do agree that model callbacks for doing heavy lifting business processes is not great, though for little things like massaging data into the correct shape is pretty nice.

Interesting. I’ve rolled my own PHP ORM at work (forbidden from using FOSS libraries like Laravel) and found hooks to be extremely useful. Notably, my programming experience started with PHP for Wordpress which used hooks extensively, so maybe I’m biased.

Mine has a table spec that can translate into a SQL definition or spit out a nicely formatted HTML form. There’s a separate controller that handles all DB connections / CRUD operations, with before- and after-hooks that can easily cross reference with other tables and constraints if needed.

It all works pretty nicely, although I would still switch to Laravel in an instant if I could.

Thanks!

Re: callbacks. They are very nice, when you have CRUD endpoints that modify models directly from JavaScript [1]. It ends up being pretty DRY, especially since you'll find yourself modifying the same model from different places in the code, and without callbacks, you'll have bad data.

Re: service layer. It's a matter of taste, and you can probably avoid it until you're way in the thousands of LOCs. Rails and Django are all about building quickly - that's an advantage you shouldn't give away to your competitors. Service layer is a drag that you may need as an "enterprise".

Re: MVC not production-ready, we know that's not true, but appreciate the hot take, always a good starting point for a great discussion.

Re: existing ORMs, they were not flexible enough. I used ActiveRecord and Django as my inspiration; those are both excellent ORMs, while existing Rust ORMs lean too heavily on type safety in Rust in my opinion. The database should be the source of truth for data types, and the framework should allow for intentional drift.

Hope you get to try Rust soon. I've been using it for years, and I don't want to go back to Python or Ruby, hence this project.

Cheers!

[1] https://levkk.github.io/rwf/controllers/REST/model-controlle...

>* 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.

How is that so? Can't you add a service layer and call a service from a controller? I don't know about Ruby but for .NET and most Java frameworks this is possible.

To take an example from .NET frameworks, which I am mostly familiar with, you use WebAPI for web applications and MVC for websites. An API just returns data in JSON or whatever form and MVC returns HTML + javascript + whatever media and files.

A controller receives the HTTP request, does some logic, make DB requests, receives models and uses that logic to update a view and serves that view as an HTML file.

Controller - does actions and uses logic

View - describes how the page looks

Model - contains data

Nothing stops the controller to call a service layer which will call a data layer instead of just calling directly the DB.

I tried Diesel years ago, it was too "Rusty" for me. It made you define your schema twice, and couldn't use the same structs for inserts and selects (so 3 times, really). Overall, great first attempt at matching database types to Rust types, but the ORM needs to be more flexible and ergonomic - it's supposed to make writing queries easier, not harder :)

As for templates, writing your own language is almost a right of passage into 30s+ nerd club. I never read the dragon book, but I always wanted to take that class in school. There will always be different implementations of the same thing, and writing this one that mimics very closely what ERB (Rails) does felt right.

https://github.com/poem-web/poem is one Rust framework with swagger definitions out of the box.