1

I am currently designing a software in which I have to use a rest client. I have decided to use a particular library, but am stuck whether I should use it directly or add a custom encapsulation layer. To make myself more clear, suppose i have to make a request from a function named getAuthInfo.

Doing it directly

function getAuthInfo() {
    return someLibrary.get(path, headers);
}

Adding Encapsulation layer

/* Adding an abstraction layer on top of the library */

import myEncapsulation;

function getAuthInfo() {
    return myEncapsulation.get(path, headers);
}

---------------------------------------------

/* myEncapsulation module */

function get(path, headers) {
    return someLibrary.get(path, headers);
}

The reason why I am asking is because the pace at which things change in javascript world, the library i am using today might do a complete rewrite causing breaking changes or a new library might come out which better supports my use case.

In any such case, if I implement using the first method, I will have to make changes all across the app, but in the second case I will have to make changes in a single module.

But the downside I feel to the second method can be that, there is a little overhead to implement the module and that I will have to maintain very cautiously and document properly for the EncapsulationModule.

What do you guys suggest ??

  • What I usually do is think about how hard would it be to test my code. In this scenario, are you able to easily mock someLibrary library? If not, definitely, write a wrapper that can be easily stubbed. If yes, weight in the other variables. – bobek Nov 29 '17 at 18:30

1 Answers1

1

This is a judgement call that only you (or your team or your manager) can make.

You must weigh the costs/effort of writing an anti-corruption layer now versus the additional effort it would take to find all usages of the external library later when you want/need to replace it.

A large part of this will also depend on how likely you think it will be that the library needs to be replaced during the lifetime of your project.