Wrapping Something That's Not Yours

10 April 2025

What's the cost of introducing something that's not yours to wrap something that's not yours?

Dependency

You use something that's not yours.

You -> NY1

That thing that's not yours (NY2) exposes a public API. This how you talk to it and it talks to you. Well, you don't like the public API. Maybe you think it's cumbersome.

You think, "Somebody else must have done something to improve this." Sure enough, someone has thought the same thing as you. They created an abstraction around the thing that's not yours.

Dependency wrapping dependency

Start using that new thing that's not yours (NY2) in the middle of you and the original thing that's not yours (NY1), and you have a chain.

You -> NY2 -> NY1

What do you get for it? A different public API. You still essentially only have the functionality of NY1. You just call it differently.

What does this cost you? Reliance on NY2 -- its team, schedule, security, bugs, EOL. Learning a new public API.

NY2's public API is not native to NY1. If you're ever in an environment with a different wrapper, like NY3, or if you have to go directly to NY1, your NY2 knowledge will not apply, and your NY2-integrated code will have to change. Probability of change is higher. Learning is less transferrable.

The public API must be particularly egregious to want to pay this cost, because the price is pretty high for no essential new service.

Anti-corruption layer

An alternative is to create your own wrapper.

You -> Yours -> NY1

This way, you control more, not relying on NY2. In some cases you can still shield yourself from NY1's public API. If you fully switched out NY1 for NY3, you could keep your own public API and rewrite the internals of your wrapper only. This is sometimes called an anti-corruption layer.

Note that NY2 wasn't an anti-corruption layer. It was only another changing layer that you didn't control.

Bare dependency

Look for the -- bare dependencies, the simple bare necessities. Forget about your worries and your strife.

Examples? Straight to sql. Straight to fetch. Straight to CSS.

Wrappers? Avoid ORMs. Avoid data fetching libraries. Avoid transpilation.

Expensive, unessential dependency

Hard rule? No. Rule of thumb? Yes.

If something that's not yours provides you a useful service, it can more easily pay for itself.

But if something that's not yours is merely wrapping something else that's not yours, it has a harder time paying for itself. Beware.