The thing is that I wasn’t talking about HTTP APIs 
I’m more inclined to solutions like packwerk so I’ll still have APIs for each component, but I’ll avoid lot of issues around the network (like the ones you have just mentioned) 
I agree with all of the above. In addition… if you think of modularization as a sliding scale from ball-of-mud to perfect then the suggestions above are very much on the right of that scale. If you are comfortable being much further left to start, you could allow ActiveRecord to cross certain component boundaries and you could have a model X (in component A) reference model Y (in component B) if you A depends on B. This will allow you to have any ActiveRecord associations from A to B (but not vice versa).
Yeah I don’t think there is a silver bullet, I’d probably use different solutions depending on the company/project/dev team/deadlines/etc but in general I’d say I’d like to be as close to rails conventions as possible, and incrementally moving to the right of that scale as needed by the context.
Crossing certain boundaries sounds like a reasonable start, though I guess I’d try to go a step further and do it through a well defined API (such as if it was an HTTP call, but it isn’t) instead of using AR associations. The main drawback would be that it could mean doing more queries since I won’t be able to join the tables anymore
Message excluded from import.
Message excluded from import.
Message excluded from import.