A good litmus test of an experienced Rails developer is how large their /lib directories are in relation to project sizes.
Rails – The Missing Parts
21–30 of 173 posts
Re: Rails – The Missing Parts
#22I've been looking into incorporating this pattern into my larger Rails apps as well. Another benefits of interactions is DRYing up your code for use in APIs. Some of the more popular interactor gems: https://github.com/orgsync/active_interaction https://github.com/cypriss/mutations
Thanks for the shout out! I'm one of the developers of ActiveInteraction. Since most of the interactor gems are pretty similar, here's why you might prefer ActiveInteraction over Mutations, Interactor, et al.:
- Built-in ActiveModel validations. - Designed to be used with form objects. - Easier and more flexible composition. - Translatable with I18n. - Quacks like an ActiveModel.
That being said, Mutations is a great library for PORO interactors and ActiveInteraction wouldn't exist without it.
Re: Rails – The Missing Parts
#23One thing I can't figure out is whether to place my service objects under `/app/models` or under `/lib`. There doesn't seem to be a clear consensus on this? I tend more towards the former, because autoload works better during development. Also, I consider them part of my domain model. What do you do?
I have app/services and just add that in application.rb to the load path.
You don't even need to add that to the load path as of rails 4 - we have app/validators, app/services, app/forms, app/inputs etc etc, all autoloaded with no config.
Re: Rails – The Missing Parts
#24I've been looking into incorporating this pattern into my larger Rails apps as well. Another benefits of interactions is DRYing up your code for use in APIs. Some of the more popular interactor gems: https://github.com/orgsync/active_interaction https://github.com/cypriss/mutations
If you need a gem to implement some of these complementary patterns, you're doing it wrong. Draper, Naught, DisplayCase and all of the other gems of patterns are over abstraction 99% of the time. Implement the pattern yourself. Most of these Presenter and Service object patterns are different variations of the Decorator pattern. Ruby happens to ship with 3 great ways to implement decorators: SimpleDelegator (my personal favorite)[0], Delegator[1] and Forwardable[2].
0 - http://www.ruby-doc.org/stdlib-1.9.3/libdoc/delegate/rdoc/Si...
1 - http://www.ruby-doc.org/stdlib-1.9.3/libdoc/delegate/rdoc/De...
2 - http://www.ruby-doc.org/stdlib-2.0/libdoc/forwardable/rdoc/F...
Re: Rails – The Missing Parts
#25I thought Etsy uses PHP. Could be wrong.
I can confirm that Etsy.com is primarily PHP. We have no externally facing Rails projects. We have some internal tools on Rails.
-- spike@etsy.com
Re: Rails – The Missing Parts
#26One thing I can't figure out is whether to place my service objects under `/app/models` or under `/lib`. There doesn't seem to be a clear consensus on this? I tend more towards the former, because autoload works better during development. Also, I consider them part of my domain model. What do you do?
/app/interactors
# add to application.rb
config.autoload_paths += %W(#{config.root}/app/interactors)Re: Rails – The Missing Parts
#27As always, the question is should be in Rails or not.
I think that the answer is clear, this should not be a part of rails since it's not true to all apps.
I think that if you want to have something real quick, you don't need an interactor/service class.
When you have a bigger app, you definitely need that, or you will get to a point where you code is split into models/observers/callbacks/lib/app/concerns and you can't find anything.
Rails generators are pretty easy to extend, this way, when you generate a new model, you can easily create the service class for it.
You can also EASILY create new generators that will generate the service classes for you with your defaults and templates and what not.
Not sure Rails is missing that, however, it is definitely a best practice that people with bigger apps should use TODAY.
Re: Rails – The Missing Parts
#28One thing I can't figure out is whether to place my service objects under `/app/models` or under `/lib`. There doesn't seem to be a clear consensus on this? I tend more towards the former, because autoload works better during development. Also, I consider them part of my domain model. What do you do?
Anything that is application-specific, we put in /app
Anything that's generic and re-usable, we put in /lib. This code is normally a prime candidate for gems - only very simple code stays in /lib for very long.
Re: Rails – The Missing Parts
#29Earlier quoted context omitted.
Sure - I don't think anyone in the Rails world is claiming to have invented these principles. The problem is that Rails ships with a very limited set of core architectural concepts, and many inexperienced Rails developers feel like they've got to cram all of their code into a Model, View or Controller. Once your codebase reaches a certain complexity, principles from other programming paradigms are extremely useful.
> "The problem is that Rails ships with a very limited set of core architectural concepts, and many inexperienced Rails developers feel like they've got to cram all of their code into a Model, View or Controller." The problem is that people think Rails is an architecture to begin with. Rails is just a framework that uses the MVC pattern (mangled slightly to fit the realm of HTTP). In the end, MVC is nothing but a dir…
Yes, that's a wonderful talk
Re: Rails – The Missing Parts
#30Perhaps because it's written with examples in java but I often feel like no one in the rails community has ever read Eric Evan's Domain Driven Design[1]. It's far and away the best material I've ever seen on how to organise large code bases. It covers pretty much every suggestion that I've seen from the rails community. Sometimes the rails community can feel like the fitness industry, everybody just rebranding things…
I would argue that both the Rails community and fitness industry may operate that way, but for good reasons. Any time you have an ongoing an significant influx of beginners, looking to hit the ground running, bad practices will be everywhere. A handful of established "bibles" or textbooks aren't going to be enough to get the message out to the masses. It may not be appealing to those already "in the know", but good practice messages need to be repeated and communicated in new ways. You also see the same dynamic at the gym, of the experienced gym-rat lamenting the things that personal trainers get paid to teach newbies.
In that same vein, this may be a repeat message of a concept that is not novel, but as an experienced non-web developer who is fairly new to Rails, I learned something from reading this.
I also appreciate you pointing out what sounds like a good development resource (Domain Driven Design).