Future-Proofing Your 3rd Party Integrations
summary
Describes a concrete pattern: isolate all vendor code as an adapter gem kept in project wired via bundler, expose a separate adapter interface gem with DTOs with validation in initializer and thin abstract services so implementations stay swappable. Covers using existing SDKs, recording HTTP interactions with VCR or providing a fake service, a test environment that Creates IDs and Ensures cleanup, CI that occasionally skips stubs to catch API drift, and an up_typed check that enforces method signatures.
AI-written summary · about
chapters (28)
- 0:00Introduction
- 1:35What do you want from your thirdparty implementations
- 2:05Making your thirdparty behavior predictable
- 4:19Gem Files
- 5:55Service Objects
- 7:07Define Your Vocabulary
- 9:10Use Services
- 9:56Data Transfer Objects
- 10:44Abstract Service
- 11:29Abstract Classes
- 12:44Adapter Interface
- 15:51Data
- 16:41Test Environment
- 17:55Cleanup
- 19:33Unit Tests
- 20:13Environment
- 22:13Services
- 24:51Goals
- 25:18Keeping and Predictable
- 25:43Documentation
- 26:17Flexibility
- 28:30Define your internal vocabulary
- 28:50Create the adapter interface
- 30:15Create a test environment
- 30:28Keep your tests going
- 30:50Maintain stubs or fakes
- 31:05Fake services
- 31:30Thanks
related talks
27mSimulating and Testing Third Party Service Integrations
47mHolistically built and tested APIs
01h 00mTestability and API Design
30mFrustration Driven Development
47mBuilding and Integrating Frameworks
51mContract-Driven Development-Escape Microservices Integration & Deployment Hell
12mAn Approach to Developing and Testing Third Party JavaScript Widgets
44mRecycling examples