2

Note: I'm new to using paid APIs (like Stripe, GPT-3, Twilio, ...).

When you are using a paid 3rd-party API, you are essentially betting on them keeping reasonable prices in the future, right? So in case you'd want to switch the API provider, potentially the work to switch could be huge if their endpoint design is different and they use other naming conventions.

Wouldn't it make sense then to wrap such APIs in an internal interface, so that you don't rely on the vendor itself?

I haven't seen much about that, or didn't know what to search for to find relevant results. Could you point me to relevant sources if I am missing something?

2 Answers 2

4

Have a look to the facade pattern:

https://refactoring.guru/design-patterns/facade

Is just for that:

Facade is a structural design pattern that provides a simplified interface to a library, a framework, or any other complex set of classes.

2
  • Yes, I think that's it, thank you. On another note: are there other important patterns or pitfalls when working with paid APIs? Mar 9 at 20:35
  • Hi @MoritzGroß , that totally depends on your context. Talking about Developing context, just try to not couple your code to the one provided by third parties, since if you decide to change provider it is not a nightmare of dependencies and code changes
    – X.Otano
    Mar 9 at 20:44
1

Third party APIs usually have a very broad purpose, so it's often useful to create a wrapper to simplify down to your exact use case, and to add things like caching and rate limiting, and adapt the interface better to your language and style choices.

In my experience however, trying to make a wrapper for the sole purpose of potentially swapping out a different implementation in the future rarely works out. That's because it's much more common to switch back ends based on features than price changes, and those features usually require significant wrapper interface changes.

For example, the migration I'm currently working on requires a shift from a synchronous interface to a lazy asynchronous interface. That's not something that was anticipated when the wrapper was first written. In general, it's really difficult to anticipate future interface requirements like that. Facades are therefore most useful if you already frequently switch back ends now, like different APIs for different deployments, etc.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.