[HN Gopher] Hanami 2.0
___________________________________________________________________
Hanami 2.0
Author : jodosha
Score : 179 points
Date : 2022-11-22 12:57 UTC (10 hours ago)
(HTM) web link (hanamirb.org)
(TXT) w3m dump (hanamirb.org)
| Draiken wrote:
| 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.
| solnic wrote:
| Hanami 2.0 doesn't have any interactors
| Draiken wrote:
| 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.
| solnic wrote:
| 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.
| ryanbigg wrote:
| Which example?
| revskill wrote:
| 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"] ?
| solnic wrote:
| 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
| revskill wrote:
| 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 wrote:
| looks pretty good, congrats to the team.
| entropie wrote:
| 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.
| hanamimastery wrote:
| 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.
| sandstrom wrote:
| 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).
| hanamimastery wrote:
| 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.
| solnic wrote:
| 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.
| specialp wrote:
| 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.
| [deleted]
| solnic wrote:
| 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
| fhars wrote:
| You might enjoy this project:
| https://github.com/garybernhardt/base
|
| :-)
| JohnBooty wrote:
| 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.
| brunno wrote:
| 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.
| hanamimastery wrote:
| I agree! My rails applications became way more maintainable
| since I started being interested in DRY and Hanami:)
| anotherbadlogin wrote:
| dolni wrote:
| 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.
| digitaltrees wrote:
| 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.
| larksimian wrote:
| 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.
| hanamimastery wrote:
| 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.
| solnic wrote:
| 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.
| [deleted]
| automatic6131 wrote:
| Looks really nice. Makes me wish I worked in Ruby, a little.
| faraaz98 wrote:
| Well you can if you want. There's a lot of Ruby projects that
| are looking for contributions.
| pryelluw wrote:
| 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. :)
| hanamimastery wrote:
| 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
| automatic6131 wrote:
| >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.
| Woshiwuja wrote:
| Chad
| foundajob wrote:
| Uh, okay then.
| rco8786 wrote:
| As an aside, working in Ruby is really great. It really
| prioritizes developer ergonomics and makes for a pretty joyful
| code writing experience.
___________________________________________________________________
(page generated 2022-11-22 23:01 UTC)