RubyConf 2013 Futureproofing your 3rd party integrations

A compilation of practices, used by the Portal team @sendgrid, for implementing 3rd party services with future flexibility in mind.

Transcript

2. future-proofing your 3rd party integrations a collection of practices Jeffrey Matthias @idlehands
3. goals • keep 3rd party logic out of our code • make 3rd party behavior predictable • make 3rd party replaceable
5. it’s just a gem
9. Clearly define internal vocabulary.
10. • package vs ‘product rate plan’ • add_on vs ‘product rate plan’ • coupon vs ‘product rate plan charge’
11. • PackageService handles ‘product rate plan’ • AddOnService handles ‘product rate plan’ • CouponService handles ‘product rate plan charge’
12. forced separation • Data Transfer Objects (DTOs) • Abstract Services
21. github.com/sendgrid/uptyped rubygems.org/uptyped
22. testing is good • observe the 4 steps of testing • never assume data exists in your 3rd party • use a sandbox if one is available
28. stubbing the 3rd party • create a fake service • use VCR
37. always never forget • stubbed service MUST be maintained • make sure you set up everything you need • CI: hit the sandbox
38. goals • keep 3rd party logic out of our code
40. goals • keep 3rd party logic out of our code • make 3rd party behavior predictable
42. goals • keep 3rd party logic out of our code • make 3rd party behavior predictable • make 3rd party replaceable
44. moar benefits • flexibility - code and business • portability
45. recap • define your vocabulary • create an adapter interface gem(DTOs and abstract services) • create an adapter gem (and add uptyped) • create a test environment • stub your 3rd party for development • maintain your stub/fake!!!!
46. future-proofing your 3rd party integrations a collection of practices Jeffrey Matthias @idlehands