Talks
Speakers
Events
Topics
Search
Sign in
Search
Home
Talks
Speakers
Events
Topics
Leaderboard
Use
Analytics
Sign in
search talks for
⏎
Suggest modification to this talk
Title
Description
It's 2015... your stakeholders have decided that PayPal is out and Stripe is in. Fortunately, you're a planner. You have all of your PayPal interactions isolated in an adapter gem and your interface is clearly defined, easy to re-implement and enforce. Rewriting your adapter isn't small, but it is surmountable and can be estimated accurately so it won't lead to surprises. You win. This talk will cover a collection of best practices for defining, enforcing and test-driving the adapter for your 3rd party service to provide easier flexibility in the future. Help us caption & translate this video! http://amara.org/v/Fp8j/
Date
Summarized using AI?
If this talk's summary was generated by AI, please check this box. A "Summarized using AI" badge will be displayed in the summary tab to indicate that the summary was generated using AI.
Show "Summarized using AI" badge on summary page
Summary
Markdown supported
This presentation by Jeffrey Matias at RubyConf 2014 focuses on best practices for future-proofing third-party integrations in software development. Matias, who has experience in refactoring legacy code and managing third-party interactions, provides a collection of practices that emphasize separation, predictability, and replaceability in interacting with third-party services. ### Key Points: - **Separation of Logic**: It is crucial to keep third-party service implementation separate from internal application logic. This separation enables developers to maintain flexibility and avoid getting tied to external service implementations. - **Predictable Behavior**: Establish predictable interactions with third-party services through comprehensive testing and clear testing patterns. This predictability allows developers to confidently deploy their code. - **Replaceability**: The ability to seamlessly swap out or upgrade third-party services and APIs is vital. This flexibility is facilitated by well-defined adapters and data transfer objects (DTOs). - **Adapter Pattern**: An adapter serves as a gateway to third-party systems. Developers should create a private adapter gem to encapsulate and manage third-party interactions, preventing the need to manage multiple repositories. Existing third-party SDKs can still be leveraged within the adapter. - **Common Vocabulary**: Clearly defining terminology used across the development team is essential for effective communication. Matias emphasizes that having consistent terms helps avoid confusion when discussing integrations and services. - **Data Transfer Objects (DTOs)**: DTOs are used to codify contracts that specify the required parameters for third-party services, enhancing clarity and ensuring correct interactions. - **Testing Practices**: Testing should ensure that both integration and unit tests accurately reflect the behavior of third-party services. Setup and teardown processes are critical, especially in maintaining a clean test environment. Using sandbox environments can prevent data corruption. - **Using Stubs Effectively**: Stubs can accelerate the development process, but it is essential to ensure they accurately reflect the behavior of real third-party services. Regular updates and maintenance of these stubs are necessary to prevent discrepancies. ### Conclusion: Matias underscores the importance of maintaining clear boundaries between third-party services and company logic, utilizing adapters and DTOs for flexibility and replaceability, and having a rigorous testing approach. By following these practices, developers can achieve a structured, maintainable system that simplifies future changes to third-party services. In doing so, teams can significantly enhance their capacity to adapt to changing requirements or services in the future.
Suggest modifications
Cancel
