Hanami 2.0

https://hanamirb.org/blog/2022/11/22/announcing-hanami-200/

by jodosha • 4 years ago

219 46 4 years ago

hanamirb.org

automatic61312• 4 years ago

Looks really nice. Makes me wish I worked in Ruby, a little.

faraaz98• 4 years ago

Well you can if you want. There's a lot of Ruby projects that are looking for contributions.

pryelluw2• 4 years ago

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

automatic61312• 4 years ago

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.

rco8786• 4 years ago

As an aside, working in Ruby is really great. It really prioritizes developer ergonomics and makes for a pretty joyful code writing experience.

brunno• 4 years ago

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.

hanamimastery6• 4 years ago

I agree! My rails applications became way more maintainable since I started being interested in DRY and Hanami:)

specialp• 4 years ago

It looks clean because the developers are also the people behind dry-rb. However, I made one production service in Hanami and never again. They put clean syntax above all else. This results in a TON of metaprogramming with very weird results. There were times when a variable name I was using in my code was conflicting with a method called in one of the many `instance_evals` to achieve such "dryness" I really do like the structure though with repositories for data.

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.

JohnBooty• 4 years ago

    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.

I don't have any opinion on Hanami and don't want to bring any negativity to the Hanami 2.0 party. Congrats to the team on this release!

However, in general, I wholeheartedly agree with your statement. Sometimes Ruby frameworks get way too cute with the metaprogramming.

fhars• 4 years ago

You might enjoy this project: https://github.com/garybernhardt/base

:-)

solnic7• 4 years ago

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

Draiken2• 4 years ago

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.

solnic7• 4 years ago

Hanami 2.0 doesn’t have any interactors

Draiken2• 4 years ago

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.

revskill2• 4 years ago

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

        SlackNotifier.notify("Welcome email sent to #{email_address}")
      end

This code is bad.

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"] ?

solnic7• 4 years ago

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

revskill2• 4 years ago

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 ?

drish• 4 years ago

looks pretty good, congrats to the team.

dolni• 4 years ago

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.

solnic7• 4 years ago

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.

larksimian• 4 years ago

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.

hanamimastery6• 4 years ago

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.

digitaltrees• 4 years ago

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.

sandstrom• 4 years ago

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

solnic7• 4 years ago

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.

hanamimastery6• 4 years ago

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.

revscat2• 4 years ago

What benefits does it bring to writing gems?

entropie2• 4 years ago

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.

hanamimastery6• 4 years ago

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.

entropie2• 4 years ago

I bet some more people are interested in howto and your experience. Maybe a gist or some blog post?

BuckyBeaver2• 4 years ago

Is...?

slater• 4 years ago

(scnr) i did the needful, and clicked the link, then clicked the homepage link:

"Hanami is a modern web framework for Ruby."

BuckyBeaver2• 4 years ago

(lskdfj) Congrats for abetting laziness.

1letterunixname• 4 years ago

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.

PikachuEXE• 4 years ago

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

bjeanes• 4 years ago

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?

solnic7• 4 years ago

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.

Hanami 2.0

Related Stories