Hanami v0.9.0 Released | Hacker News Reader

Hanami v0.9.0 Released

hanamirb.org

78 pointsksec11 comments

I'm glad that there are alternatives to Rails still being developed. I have looked at both projects independently before, and it makes sense for Hanami to adopt ROM as it's ORM.

from the guides:

>Hanami components are decoupled each other. This level of separation allows you to use the ORM (data layer) of your choice. [0]

So indeed, one could use a preferred ORM. Yes the ORM looks a bit verbose and the part with the relations being experimental is a show stopper.

Ignoring all that, Hanami is quite nice architecturally speaking [1] it could evolve into the Phoenix of the Ruby ecosystem.

[0] - http://hanamirb.org/guides/models/use-your-own-orm

[1] - https://github.com/hanami/hanami

Finally gotten on the front page and a few comment.

It seems the Ruby communities aren't interested in anything but Rails. Especially in US and Japan. I have only seen Hanami mentioned in EU conference.

Is it just me, or does this seem like a solution looking for a problem? Especially the verbose way the ORM works... just seems overly complex without actually solving any real problem I had with ActiveRecord.

The ORM isn't he selling point of Hanami. This is just an announcement for an ORM.

IMHO, if popularity was a concern, Luca should have opted for a batteries included nosql ORM/DB with seemless integration. Couchdb and MongoDB would have made excellent candidates.

It's not just you, as I was scrolling the article I was looking for "what's the improvement over other frameworks like ActiveRecord or Sequel?"... I didn't see anything.

Anyone have commentary on why one would use this over another more mature framework?

separation of the entities and repositories is useful in many ways.

For example, you can stub the repository and avoid persisting objects in tests, and only test persistence in the appropriate ones.

Or, you always know that operations you call on an entity won't touch the database, so you avoid a whole class of problems (think: accidental N+1 queries in a loop).

Or, by making the query interface private to the repository, you avoid accidental leakage of storage details (think: `default_scope` impacting associations)

I believe Ecto/Phoenix adopts a similar pattern http://www.phoenixframework.org/docs/models

tldc; an Ruby ORM for PostgreSQL for those who don't want to click.

It's actually an entire web framework. RoR for the "modern web".

right, but the article is specifically about the ORM part.

More interestingly, there's a big crossover with dry-rb, which is some of the stuff that makes me think that Ruby (my preferred glue/new-Perl language by a country mile) can actually sanely scale to large projects with large teams. (My experiences with dynamically-typed languages mostly are a shitshow past a certain point, but dry-types and dry-struct are, at least, the starting point of something that's a little less kooky.)

Right now I've been using hanami-validations, which incorporates a bunch of dry-rb, in completely non-web projects and it's great. Functional, typed conversions are really comfortable and easy with dry-rb; my main beef is a lack of a good way to dump data back out into an interchange format (like, I'd like my types to be able to JSONify themselves), but that's relatively minor.

Reply on news.ycombinator.com