We currently do use this sort of pattern, and even give it its own folder app/services, but we only use it sometimes.
Right now I'd say we're sort of caught in between "hacked to get things to work" and "decent architecture" state (most code could probably be described that way).
The problem is probably that we've sort of gone half-way with some of these things.
The fact that we have the labor folder and the services folder (and the liquid_tags) and the models folders is indicative of some indecision combined with lack of taking the time to actually take the time for dedicated large-scale refactoring.
There are different schools of thoughts in terms of folder structure here (should it all go in models, with subfolders?)
If you have any opinions here, I'm all ears.
PS, we actually define our own timeout at about 9 seconds. RACK_TIMEOUT accepts some a Rails-magicky ENV variable called RACK_TIMEOUT_SERVICE_TIMEOUT. We could extend this longer, but everything we do really should finish sooner, so it would be better to fix the code IMO.
The fact that we have the labor folder and the services folder (and the liquid_tags) and the models folders is indicative of some indecision combined with lack of taking the time to actually take the time for dedicated large-scale refactoring.
I think it's normal :) A way to refactor could be choosing one style and slowly convert the rest to it
There are different schools of thoughts in terms of folder structure here (should it all go in models, with subfolders?)
Dunno. I've never liked the "fat model" approach because it leads to giant files with a lot of different business logic. For example, where do you put a method that operates on a user and a comment? In user? In comment? 42?
One thing that I like is having "third party services" clients in the same folder, especially if they are used in multiple part of the business logic.
I've also used presenters in the past to group the display logic and (some) query objects to hide complex queries and be able to test them in isolation.
These are a few articles on the topic of how to structure or refactor Rails code:
Presenters: I love presenters, because they make clear which part of the logic is just for the templates. A date formatter for the UI shouldn't be in a model for example. They aren't super easy to test in pure Ruby but dev.to moved on from controller tests so this shouldn't be an issue.
Sandi Metz’ rules for developers are more or less in tuned with what CodeClimate is warning about (ps. it's okay to break them if needed :D)
Another thing I would consider is to make more explicit what is an asynchronous job. The code base right now uses delayed_job directly with its various .delay, _without_delay and handle_asynchronously. Refactoring all of this into Active Jobs would have the effect of make jobs explicit and produce a nice app/jobs folder as a central repository for all the async stuff. This way you can test it in isolation if needed or if in the future you outgrow delayed job you know where to go to make the changes.
PS, we actually define our own timeout at about 9 seconds. RACK_TIMEOUT accepts some a Rails-magicky ENV variable called RACK_TIMEOUT_SERVICE_TIMEOUT.
Ah! Good to know :) Well, it's entirely possible that the wall is hit at 9 seconds then.
We could extend this longer, but everything we do really should finish sooner, so it would be better to fix the code IMO.
We currently do use this sort of pattern, and even give it its own folder
app/services, but we only use it sometimes.Right now I'd say we're sort of caught in between "hacked to get things to work" and "decent architecture" state (most code could probably be described that way).
The problem is probably that we've sort of gone half-way with some of these things.
The fact that we have the labor folder and the services folder (and the liquid_tags) and the models folders is indicative of some indecision combined with lack of taking the time to actually take the time for dedicated large-scale refactoring.
There are different schools of thoughts in terms of folder structure here (should it all go in models, with subfolders?)
If you have any opinions here, I'm all ears.
PS, we actually define our own timeout at about 9 seconds.
RACK_TIMEOUTaccepts some a Rails-magicky ENV variable calledRACK_TIMEOUT_SERVICE_TIMEOUT. We could extend this longer, but everything we do really should finish sooner, so it would be better to fix the code IMO.I think it's normal :) A way to refactor could be choosing one style and slowly convert the rest to it
Dunno. I've never liked the "fat model" approach because it leads to giant files with a lot of different business logic. For example, where do you put a method that operates on a user and a comment? In user? In comment? 42?
One thing that I like is having "third party services" clients in the same folder, especially if they are used in multiple part of the business logic.
I've also used presenters in the past to group the display logic and (some) query objects to hide complex queries and be able to test them in isolation.
These are a few articles on the topic of how to structure or refactor Rails code:
Another thing I would consider is to make more explicit what is an asynchronous job. The code base right now uses
delayed_jobdirectly with its various.delay,_without_delayandhandle_asynchronously. Refactoring all of this into Active Jobs would have the effect of make jobs explicit and produce a niceapp/jobsfolder as a central repository for all the async stuff. This way you can test it in isolation if needed or if in the future you outgrow delayed job you know where to go to make the changes.Ah! Good to know :) Well, it's entirely possible that the wall is hit at 9 seconds then.
Agreed
I know it's a lot, but the great thing about refactoring is that it can be (mostly) done one step a time :-)