Provider wrappers
Keep authentication, timeout, retries, and normalized outputs at the edge so the rest of your code stays stable as vendors change.
The wrapper should not be where your product logic lives. It should be where vendor weirdness stops.
What a wrapper should do
- accept stable internal inputs
- translate them to vendor-specific requests
- normalize vendor-specific responses
- centralize timeout and retry policy
- expose consistent errors back to the application layer
What a wrapper should not do
- decide product behavior
- own orchestration logic
- leak vendor-specific shapes deep into your codebase
Why boring is good
If wrappers stay boring:
- provider swaps are easier
- tests stay clearer
- application services can depend on stable contracts
Practical takeaway
The wrapper’s job is to make the rest of the system forget which SDK sits at the edge.