4 ms·
At my current place of work, we have this strategy and I think it's a mistake. app/lib is just another way of writing app/service. It becomes, over time, a chao
by p-o 3y ago
At my current place of work, we have this strategy and I think it's a mistake. app/lib is just another way of writing app/service. It becomes, over time, a chaotic place where everything goes. If it doesn't fit for _any_ reason, app/lib becomes the place where those files live.
The benefit of lib/ is clearer in my opinion. Files that live there are only explicitly loaded. Some might be loaded in development, some in production, some in test. The conversation about the structure becomes more important because you need to think about what is going to consume your class.
But I think we could take this a step further and instead replace lib/ with engines/. This way, you can create multiple Rails engines that will have their own paradigm and environments' handling.
Every Rails application I got to work on had a lib/ (or app/service) that could have been grouped in a few different engines/. The benefit of using those kind of engines is that conversation about architecture, pros/cons get more defined. At least that's been my experience.
- LesZedCB 3y agoservices are IMO the biggest misfire of an attempted rails convention. "service" is completely domain agnostic and because there's no standard API like there is for controllers or model, the "service" API ranges from `MyService.call` to `MyService.new.call` `MyService.do_thing` etc etc. service became the junk drawer of junk drawers even worse than lib because people at least 'believe' there is supposed to be a convention when there isn't. at least you know lib is kinda wild west. rails has failed to channel applications into domain logic once it scales past start-up rapid development to a huge team of ICs
- nightpool 3y agoI agree with the former, but I absolutely can't agree with the latter. Services aren't necessary to scale up Rails applications. Plenty of people get along just fine with plain old model-view-controller architectures.
- deleted 3y ago[deleted]
- kevinmchugh 3y agoDifferences in files loaded across environments or even the order of loading has been the source of some of the most annoying bugs I've seen. Fundamentally untestable.
- nightpool 3y ago> The benefit of lib/ is clearer in my opinion. Files that live there are only explicitly loaded. Some might be loaded in development, some in production, some in test. This sounds like such a recipe for confusion... why not just have a lib_dev for the very very rare case that something in lib/ isn't appropriate outside of a dev environment? Any RSpec already has spec/support for the test environment side. Saying that everything in lib/ has to be special and unique just because <10% of are dev-only makes zero sense to me. 90% of the lib code I've ever used/written is used in models, controllers, etc and it would make no sense to need to require it everywhere you use it when no other code in Rails works that way.