hckrnws

> I think Rust makes a great prototyping and deploy straight to production language

Sorry what? Isn't Rusts whole thing is that it prevents you from prototyping wild ideas in the name of memory safety?

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!

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

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

Domain models are hard to do well and I think the SOA era brought a lot of confusion between data transfer objects, serialized objects, anemic domain models, and domain models.

[0] https://martinfowler.com/bliki/AnemicDomainModel.html

Business logic should sit in the domain model, but not the orm model. The domain model should be an object that is not coupled with the web framework. In the Clean Architecture approach this is called an Entity.

This sounds to me like the standard OOP versus Data Oriented programming divide. You want to think of code as a bunch of bundles of data and associated functionality, GP wants to think of code as data models and services or functions that act on them.

In general, I think 'unit test' level business logic should be in the model (think configuration for data-driven workflows, normalization logic, etc) but 'integration test' business logic should be in a service (callback logic, triggering emails, reaching across object boundaries, etc).

I think most people agree about skinny controllers but I've definitely seen disagreement on if that gets moved to fat models or service objects.

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

Also Django signals, Symfony events... makes things extensible but also hard to debug indeed.

attach a debugger to the running process

It's because people ended up with models that were thousands of lines and difficult to reason about. Out of curiosity, did you end up running into this issue and how did you deal with it?

I work on a few projects that do have a model that is over a thousand lines long. A lot of times as the model gets more complex, you start moving associated model logic into their own models, which helps reduce the problem space. I think its fine because the logic ends up being cohesive and explicit. Whereas services end up with logic being hard to track down when they get very large and usually scattered.

If I had to choose between thousands lines in models and thousands lines in controllers I'd definitely take "fat" models over "fat" controllers.

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.

Please don't feel obligated to answer if you can't, but why can't you use FOSS libraries like Laravel? Are you not even allowed to use MIT licensed stuff? What industry do you work in?

Small aerospace company. We had a really old school CEO at the time the project was started - didn’t even want us using GitHub since it was on the cloud. Everything runs on an on-premise IBM i Series (AS400 / IBM Mainframe).

I pushed hard and was able to get us to the point where stuff runs in PASE with modern languages (like PHP).

It’s not any specific licensing issue, just organizational distrust of anything that isn’t paid for.

Are there not any Laravel shops that would take your money so you can "pay" for it?

Thanks for sharing that. AS400 always catches my eye after doing in internship at IBM, working with AS400 back in 2000.

Thanks, that is quite fascinating! I recently spoke with a very old school IT guy who was setting up his brother's IT stuff for a new business, and he is militant about on-prem and other stuff too. It's a very interesting mentality, though so foreign to me as I strongly gravitate toward FOSS instead of away from it.

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

It would help a lot if you would clarify what you mean by “service object”. In my experience a single method on a service object would define a transaction. Is that what you mean by “service object”?

Along the lines of what OP is talking about, part of the problem is that Rails has no service objects, so I have seen a handful of different ideas of what they mean (probably no more than 10).

The one I've seen he most is stuff like `UserRegistrationService` or the like. These things can end up getting scattered and in general, I would rather just talk to the business object, ie, `User.register` which can delegate to a more complex private object handling it. It's basically "inverting" things. The win here is that things are more discoverable (You can look at the user object and see a list of everything it does) and more importantly draws better boundaries. This way the web layer only has to know about `User` instead of `RegisterUserService` and `DeleteUserService` etc.

Again, services can work and aren't inherently bad, but plain MVC can certainly also work.

I feel like the same people that like UserRegistrationService will argue that database table names should be plural because it reads better, which is wrong for similar reasons.

I don’t really follow. My focus wasn’t on the naming but the location of responsibilities.

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

Some people use the ORM models as pure persistence models. They just define how data is persisted. Business models are defined elsewhere.

I think makes sense when you application grows larger. Domains become more complex and eventually how data is persisted can become quite different from how it is represented in the business domain.

I would kinda expect REST framework to be able to generate Swagger (aka OpenAPI) definitions out of the box. That's one of the killer features of FastAPI in my opinion.

Also, I don't really understand what is the reason for creating your own ORM instead of integrating with, let's say diesel.rs [0] and what is the reason for inventing your own template language instead of just picking one of the most popular existing template engines [1].

Other than that this project looks really interesting and I will definitely keep an eye on it.

[0] https://diesel.rs/

[1] https://crates.io/categories/template-engine

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.

Same: I was put off by keeping track of models in triplicate, and the lack of automatic migrations. These are considered features, vice bugs; it's not for me.

I tried diesel about 5 years ago. I needed to do relationships where the foreign key lived on the other side of the relationship from what diesel wanted. IIRC diesel only supported the key on a specific side, I think it was a M:1 relationship. Diesel docs said this was unsupported. I was still learning traits at the time but navigating how to implement this in diesel was beyond me. I used sqlx and moved on.

Never been a fan of ORMs in general. Working with the extra abstraction layer on top of SQL can be painful.

Re ORM: fair enough, I don't have any experience with Diesel, just wanted to know if you have an actual reason or if it's just a case of NIH [0] syndrome :)

Re templates: I understand that writing a new template engine can be a very fun task (it is both hard enough not to be boring and easy enough not to feel daunting). I also thought many times of creating my own template engine to fix things that I don't like in the language that I am currently using (mostly jinja2).

But if you intend this project to become an actual production ready solution, I see a lot of good reasons not to reinvent template language:

1. Forcing users to learn yet another template language is an additional entrance barrier

2. Tooling support. Existing languages might already have a good tooling support (coming from Python world: PyCharm supports both Django templates and jinja2 very well) including syntax highlighting, auto-complete, auto-formatting, linting etc. Are you going to create all of it yourself?

3. You mentioned planned migration from Python. How exactly I am supposed to manage templates during the transition period? Do I have to have two copies of each template: one in legacy language and one in your new language? If you had a template language compatible with Django/jinja2 [1] this problem would not arise.

4. Whether we like it or not more and more people are using LLMs for coding. This potentially could solve the issue of migrating templates. I expect LLMs to perform really well on the task of "translating" a template from a <popular template language A> to a <popular template language B>. The problem is that if your template language is brand new, LLMs probably didn't have enough examples in their training sets to "learn" its syntax. So, basically, you are setting up your users for a boring, tedious and error prone task of rewriting each template manually without a proper support from their IDE/editor. Meh.

BTW, Django makes it very easy to bring your own template engine [2].

[0] https://en.wikipedia.org/wiki/Not_invented_here

[1] https://github.com/mitsuhiko/minijinja

[2] https://docs.djangoproject.com/en/5.1/howto/custom-template-...

In random order:

1 & 2. It's not really a new language. It's very similar to ERB, so existing tooling, including syntax highlighting, etc., shouldn't be an issue.

4. LLMs are actually pretty good at "understanding" programming language syntax and replicating it to generate code, so even a new language would work. Besides, there is really nothing new under the sun, so similarities with existing languages would help here.

3. I migrated once from Jinja to Sailfish [1], it wasn't so bad. All template languages are roughly the same: start code tag, some simple code, end code tag, maybe a loop or an if statement, but the vast majority of it is print a variable. It would be nice to bring your templates over during a migration, but they are typically a small portion of your code compared to business logic, so I don't think it'll be a roadblock, if someone wanted to attempt this at all.

[1] https://github.com/rust-sailfish/sailfish

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

Know of any similar frameworks that work the other way around? Where you can Keep an openapi definition as the source of truth and validate that your server follows it, I mean.

I agree. API-first is the way! Change your schema, auto-generate types into your code and use them for your server definition. It's just faster and more secure this way. Use api-fiddle.com or spotlight.io to work with the schemas (branching, sync with Github).

In a fully typesafe world, it should be pretty hard to derive from the shema this way.

Rswag is still my favorite openapi-related project. You write integration tests against the server and get an openapi spec as output. But thats for rails.

As others suggested, I would diff against a generated one, then potentially treat the generated one as source of truth in the future... Then diff accordingly as it changes.

You can simply diff it. Define the OpenAPI spec, have the framework generate a spec, compare.

You could generate a spec for the service and then diff to the expected perhaps.

100% agree that generating OpenAI from your server is a killer feature, it works well for us with Dropshot.

Just FYI - since this is an asynchronous framework you probably would want something like sqlx versus Diesel (which is sync if I recall correctly)

What an amazing name choice, certainly one way to end up at the top of search results :P

To be serious, good job!! Building a good framework is a shockingly large task, and it’s always nice to see people exploring the design space and trying for new ideas.

> What an amazing name choice

"Row" would be another good name choice, that would also be easier to say than 'rwf'.

RustOnWeb.com is even able to buy for $10 :)

Just say'n

As SRE, I got interested in https://levkk.github.io/rwf/migrating-from-python/. On one hand, this is crazy neat you were able to pull it off. On the stability SRE hand, I'm internally screaming. At scale, this should be handled by Reverse Proxy (Caddy, Nginx, Traefik, whatever)

I thought the same thing, but this allows you to test your changes locally as an application engineer, without the back and forth. This goes back to the good old monolith vs. microservices debate.

Writing a stable WSGI server is possible, and not very hard with a bit of attention to detail, e.g. thread counts, vacuum (just like good old php-fpm, restart every n requests...), etc. Basically if you implement most options uwsgi has, you're on the right path. It's on the roadmap to make Rwf comparable to running Gunicorn.

Sure, but Gunicorn doesn't try and run Node. I totally get benefit for development; I was just worried about someone YOLOing this into production.

I imagine the author assumed a technical audience wouldn't need to be told of the necessity of a reverse proxy in front of the wsgi server

As SRE, you assume 100% wrong. Devs totally need to be told "Please don't do this in production." They will ignore you but hey, you might reach a few.

As a Python dev, I imagined the same.

> (think Rails, not Flask)

I like that... we need more (or better) opiniated frameworks a la rails/django in static languages.

I've been evaluating and building out small prototypes with all the usual suspects for backend Rust work. So far I've reluctantly agreed with the hive mind that Axum on balance is the best choice, despite being lower-level than I'd like.

Other contenders were Loco (but was TOO much like Rails) and Rocket (whose macros only started to bother me after writing more Rust).

Your framework seems to perfectly match my criteria of "batteries-included, but not too prescriptive". Great addition to the ecosystem!

What about Actix? There were some discussion on HN a while back related to Actix vs Axum if I recall that.

@levkk How do you thing it compares to loco.rs, I'd like to understand the differences.

Awesome, looking forward to testing it out. I really like that idea of being able to gradually migrate WSGI (Django) apps, or even support running both at the same time.

Do you plan on adding CRUD generators? That was the killer feature of MVC frameworks

It's there but the docs aren't written yet. See the REST example in the repo. I'll have some docs for that soon.

Sounds nice, years of Django dev (with some other dev sprinkled in) has really taught me the value of boring old MVC and the rest of the ingredients, will def be having a look.

Great work!! I was just talking about how this is a major gap in Rust and here you are the very next day! Looking forward to use and contribute!

What are these projects missing that you feel there’s a “major gap” in the web framework space?

rocket.rs, actix, axum, warp, gotham, ruille

Looks cool! How does it compare to loco.rs?

Based! Django/Rails in a god tier language!

my suggestions:

- async-trait should be stabilized now, so you shouldn't need the macro anymore

- Add opentelemetry integration so we get metrics and tracing out of the box

- use jemalloc for linux targets

Good work! Keep it up!

Thank you!

I tried to use standard async traits, but they don't support dynamic dispatch [1] which Rwf uses extensively.

I'll be adding opentelemetry tags to functions (from the `tracing` crate). jemalloc can be added to the binary apps that use Rwf, we don't need to add it as a dep to the lib.

Cheers!

[1] https://blog.rust-lang.org/2023/12/21/async-fn-rpit-in-trait...

> use jemalloc for linux targets

Why is that? Or, why isn't it required for other targets?

Well done! You could try to get mentioned on https://www.arewewebyet.org/

Very surprising this page doesn't mention loco.rs which seems like the most "Rails" Rust framework out there.

Nice got rustpilled myself recently through ditching webpack js loaders and using rust ones which are 50x faster, rust is so preformance enhancing, c++ and rust are my favourite languages atm.

Oooh, mind sharing what you ditched web pack in favour of?

Cool! Since I learned Rust I've wanted a Django replacement that has the functionality of a batteries included Web Framework + the speed/footprint of Rust. I'll check it out!

Thanks for sharing!

As a heads-up, The Pages documentation page is blank.

https://levkk.github.io/rwf/controllers/pages/

I can already hear people asking "Did you aRWF already?" Seriously, the migration option is precisely how I think migration for years. Great job!

Looks great, very interesting! How is the state of to documentation?

I love rust!! This is so cool and I'm a beginner and I'm not sure if I can utilize this framework or not.

You definitely can. I remember learning Django and Rails as a beginner, it wasn't straight forward. New things are hard until they are not new. Good luck!

Does Rust have any DSL for web use (e.g. Rails in someways is a DSL to Ruby)?

I ask because I imagine a simplified (Rust) syntax would be more inviting to newcomers.

Yup, they are called "macros". Rwf uses a few of them, some of which you'll find familiar, e.g. `render!` which returns a rendered template with HTTP 200 [1].

[1] https://levkk.github.io/rwf/views/templates/templates-in-con...

That's good to know.

From the ReadMe example, is there a way to use macros to simplify the following line of code:

  async fn handle(&self, request: &Request) -> Result<Response, Error> {

(Awesome project btw)

Rust can be an intimidating language but the example you’ve provided there really shouldn’t be intimidating to anyone that’s using TypeScript today. There’s a little learning to with &self and & but that’s really basic Rust stuff. I don’t think it’s wise for a framework to attempt to hide core components of the language.

Coming from Typescript that doesn't look very ominous to me, though it would nice if the types could be inferred somehow.

You might be surprised, with Typescript's ubiquity in the web space the type definitions probably won't be too scary. I've never used Rust but I assume `&` is some kind of Rusty pointer.

Thanks!

Yes, I was thinking of adding a shorthand for that. Will add something soon!

```I think Rust makes a great prototyping and deploy straight to production language.```

How?

Love it; this is a big gap in Rust's ecosystem IMO.

Is it? Asking as someone not very tuned into the ecosystem. Based on TechEmpower's Web Framework Benchmarks[0] and AreWeWebYet's resounding "yes!" for years now[1] I always got the impression that there were quite a few options available.

Rocket, Actix, Axum, Salvo, etc just to name a few. Each with different focuses (e.g. performance vs "batteries-included-ness")

[0] https://www.techempower.com/benchmarks/#hw=ph&test=composite...

[1] https://www.arewewebyet.org/

No, it's there but it's not popular and probably won't be for a while. Higher level languages like Java/JS/.Net/Go already do the job well enough for vast majority of use cases. Sure, there are cases like Discord where Go performance was impactful to their operations but those are pretty niche edge cases. Vast majority of people don't have those edge cases so any GC stutter is fine.

Great question!

The frameworks you listed are not a direct comparison to this lib, nor Rails, nor Django. They are Flask analogs. They are ideal for microservices, but are not a substitute for a batteries-included framework of the sort used in websites.

I love rust, but don't use it for web backends because there is nothing on Django's level.

So... rust "on rails" is basically ... https://github.com/loco-rs/loco

less rails is... leptos, and a few others

Rocket comes with support for templating, cookies, websockets, middleware, an orm, testing, etc. I'm not familiar with Python web development (or why anyone would reach for Python for a webapp in 2024 :P), but it seems pretty analogous to Rails

It's also the oldest/most mature tool out there

"The goal is for functionality like templating, sessions, ORMs, and so on to be implemented entirely outside of Rocket"

So definitely a Flask, not a Django. And I want no Flask.

> why anyone would reach for Python for a webapp in 2024

Because it works damn fine, is complete and stable, has a gigantic ecosystem covering virtually every needs in the field and also we know the ins and outs of it.

Of course, less resource consumption is always good, particularly RAM, hence why we're interested in initiatives like RWF or why I keep an eye on the Go ecosystem.

How many people are greenfield new Django style projects? I know Static Server-Side Rendering is becoming new hotness but I still thought pure Server-Side Rendering is frowned upon.

Most of SSR I see is still SPA + Rest API/GraphQL backend with some scraper generating all the HTML.

This is orthogonal; You don't use auth, email, automatic admin, migrations etc from a SPA; those are backend jobs.

I would have argued Rust isn't the right choice for a web framework unless the team is rust-first because the memory guarantees aren't really needed, and you're better off with occasional GC pauses and faster development velocity.

This is perhaps a bit off topic, but I don't think rust is a one-trick-pony IRT memory safety. I hear this a lot, mainly from Rust programmers. [surprisingly]

That’s my take as well. To each their own, but for me there are other, GC-ed, languages that are performant enough and way more productive (and I love Rust!)

Very interesting. I might have to check this out after work!

Impressive launch, good luck and happy coding!

Hopefully it takes off.

Well done!

Lately I've been following https://loco.rs/ as it aims for a rails-like experience, complete with generators for workers, controllers, etc. I've only had time to experiment but it's the closest I've gotten to feeling rails-y in rust.

[dead]

[flagged]

Or any of these XD https://www.arewewebyet.org/topics/frameworks/

[flagged]

[flagged]

These kinds of comments seem to be like a fire starter on this site, but I cannot for the life of me see how they fit in the site guidelines.

(At some point this place has to contend with the issue of “we started as people trying to build cool things and wound up with every thread being nonstop complaints or nitpicking”.)

They don't, just flag them rather than reply them. It's the only way to be sure.

I think there is a valid claim to be made that web frameworks cost more to learn than they pay off in value in using them.

Mind you, I don't assert that claim. I don't know; I'm not in web development. But I could see how having to learn a new framework that wouldn't pay back the effort would give rise to some valid complaints.

haha yeah it was a bit tongue in cheek as I'm learning another framework right now. If we can't have a little levity I'll just delete my comment if it upsets you. :)

chill brother, let an old man yell at clouds

hahah thanks :)

I'm old too, this is how I pretend to stay young.

Understandable. I wasn't criticizing your product -- best of luck and congrats on shipping :)

The youngest old man I know at any rate