Talks
Speakers
Events
Topics
Sign in
Home
Talks
Speakers
Events
Topics
Leaderboard
Use
Analytics
Sign in
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. Larger Rails apps are moving towards Service Oriented Architecture with adapters (typically custom gems) abstracting 3rd party services. This talk will cover defining, enforcing and test-driving the interface for your 3rd party service to provide easier flexibility in the future. Help us caption & translate this video! http://amara.org/v/F0om/
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 talk, delivered by Jeffery Matthias at the Rocky Mountain Ruby 2014 conference, focuses on strategies for future-proofing third-party integrations within software architecture. It addresses the importance of isolating third-party services to enhance flexibility and maintainability in software products, especially as organizations shift towards Service Oriented Architectures (SOA). Key points include: - **Separation of Concerns**: Emphasizing the necessity of keeping third-party logic out of the core application code to avoid dependencies on external implementations. - **Predictable Behavior**: Advocating for test-driven development to ensure interactions with third-party services are predictable and manageable. - **Replaceability**: The concept that any third-party API should be replaceable, encouraging engineers to consider future changes when integrating these services. The speaker shares insights on defining a clear architecture for such integrations, using a conceptual example involving a 'Music Box' app and a 'Teapot Adapter'. This adapter acts as a bridge between the application and third-party services, ensuring that the main application code remains agnostic to specific third-party implementations. Key architectural components include: - Using Ruby gems to bootstrap adapters for third-party services. - Routing messages to service objects that interact with these third-party services while keeping implementation details concealed from the main application. - Importance of having a consistent internal vocabulary distinct from the third-party terminology, which helps in communication among stakeholders and minimizes confusion. Finally, the talk emphasizes that while team members may never intend to swap out third-party services, planning for potential changes is critical. This foresight leads to better-designed systems that remain adaptable to change over time. In conclusion, the presentation advocates for a structured approach to managing third-party services to enhance the development process and safeguard against common pitfalls associated with legacy integrations.
Suggest modifications
Cancel
