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!
qudat 8 minutes ago [-]
Agreed on all fronts. Go has nailed the stdlib and every other language is in its shadow
kvirani 7 hours ago [-]
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!
ecshafer 6 hours ago [-]
> 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.
CharlieDigital 3 hours ago [-]
> 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.
The opposite of this is what Fowler has called an "Anemic Domain Model"[0] which is ostensibly an anti-pattern. What I've learned from my own experience is that with an anemic domain model, the biggest challenge is that the logic for mutating that object is all over the codebase. So instead of `thing.DoDiscreteThang()`, there could be one or more `service1.DoDiscreteThang(thing)` and `serviceN.DoDiscreteThang(thing)` because the author of `service1` didn't know that `service2` also did the mutation.
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.
I tend to draw the line at intrinsic vs extrinsic behavior. The model layer must be able to maintain all intrinsic properties. Whenever it would talk outside the application, it's beyond the domain of the model.
Taken to the extreme, you could model all intrinsic constraints and triggers at the relational database level, and have a perfectly functional anemic domain model.
idle_zealot 5 hours ago [-]
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.
appguy 1 hours ago [-]
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.
DanHulton 55 minutes ago [-]
This is the critical difference.
One of the simplest examples is that you could have a Login domain model that handles login-related business logic, that mutates properties in the User ORM model.
All your login-related business logic code goes in the Login model, and any "the data _must_ look like this or be transformed like that" logic can go in the ORM model. If some other service wants to do anything related to the login process, it should be calling into the Login domain model, not accessing the User ORM model directly.
JamesSwift 4 hours ago [-]
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.
JodieBenitez 3 hours ago [-]
> 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.
fragmede 3 hours ago [-]
attach a debugger to the running process
yoyonamite 4 hours ago [-]
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?
ecshafer 3 hours ago [-]
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.
throwaway313373 3 hours ago [-]
If I had to choose between thousands lines in models and thousands lines in controllers I'd definitely take "fat" models over "fat" controllers.
LeftHandPath 2 hours ago [-]
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.
freedomben 2 hours ago [-]
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?
LeftHandPath 2 hours ago [-]
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.
freedomben 1 hours ago [-]
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.
ensignavenger 1 hours ago [-]
Are there not any Laravel shops that would take your money so you can "pay" for it?
LeftHandPath 25 minutes ago [-]
Hah, I’m currently trying that tactic to get us on Bookstack for our SOPs. Never thought about doing it with Laravel. Could work!
snowAbstraction 1 hours ago [-]
Thanks for sharing that. AS400 always catches my eye after doing in internship at IBM, working with AS400 back in 2000.
sodapopcan 6 hours ago [-]
> * 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.
jt2190 6 hours ago [-]
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”?
sodapopcan 5 hours ago [-]
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.
CSSer 4 hours ago [-]
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.
sodapopcan 3 hours ago [-]
I don’t really follow. My focus wasn’t on the naming but the location of responsibilities.
globular-toast 2 hours ago [-]
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".
pdhborges 1 hours ago [-]
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.
throwaway313373 7 hours ago [-]
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.
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.
the__alchemist 6 hours ago [-]
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.
phibz 4 hours ago [-]
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.
xyst 4 hours ago [-]
Never been a fan of ORMs in general. Working with the extra abstraction layer on top of SQL can be painful.
throwaway313373 3 hours ago [-]
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].
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.
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.
florianmartens 4 hours ago [-]
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.
JamesSwift 3 hours ago [-]
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.
giancarlostoro 5 hours ago [-]
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.
internetter 5 hours ago [-]
You can simply diff it. Define the OpenAPI spec, have the framework generate a spec, compare.
jjnoakes 5 hours ago [-]
You could generate a spec for the service and then diff to the expected perhaps.
steveklabnik 4 hours ago [-]
100% agree that generating OpenAI from your server is a killer feature, it works well for us with Dropshot.
outside1234 5 hours ago [-]
Just FYI - since this is an asynchronous framework you probably would want something like sqlx versus Diesel (which is sync if I recall correctly)
4 hours ago [-]
notamy 7 hours ago [-]
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.
alberth 5 hours ago [-]
> 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
Arch-TK 26 minutes ago [-]
Surely it has a WSGI client not a server.
stackskipton 6 hours ago [-]
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)
levkk 6 hours ago [-]
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.
stackskipton 5 hours ago [-]
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.
biorach 6 hours ago [-]
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
stackskipton 5 hours ago [-]
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.
drcongo 6 hours ago [-]
As a Python dev, I imagined the same.
JodieBenitez 7 hours ago [-]
> (think Rails, not Flask)
I like that... we need more (or better) opiniated frameworks a la rails/django in static languages.
stuaxo 2 hours ago [-]
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.
jamiedumont 3 hours ago [-]
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!
factormeta 1 hours ago [-]
What about Actix? There were some discussion on HN a while back related to Actix vs Axum if I recall that.
apbytes 6 hours ago [-]
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!
xyst 4 hours ago [-]
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
lopatin 1 hours ago [-]
> 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?
robert_foss 3 hours ago [-]
@levkk How do you thing it compares to loco.rs, I'd like to understand the differences.
jpopesculian 6 hours ago [-]
Looks cool! How does it compare to loco.rs?
jcmontx 3 hours ago [-]
Do you plan on adding CRUD generators? That was the killer feature of MVC frameworks
levkk 3 hours ago [-]
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.
dethos 2 hours ago [-]
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.
Very surprising this page doesn't mention loco.rs which seems like the most "Rails" Rust framework out there.
unjkyivbnp 6 hours ago [-]
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!
levkk 5 hours ago [-]
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.
Why is that? Or, why isn't it required for other targets?
fHr 6 hours ago [-]
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.
drcongo 4 hours ago [-]
Oooh, mind sharing what you ditched web pack in favour of?
wormlord 6 hours ago [-]
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!
tommaho 7 hours ago [-]
Thanks for sharing!
As a heads-up, The Pages documentation page is blank.
```I think Rust makes a great prototyping and deploy straight to production language.```
How?
sureglymop 7 hours ago [-]
Looks great, very interesting! How is the state of to documentation?
MASNeo 6 hours ago [-]
I can already hear people asking "Did you aRWF already?" Seriously, the migration option is precisely how I think migration for years. Great job!
donq1xote1 6 hours ago [-]
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.
levkk 5 hours ago [-]
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!
alberth 7 hours ago [-]
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.
levkk 7 hours ago [-]
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].
I ask because many web developers don't come from a C/C++/Rust background - so the line above will be jarring/off-putting to many.
(Awesome project btw)
afavour 6 hours ago [-]
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.
Scarblac 6 hours ago [-]
Coming from Typescript that doesn't look very ominous to me, though it would nice if the types could be inferred somehow.
fkyoureadthedoc 7 hours ago [-]
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.
levkk 7 hours ago [-]
Thanks!
Yes, I was thinking of adding a shorthand for that. Will add something soon!
the__alchemist 7 hours ago [-]
Love it; this is a big gap in Rust's ecosystem IMO.
culi 6 hours ago [-]
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")
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.
the__alchemist 6 hours ago [-]
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.
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
JodieBenitez 2 hours ago [-]
"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.
stackskipton 6 hours ago [-]
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.
the__alchemist 6 hours ago [-]
This is orthogonal; You don't use auth, email, automatic admin, migrations etc from a SPA; those are backend jobs.
dehrmann 5 hours ago [-]
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.
the__alchemist 2 hours ago [-]
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]
ku1ik 2 hours ago [-]
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!)
giancarlostoro 7 hours ago [-]
Very interesting. I might have to check this out after work!
taikahessu 7 hours ago [-]
Impressive launch, good luck and happy coding!
Havoc 7 hours ago [-]
Hopefully it takes off.
hkc88hkc 6 hours ago [-]
Well done!
jakswa 4 hours ago [-]
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.
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”.)
pvg 7 hours ago [-]
They don't, just flag them rather than reply them. It's the only way to be sure.
AnimalMuppet 7 hours ago [-]
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.
ratedgene 7 hours ago [-]
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. :)
TZubiri 7 hours ago [-]
chill brother, let an old man yell at clouds
ratedgene 7 hours ago [-]
hahah thanks :)
7 hours ago [-]
levkk 7 hours ago [-]
I'm old too, this is how I pretend to stay young.
ratedgene 2 hours ago [-]
Understandable. I wasn't criticizing your product -- best of luck and congrats on shipping :)
mmontagna9 7 hours ago [-]
The youngest old man I know at any rate
Rendered at 21:42:19 GMT+0000 (Coordinated Universal Time) with Vercel.
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!
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 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.
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
Taken to the extreme, you could model all intrinsic constraints and triggers at the relational database level, and have a perfectly functional anemic domain model.
One of the simplest examples is that you could have a Login domain model that handles login-related business logic, that mutates properties in the User ORM model.
All your login-related business logic code goes in the Login model, and any "the data _must_ look like this or be transformed like that" logic can go in the ORM model. If some other service wants to do anything related to the login process, it should be calling into the Login domain model, not accessing the User ORM model directly.
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.
Also Django signals, Symfony events... makes things extensible but also hard to debug indeed.
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.
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.
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.
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 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.
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
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.
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-...
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
In a fully typesafe world, it should be pretty hard to derive from the shema this way.
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.
"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
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.
I like that... we need more (or better) opiniated frameworks a la rails/django in static languages.
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!
rocket.rs, actix, axum, warp, gotham, ruille
Sorry what? Isn't Rusts whole thing is that it prevents you from prototyping wild ideas, in the name of memory safety?
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!
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...
Why is that? Or, why isn't it required for other targets?
As a heads-up, The Pages documentation page is blank.
https://levkk.github.io/rwf/controllers/pages/
How?
I ask because I imagine a simplified (Rust) syntax would be more inviting to newcomers.
[1] https://levkk.github.io/rwf/views/templates/templates-in-con...
From the ReadMe example, is there a way to use macros to simplify the following line of code:
I ask because many web developers don't come from a C/C++/Rust background - so the line above will be jarring/off-putting to many.(Awesome project btw)
Yes, I was thinking of adding a shorthand for that. Will add something soon!
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/
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.
less rails is... leptos, and a few others
It's also the oldest/most mature tool out there
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.
Most of SSR I see is still SPA + Rest API/GraphQL backend with some scraper generating all the HTML.
(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”.)
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.