4 ms·
The answer to that question could probably fill another blog post :D Long story short, Rails and dependency inversion equals lots of friction. The whole framew
by exterm 6y ago
The answer to that question could probably fill another blog post :D
Long story short, Rails and dependency inversion equals lots of friction. The whole framework is built on the assumption that it's OK to access everything from everywhere, and over the years we've built lots of tooling on top of those assumptions.
E.g. we heavily use https://github.com/Shopify/identity_cache https://github.com/Shopify/identity_cache with active record associations that cross component boundaries.
We also have a GraphQL implementation that is pretty closely coupled to the active record layer and _really_ wants to reach into all the components directly.
All of those problems can be overcome, but this is definitely an area where we have to working against "established" Rails culture, and our own assumptions from the past.
- sandGorgon 6y agoWhat's the difference between "componentization+engines" and microservices? From a deployment perspective are your engines deployed and scaled independently?
- exterm 6y agocomponents are - same database - same runtime - same deployment - same repository That said, I don't think this is an either/or. It's a spectrum. you can have components within the same runtime and repository that have separate databases, or components that are using the same database but live in separate repos, etc. From one monolithic app towards fully separated microservices is a spectrum, and I think developers should be enabled to move freely around that spectrum.
- sandGorgon 6y agoI think components are the better option. Because it allows for separation of concerns without introducing deployment ...or worse : political complexity. I call them Micro-SDKs.
- straws 6y agoI hope to hear more in the future! Do you envision any extension points to the way engines are implemented that could better enforce boundaries? In our engines, there was nothing that referenced another engine's resources, leaving the main application to handle route mapping and ActiveRecord associations between app models and engine's models. I feel like the use-case for engines has long been around supporting framework like functionality (Devise, Spree, etc), but I wonder if there are changes to be made that better support modularization for large apps.
- exterm 6y ago> extension points to the way engines are implemented that could better enforce boundaries Can you expand on that? I'm not sure I follow.