future-proofing your 3rd party integrations - Rocky Mountain Ruby 2014

The adapter pattern using gems, dtos, and communication.

Transcript

1. future-proofing your 3rd party integrations a collection of practices Jeffrey Matthias @idlehands
2. goals • keep 3rd party logic out of our code • make 3rd party behavior predictable • make 3rd party replaceable
3. Insert 50 ft view here.
4. it’s just a gem
8. Clearly define internal vocabulary.
9. • package vs ‘product rate plan’ • add_on vs ‘product rate plan’ • coupon vs ‘product rate plan charge’
10. • PackageService handles ‘product rate plan’ • AddOnService handles ‘product rate plan’ • CouponService handles ‘product rate plan charge’
11. forced separation • Data Transfer Objects (DTOs) • Abstract Services
16. uptyped
17. testing is good • never assume data exists in your 3rd party • use a sandbox if one is available
18. • Integration tests can use this, too!
19. stubbing the 3rd party • create a fake service • use VCR
21. always never forget • cassettes must be delete-able • make sure you set up everything you need • CI: kill your cassettes. A lot.
22. recap • define your vocabulary • create an adapter interface gem(DTOs and abstract services) • create an adapter gem (and add uptyped) • create a test environment • use VCR • delete your cassettes!!! A lot!!!!!
23. future-proofing your 3rd party integrations a collection of practices Jeffrey Matthias @idlehands