I’m always very curious to know how people discover the project and what is their motivation to learn it and try it out. Please tell me your story, even when it wasn’t successful. If ROM didn’t meet your requirements please tell what it was.
I can briefly tell you my story for a good start
I started working as a rails developer in 2007 and got interested in the DataMapper project around 2008 after seeing AR not working very well in bigger projects. I’ve been exploring alternative ways of designing apps since then. I spent quite a while working on the DataMapper project itself, roughly 2 years of being a core team member. Initially I wanted to have an ORM that implements the DM pattern but eventually I realized I don’t like ORMs in general. That’s why ROM changed its direction last year. FWIW I never looked back.
I moved away from ActiveRecord, so now I need good libraries to support my design. For my needs it’s very close to be completed, but for the general audience there’s still a lot to be done
Apart from persistence concerns I am also deeply interested in having a better validation library and a view layer that doesn’t turn into complete mess too quickly.
I’ve been using Rails since mid 2006 – sometime before 1.2 came out, certainly. Most of the early days were spent wrangling a large codebase; I made every version jump from 1.1 all the way up to 3.0 before I left that project. From there, I bounced around projects for a little bit before landing at LivingSocial, where we also had a really large codebase.
Which is a long way of saying that I’ve seen how Rails can solidify into an intractable mess, if you let it. I lay the blame at the feet of ActiveRecord, and the way in which Rails has tended to expect everything else to be built on top of it. A few years back, I started playing with ways to work around that. One of the approaches I’ve been happy with is pulling out and identifying specific Repository objects, as described in the DDD book. These let me trade off where data comes from within the application, without having to make deep structural changes to the business logic, and they let me start pulling in data from web services and other non-dbms sources, with minimal fuss.
ROM first attracted me because it was looking at ways to address mixing data from these various sources; My repositories were still doing a lot of data reconstruction and manual joins. The promise of being able to write a simple adapter for your internal data source, and trivially mix data from multiple backends is one of the things I find most compelling.
I’d heard about ROM when I learned that the next version of DataMapper was going to take a different approach. (I was probably surfing to DataMapper on some day when my frustration with AR was peaking.)
I have been working with Ruby since 2002. Interestingly, one of my first Rails experiences was adapting an existing Ruby codebase that talked to a database to use Rails 0.8, mixing AR validations in.
I have decided I’m done putting up with the AR nonsense. We’re in Ruby—it’s not too hard to write good code. We can apply good DDD. I think ROM is a great tool.
I’m still getting up to speed. As my current project ramps up using ROM “in anger” I hope to share insights and perhaps write-ups of usage patterns, questions, etc.
I’ve been using Ruby since we decided to build our first product using Rails back in 2004.
I’ve heard about the ROM-RB 0.6.0 launch in the Ruby5 podcast back on March, and i remember i liked much what i read about the motivations behind the project. I didn’t start using it, but last week @solnic gave us one of the best talks at the Baruco in the Full Stack Fest in Barcelona.
I’ve been playing with Neo4j lately and these days was thinking about the best API for the persistence layer of a personal project. After seeing the good ROM’s health i decided give a try to rom-neo4j adapter.
The rom-neo4j’s README asks to run its specs, but they do not passed because the adapter was using an obsolete ROM’s API. Not knowing much about ROM, i decided to see what had changed in other adapters’ code to run with the current API.
I’d like to keep helping @maetl with the neo4j’s adapter, but the thing is that i still don’t know enough about ROM to do it.
I’ve tried to complete the Rails tutorial, but with no luck since at this moment it needs to be updated too.
I want to study the guides better and help with updating the tutorial since i think is important to have a pleasant “getting started moment” in order to catch developers’ hearts
Thanks for the kind words Fernando I’m sorry you had trouble with the tutorial, as you know it’s quite out-of-date and we’re looking for help with updating it. Personally I decided to move away from rails, this also means that effectively I won’t be maintaining rom-rails with the exception of patches that are needed for my client work.
It’s been fantastic to see that you managed to update neo4j adapter to latest rom w/o asking any questions. This is a good sign for me
As far as docs go we are discussing how to rewrite them and what to do in general to make “on-boarding” a nicer experience. Until recently people who started using ROM were almost exclusively early-adopters and contributors, which means it was easier for them to start using ROM even though only lower-level interfaces were available. Now I see the need to focus more on convenient usage for all the common use-cases (the “blog in 15 minutes” type of usecases) and this includes improving rom-repository mostly and polishing internals so that repository can be as simple as possible in terms of both its internal implementation and the public interfaces it exposes.
Having said that, using ROM will be a mind-shift for most people as the first step is to understand it’s not an object-relational-mapper. And just that takes time. Personally I believe it’s worth the effort though I will work hard on various resources to make that process as pleasant as possible.
It would be great to collect as much usage patterns as possible. My plan is to write a whole ebook about my usage patterns but I do not want to say “here’s THE way” and instead show “here’s MY way, it’s A way, tell me what you think”. Toolkit nature of ROM should enable all kinds of approaches. It should be interesting to see how people will use ROM.
I would love to learn more about DDD + ROM. Personally I’ve been leaning towards more FP approach for quite a while and honestly it starts to feel really good.
I came to ruby because of rails when rails 3 was new and shiny… my plan was to rewrite a legacy PHP application in RoR but quickly discovered that ActiveRecord was too magic and a PITA to use with the legacy database schema… so I reached out for datamapper which worked well back then.
I have followed DM2/ROM development, with its ups and downs, since then. I was delighted when @solnic announced the revamp of ROM and I’m grateful for all the hard work he put into this project.
I got into ruby/rails from PHP to create a corporate application (automates supply chain for construction materials).
At first all were ok. I loved that 3.weeks.ago helpers, ‘convention over configuration’… until the app has grown to ~50 models. Then, well, it becomes unmaintainable. I made 2 trials to revive it, but without much success. Even after implementing “7 Patterns to Refactor Fat ActiveRecord Models”, listening to “Architecture the Lost Years” and other great talks by Matt Wynne, Jim Weirich, reading Evans’ and Fowler’s books/articles about DDD. This was wonderful experience, but with a small effect due to stuck to AR/AM/AS.
I tried DataMapper in 2013/2014, but it seemed not to be ready for production. Then I listened about re-launching ROM in november 2014. I’ve read it sources this spring, then I’ve read sources of transproc and become much happier. Not only because ROM allows to decouple persistence from domain, and switch between various data sources (like sql, cassandra, kafka (announced) etc.), but because I borrowed this FP-ish style of coding.
The dark side is after all of this, dealing with Rails makes me sad.
In fact the right thing would be to have a “stand alone” tutorial not related with any particular framework, or to have one related to a very simple one (e.g. Sinatra).
A Rails tutorial is for sure very helpful to let many people get on-board. But also may also make more difficult to show some ROM-RB aspects, though they could always be learnt later.
Thanks man, it’s been a crazy journey for me indeed. FWIW I’m very happy with how ROM’s been evolving since I rewrote it last year. Optimistically looking forward to the future now.
@solnic, I appreciate all the work you’ve contributed into ROM. I like especially the default patterns it enforces on app design. SRP serves isolation, which is so testable. I’ve landed here from (PORO presenters + Interactor gem) stack and let’s see how it’ll whirl.
As there’re thousands of still maintained apps with AR skeleton on board, I ponder about the idea of introducing ROM into AR–based Rails app and make a hybrid at first. I believe, depending on the use case, it may gain profits in the longer term.
As far as AR goes - it should be possible to hide AR behind ROM-based infrastructure and treat it as a data-source. I already wrote an adapter spike for DataMapper, I’d imagine something similar could be done for AR.
Tenjin started working in Rails 3 on our early projects. similar to nepalez, it went okay until things needed to work for people, not the database. The layers of ‘convention’ magic simply became more work than it was worth. Testing was cumbersome due to Rails’ monolithic structure.
We discovered Architecture: The Lost Years, and fell in love with the hex arch style. Rails at this point was causing more work than it reduced, so it was out. We took a first run at trying to hide an ORM behind a general persistence layer, which did not go well (for obvious reasons). We settled for the slightly more flexible DataMapper for the time being.
Our focus turned to simplifying the rest of the architecture, switching to the lightweight Sinatra, which made our views dumb data-displayers. Shearing off the the core application logic into user story orientated functions (rather than CRUD/REST), meant that we have meaningful first-class core behaviour defined. Only the persistence layer remains to be de-dunked and re-worked.
Learned about ROM from a former colleague, though I don’t know how he knew about it. The philosophy and implementation direction matched what we need. At the time, it was just a little too green to use in production, but that was before the advent of Repository. Excited for the next project that I can test drive it on. If it goes well, we may make a big push to standardize all of our existing code bases to our new Dirt style, including ROM.
Cheers to solnic and others for the research, work, and even moreso the open mindset. That interactivity and willingness to hear others out creates an infectious energy, and that’s what got me boosted from interested to helping (in as much as I can, anyway).
We RingTwice, are belgian startup using a Rails SSR monolith deployed to heroku servers. We learned about ROM about 3 months ago (Jul’ 21) via a contractor with 15+ years experience, working a really well rep rails-focused webdev agency in the country.
For context, we’re working with an 8 year old legacy application that was managed by 1 or 2 people its first 5 to 6 years, with very little test coverage, and 1+ year tech debt score.
Now we’re scaling, so we hired this contractor to help us find a refactoring strat to make the app workable for new hires. Using the DRY ecosystem + ROM made the ideal scenario possible. We can incrementally rewrite the legacy BE without having to hire a devops team to transition.
Anyways, we’re still testing out a few things, but this is what we’re thinking of using:
Rom
Rom-sql
Rom-factory
and 80% of the dry ecosystem libraries
We didn’t use any of the rails integration libraries in favour of creating our own gem encapsulating the new domain logic, since we found those to defy the our purpose of stripping down our rails and legacy code dependencies.
Coming from a community as large as rails, it hasn’t been always simple or straight-forward to navigate and find the solutions to issues, but it’s been fun and fulfilling to feel like we’re writing code that follows better patterns!
I’ve been on Rails since 2005, version 0.10, and have followed best practice development as much as I was able since. Eventually I found DDD, and ROM, but didn’t have the bandwidth to pursue it. Now I have a new project, and I am attempting to build it with ROM, but so far that has been very difficult. I’m not even sure what I’m doing wrong, but a number of things are confusing. I am using Dry::Types to define my schemas because ROM::Types doesn’t work the same way, and I am not sure how to use it, and the documentation hasn’t helped. My entities and their schemas work well as objects in unit tests, but I am unable to integrate them with any of the relations or repositories I am working on. use_namespace just doesn’t work as I expect it to. I’m not sure what I’m doing wrong.
