DEV Community

Discussion on: Where should API calls to third-party services live in a Ruby web app?

Collapse
 
mculp profile image
Matt Culpepper

The problem to that approach is that there is a lot of business logic that depends on other business logic that the gem couldn't possibly know about.

e.g. the Blockfires gem would have to know that each transaction is used by models A, B, C

If we move models A, B, C to the gem, then the gem's gotta know about the database setup, right?

All of our internal, private gems have thin wrappers in the monolith for this reason. There are interactions in the monolith that each gem doesn't know about.

Third-party integrations as gems may work better in a microservices architecture, though!

Collapse
 
paulscoder profile image
Paul Scarrone

I agree but only if the domain delineation is based on business logic. Your integration with blockfire should be concerned with communication.

Consider if you had an event driven system and each model and associated business logic was a domain distributed to its own service cluster. The service knows what model it maintains, some other system will have to probably manage the eventual consistency state of such operations but there are some interactions that all these services share related to blockfire and those should be delegated to a client. The hope is next time a new model crops up, we can stand-up a new domain that inherits how your org uses blockfire.

The distinction is, treating your toolchains like internal platforms. You don't wanna share models but you wanna make expansion of business behavior easier to onboard.