Comments on: How (And Why?) To Wrap External Libraries? https://www.codejourney.net/how-and-why-to-wrap-external-libraries/ Pragmatic full stack software development Thu, 24 Aug 2023 15:49:04 +0000 hourly 1 https://wordpress.org/?v=6.9.4 By: Dawid Sibiński https://www.codejourney.net/how-and-why-to-wrap-external-libraries/#comment-244 Sun, 05 Mar 2023 16:36:00 +0000 https://www.codejourney.net/?p=4346#comment-244 I don't recommend wrapping <em>every</em> library. I wouldn't even think about abstracting stuff like <strong>mobx</strong> or <strong>react-hook-form</strong>. This would lead to - as you mentioned - having hundreds of wrappers with probably more logic inside the wrappers themselves than the actual library provides. Referring to your first remark - if the wrappers are implemented incorrectly, i.e. having a lot of logic inside them instead of only exposing the 3rd party code with minimum amount of own code, then I'd agree it is a nightmare debugging this. However, to me, a wrapper should be minimalistic in a way that no documentation is needed for it. It only acts as a proxy to the external code. I create wrappers only for stuff that can be exposed via simple API, without much additional logic inside. Regarding the second point - I had pretty different experiences here 😉 I saw external libraries used so extensively in the code that no one would even think about replacing them. And that's often problematic. If you need to change your wrapper's API because of the changes in the wrapped library, then you either didn't think abstract enough when creating the wrapper or you shouldn't have created it in the first place (see my previous remarks about what not to wrap). Wrappers' role is not only to hide the 3rd party implementation details. They let you <em>think first, use later</em>. First: think which features of a library you might need, try to abstract them (in a form of <em>contract</em>). Later: use the contract's implementation(s) in your code.]]> In reply to Dmytro.

Hi Dmytro, thanks for your comment.
Extremism is always bad 🙂 I don’t recommend wrapping every library. I wouldn’t even think about abstracting stuff like mobx or react-hook-form. This would lead to – as you mentioned – having hundreds of wrappers with probably more logic inside the wrappers themselves than the actual library provides.

Referring to your first remark – if the wrappers are implemented incorrectly, i.e. having a lot of logic inside them instead of only exposing the 3rd party code with minimum amount of own code, then I’d agree it is a nightmare debugging this. However, to me, a wrapper should be minimalistic in a way that no documentation is needed for it. It only acts as a proxy to the external code. I create wrappers only for stuff that can be exposed via simple API, without much additional logic inside.

Regarding the second point – I had pretty different experiences here 😉 I saw external libraries used so extensively in the code that no one would even think about replacing them. And that’s often problematic.
If you need to change your wrapper’s API because of the changes in the wrapped library, then you either didn’t think abstract enough when creating the wrapper or you shouldn’t have created it in the first place (see my previous remarks about what not to wrap).

Wrappers’ role is not only to hide the 3rd party implementation details. They let you think first, use later. First: think which features of a library you might need, try to abstract them (in a form of contract). Later: use the contract’s implementation(s) in your code.

]]> By: Dmytro https://www.codejourney.net/how-and-why-to-wrap-external-libraries/#comment-243 Sun, 05 Mar 2023 08:00:54 +0000 https://www.codejourney.net/?p=4346#comment-243 Oh, how much those bull*t I saw in all my recent projects
What this approach actually brings to the table:
1. For each new developer: instead of looking into the library itself (usually well-documented), you need to debug a custom wrapper (usually not documented). What if you have 30 external libraries (and wrappers)? Or 100+?
2. How often do you really need to replace libraries in your project? I can’t remember any strong case in about 9 years of my work (including positions as Senior/Tech lead). And do you think you wouldn’t need to change your wrapper’s interface (API) in case of some drastic change?

This works in only one particular case – if you are ready to support and spend time on documentation for your wrapper. Elsewhere, it will cost you (mostly new developers in a team) a lot of headaches.

]]>