Binding an interface on top of third-party modules to develop future-proofed and scalable apps

Question

Every day a couple of new javascript modules are created and published around the world and we need to think long term. Let's say today I need to use an ORM module to go smooth and fast. But tomorrow I may face a deprecated module or may find a better one to switch or even may need to create my own.

For example, the team have decided to use Sequelizejs on top of the Sqlite to provide the models:

const User = sequelize.define('user', {
  username: Sequelize.STRING
});
User.create({
    username: 'melbourne'
});

Then, a new type of database like Realm was introduced and they planned to switch:

class User {}
User.schema = {
  name: 'User',
  properties: {
    username: {type: 'string'}
  }
};

let realm = new Realm({schema: [User]});
realm.write(() => {
  realm.create('User', {
    username: 'melbourne'
  });
});

So, this can lead to refactoring the entire application and the team needs an interface to present in front and ignore code rewriting. As a result, switching will be easy and changing the bindings will not affect the entire code.

class User  {
  //...
  define(name, dataTypes) {
    ThirdParty.define(name, dataTypes);
  }
  create(data) {
    ThirdParty.create(data);
  }
  //...
}

Regarding the example, what would be the good design pattern in javascript? How to bind an interface on top of third-party modules to develop the future-proofed and scalable apps?

Answer 1

I don't think it is possible in general to provide a future-proof abstraction layer. Different libraries have different approaches to the same problem which means they may provide different abstractions.

Furthermore, the point of a library is to save you work. If you have to replicate the whole data model one-level above the ORM just to provide an abstraction layer, you introducing complexity with no benefit.

I think the best approach is to keep your code well-factored in general and follow principles of separation of concerns and single responsibility, but don't introduce layers to prepare for a library replacement which may not happen anyway. See the YAGNI principle.