Designing Your API for Their API (Yo Dawg!)

Fullstack Ruby Podcast

It’s tempting to want to take the simplistic approach of writing “to the framework” or to the external API directly in the places where you need to interface with those resources, but it’s sometimes a much better approach to create your own abstraction layer. Having this layer which sits between your high-level business logic or request/response handling, and the low-level APIs you need to call, means you’ll be able to define an API which is clean and makes sense for your application…and then you can get messy down in the guts of the layer or even swap out one external API for another one. I explore all this and more in another rousing episode of Fullstack Ruby.
Links & Show Notes

• Sign up for the Fullstack Ruby newsletter
• Get bonus issues and support this content as an Intuitive+ member!
• Whitefusion: a Boutique Web Studio (hire me!)
• Top 10 Most Excellent Gems to Use in Any Ruby Web Application
• Bridgetown 2.0 Beta

Become a part of the Fullstack Ruby community and learn how to put your Ruby skills to work on the backend AND the frontend. Know somebody who's a JavaScript developer but is interested in learning more about Ruby? Share the site, podcast, or newsletter with them!
Theme music courtesy of Epidemic Sound.

Capitole

1. Introduction (00:00:00)

2. Gems for use in *any* Ruby web application (emphasis *any*!) (00:01:06)

3. Fullstack Ruby is now part of Intuitive+ (00:02:55)

4. Bridgetown 2.0 is in beta (00:04:54)

5. MM v DHH (00:05:43)

6. Writing an abstraction layer to connect to APIs (00:08:00)

7. HTTP REST API calls with Faraday (00:13:50)

8. Some individual methods call multiple API endpoints (00:16:58)

9. Future improvement: async requests in parallel (00:20:39)

10. Yo dawg, I heard you like APIs, so I put an API in your API… (00:23:22)

11. Outro (00:26:52)