Hanami 2.0(hanamirb.org)
hanamirb.org
Hanami 2.0
https://hanamirb.org/blog/2022/11/22/announcing-hanami-200/
49 comments
Overall I think the focus with clean syntax/DSLs
in Ruby projects with pervasive metaprogramming
is one of the reasons the code is so hard to maintain.
However, in general, I wholeheartedly agree with your statement. Sometimes Ruby frameworks get way too cute with the metaprogramming.
What you're describing should've been reported as a bug because we do use metaprogramming for DSLs but the "runtime" objects are actually designed to have very minimalistic public API. I can assure you we do not put clean syntax above all else but we do like clean DSLs that reduce boilerplate
You might enjoy this project:
https://github.com/garybernhardt/base
:-)
:-)
[deleted]
I come from ramaze (very old, not maintained, very simple), used rails for work (and was never a big fan) and use hanami for a couple of years now.
I wrote a wrapper that handles/maintains multiple hanami apps and makes plugin usage easy with multiple projects I use them in. Everything gets deployable with capistrano. I run a few sites with more or less complex features and quite happy with it.
Will see how the migration goes...
Grats to 2.0 and kudos to the hanami guys! Great software.
I wrote a wrapper that handles/maintains multiple hanami apps and makes plugin usage easy with multiple projects I use them in. Everything gets deployable with capistrano. I run a few sites with more or less complex features and quite happy with it.
Will see how the migration goes...
Grats to 2.0 and kudos to the hanami guys! Great software.
I am working on upgrading a few big services from Hanami 1.3 -> 2.0 at the moment. feel free to reach out if you will need some help.
I bet some more people are interested in howto and your experience. Maybe a gist or some blog post?
Looks really nice. Makes me wish I worked in Ruby, a little.
As an aside, working in Ruby is really great. It really prioritizes developer ergonomics and makes for a pretty joyful code writing experience.
Well you can if you want. There's a lot of Ruby projects that are looking for contributions.
>Well you can if you want.
Oh, yes, of course. But I am only willing to work for 6-7 hours a day, 5 days a week and my employer pays for them all. Working outside that... nah, no need.
Oh, yes, of course. But I am only willing to work for 6-7 hours a day, 5 days a week and my employer pays for them all. Working outside that... nah, no need.
Id appreciate if you shared some links or project names. I know it’s a web search away but it sounds like you have some projects in mind. :)
Contributions to Hanami components would be appreciated for sure! There is a whole persistence and views integration to be done fir 2.1 release! The core team will not rest for too long after 2.0 being out :D
Nice thank you. Will follow up.
Framework-style libraries (i.e. Hanami) pulling in other framework-style libraries (i.e. dry-rb) which themselves pull in other framework-style libraries (i.e. Zeitwerk) is asking for a whole lot of trouble.
If your app uses Hanami and Zeitwerk, for example, breaking changes in Zeitwerk may REQUIRE you to update Zeitwerk before you can upgrade Hanami. Or, if dry-rb hasn't adopted the new version of Zeitwerk, you may be stuck on an old version of Zeitwerk, unable to update it. Depending on the nature of the breaking changes, working through this stuff could be a lot of work for a mature app.
Maybe the maintainers are nice and release patch versions for older major releases. I don't know. What I do know is that either way, there is likely to be a lot of maintenance burden somewhere unless these libraries have high stability guarantees.
I don't understand the Rubyist obsession with having a whole bunch of magic stuff just "happen" in your code. Magic is fine if the scope is narrow and well-defined. Ruby magic is often _entire app magic_, which means that it is hard to approach (because you need to understand how it works in many contexts). If that magic ever changes, there are a lot more places where it can break stuff.
If your app uses Hanami and Zeitwerk, for example, breaking changes in Zeitwerk may REQUIRE you to update Zeitwerk before you can upgrade Hanami. Or, if dry-rb hasn't adopted the new version of Zeitwerk, you may be stuck on an old version of Zeitwerk, unable to update it. Depending on the nature of the breaking changes, working through this stuff could be a lot of work for a mature app.
Maybe the maintainers are nice and release patch versions for older major releases. I don't know. What I do know is that either way, there is likely to be a lot of maintenance burden somewhere unless these libraries have high stability guarantees.
I don't understand the Rubyist obsession with having a whole bunch of magic stuff just "happen" in your code. Magic is fine if the scope is narrow and well-defined. Ruby magic is often _entire app magic_, which means that it is hard to approach (because you need to understand how it works in many contexts). If that magic ever changes, there are a lot more places where it can break stuff.
You're right in principle but not in this case. Zeitwerk is not a regular dependency, it's stable and the risk it will change in an incompatible way is very minimal (reminder - it's used by Rails too). When it comes to dry-rb as deps - dry-rb core team == hanami core team. This means we are on top of the things and we'll ensure that things are evolving together w/o breaking anything.
This is the sort of cargo-culty FUD criticism people often bring up about Rails. So many programmers would rather reinvent the wheel, badly, than learn how to use existing products and focusing on their USPs.
What would your successor prefer when they take over: Bob's ad-hoc framework built from the ground up where they don't know how anything works, or some app implemented on top of a framework they've used in 10 other jobs?
While I agree that using frameworks like rails/django/hanami/react has an upfront cost, it's so hard to justify doing your own thing if your usecase is fits within what they offer.
What would your successor prefer when they take over: Bob's ad-hoc framework built from the ground up where they don't know how anything works, or some app implemented on top of a framework they've used in 10 other jobs?
While I agree that using frameworks like rails/django/hanami/react has an upfront cost, it's so hard to justify doing your own thing if your usecase is fits within what they offer.
Hanami 2.0 is almost completely rewrite in it's core from 1.3, and it took over 3 years. I could not imagine companies relying on owned frameworks - maintaining it, documenting it, educating people to work with them - it's just too expensive.
The ruby community is able to do it by having a rigorous set of defaults. When you look at the ecosystem there is far more inter compatibility than say JavaScript/ npm because there are robust norms.
The obsession with magic is actually more an obsession on developer speed and ease because that is the biggest cost and driver of software. The magic also promotes following well tested patterns.
You seem to be advocating a dependency free path where the developer builds everything from scratch. Totally a valid approach but at the cost of development speed and ease. It also results loss of the collective knowledge of a community.
The obsession with magic is actually more an obsession on developer speed and ease because that is the biggest cost and driver of software. The magic also promotes following well tested patterns.
You seem to be advocating a dependency free path where the developer builds everything from scratch. Totally a valid approach but at the cost of development speed and ease. It also results loss of the collective knowledge of a community.
This is great!
I love Rails but have used Sinatra and Padrino in the past. The knowledge you get using these frameworks can sometimes be brought back to your Rails apps to improve some things.
I hope I can have some time in the near future to use Hanami in a real world project.
Congratulations to the team.
I love Rails but have used Sinatra and Padrino in the past. The knowledge you get using these frameworks can sometimes be brought back to your Rails apps to improve some things.
I hope I can have some time in the near future to use Hanami in a real world project.
Congratulations to the team.
I agree! My rails applications became way more maintainable since I started being interested in DRY and Hanami:)
dry is a neat framework. It also works with rails. [0]
0. https://dry-rb.org/gems/dry-rails
I'm sad that the trailblazer stack went so commercial as to be FOSS-hostile and unusable.
0. https://dry-rb.org/gems/dry-rails
I'm sad that the trailblazer stack went so commercial as to be FOSS-hostile and unusable.
trailblazer - Besides the cells gems I used soon since it's created (before trailblazer became a thing) I have never used others
I found that some doc are removed from README to a 3rd party website which seems odd to me
I found that some doc are removed from README to a 3rd party website which seems odd to me
Looks like the new 2.0 guides doesn't have anything regarding views and templates yet. Is that a documentation gap or is it like some of the closer ROM integration, where it will be 2.1 where that is functionally fleshed out?
Yes the view layer will be introduced in 2.1. We have hanami-view ready but we need to build hanami-assets and hanami-helpers + add integration code to the main hanami gem.
For me it's a shame that they doubled down on the "interactors" (which are now called operations?) pattern. I really like the containers system from `dry-rb` and overall how the routing/controller system works. I like the concept of multiple apps and slices as first class citizens.
But interactions are a plague. People start chaining interactions and very soon you have a maze of these things, with all the domain logic lost inside of these procedures and almost no POROs in sight.
Most of these complaints are, of course, not inherently the fault of these commands/operations/interactions, but they make it so easy to create these monstrosities that I have to put some of the blame on them.
But interactions are a plague. People start chaining interactions and very soon you have a maze of these things, with all the domain logic lost inside of these procedures and almost no POROs in sight.
Most of these complaints are, of course, not inherently the fault of these commands/operations/interactions, but they make it so easy to create these monstrosities that I have to put some of the blame on them.
Hanami 2.0 doesn’t have any interactors
Oh, I saw an example with `app/operations` and assumed they were just renamed.
Guess that changes everything for me. Will definitely give it a try.
Guess that changes everything for me. Will definitely give it a try.
Haha no it's just an example of a custom directory that you can place under app dir We're still thinking about an abstraction for operation-like objects (I actually started experimenting with this a couple of months ago) but I don't think it will become part of the main Hanami stack.
Which example?
def call(name:, email_address:)
email_client.deliver(
to: email_address,
subject: "Welcome!",
text_body: welcome_email.render_text(name: name),
html_body: welcome_email.render_html(name: name)
)
If you want Hanami to be an IoC framework, why still allow direct SlackNotifier to be injected to the action layer here ? I guess, lib/ folder should be loaded into Deps instead (Deps["slack_notifier"] ?
SlackNotifier.notify("Welcome email sent to #{email_address}")
end
If you want Hanami to be an IoC framework, why still allow direct SlackNotifier to be injected to the action layer here ? I guess, lib/ folder should be loaded into Deps instead (Deps["slack_notifier"] ?
You missed the context of this example - it's just there to show that IF you don't want to use constructor DI, you can put things in lib and they won't become part of the automatic DI system
The point here, is, let's code in production.
No good production code allows such things to accidentially happen, so to me, it's the error from framework. What's the point of using a framework if it couldn't help me do silly things then ?
No good production code allows such things to accidentially happen, so to me, it's the error from framework. What's the point of using a framework if it couldn't help me do silly things then ?
How would Hanami prevent this without messing with ruby constant lookup? Probably monkey patches to Kernel would be required.
[deleted]
Anyone who knows how this is different from Sinatra and Roda?
They seem to be the other two "micro frameworks" (with Rails obviously being the primary Ruby framework).
They seem to be the other two "micro frameworks" (with Rails obviously being the primary Ruby framework).
Hanami is not a micro-framework, it is composed of multiple gems though, so if you remove them all you're left with a core of the framework that doesn't do anything except providing an API for plugging in components, configuring them and managing their state.
When it comes to differences - Sinatra is not as feature rich and it's got a less powerful plugin system. Roda has a completely different router using so called Routing Tree, which Hanami doesn't have (it's got something more akin to what Rails has) but it's also highly extendible through plugins, so there is similarity there. A huge difference is that Hanami ships with a very powerful code loading system that supports automatic dependency injection mechanism.
When it comes to differences - Sinatra is not as feature rich and it's got a less powerful plugin system. Roda has a completely different router using so called Routing Tree, which Hanami doesn't have (it's got something more akin to what Rails has) but it's also highly extendible through plugins, so there is similarity there. A huge difference is that Hanami ships with a very powerful code loading system that supports automatic dependency injection mechanism.
Hanami aims to be a complete Ruby framework, allowing you to write web apps, but also gems, and non-web ruby applications. Hanami 2.0 only ships for API focus, but in next minor versions this is going to be extended. I see it as a direct alrernative to Rails for anyone who would like to try different style of programming while still using Ruby.
What benefits does it bring to writing gems?
Similar to what rodauth did, or active-admin - extracting mountable, shareable and reusable parts of your app to a separate thing.
Is this documented somewhere? Sounds interesting.
looks pretty good, congrats to the team.
Is...?
(scnr) i did the needful, and clicked the link, then clicked the homepage link:
"Hanami is a modern web framework for Ruby."
"Hanami is a modern web framework for Ruby."
(lskdfj) Congrats for abetting laziness.
Overall I think the focus with clean syntax/DSLs in Ruby projects with pervasive metaprogramming is one of the reasons the code is so hard to maintain.