Design: Third-party dependencies

When third-party should be a second choice?

A pile of big “modern” dependencies depend itself on a small module written years ago by random person.
A pile of big “modern” dependencies depend itself on a small module written years ago by random person.
Beware of the dependencies of your dependencies (XKCD drawing).

When to use them

There are several reasons to use third-party software:

  • lack of resources: you don’t have the time or the workforce to do it ;
  • reusability common sense: somebody seems to have the solution to your problem, so why not using it? This will save you time (which is critical in professional environments) and will probably warrant some good quality provided it has already been tested by many users.
  • adoption: if a library or framework is widely used (and provided it brings real and substantial added value) it might save you training time to choose it, as other developers of your team will more likely know it already (or will be less reluctant to invest in learning it, conversely): APIs and patterns will be well-known, so your team will speak the same language quite quickly.

When not to use them

There are also contexts where you should think twice before using third-parties:

  • monolithism: The share of the library you’re using is only a tiny part of the library itself. Maybe you would benefit from using only the code you need. For instance, don’t use Moment.js to get a pretty print of the current date.
  • fast evolution pace: If the library or framework you choose has strong competitors, or if the addressed domain is nascent, it is more likely that the third-party of your choice might be superseded by another one. So either you will keep on using outdated software, or your investment in any proprietary APIs might be lost.
  • specific critical requirements: It may sound obvious that nobody is likely to use a third-party software that doesn’t meet its project requirements, but this is more a matter of mid-term and long-term projection.
    Some software can meet your first requirements but not others that you know will occur. So building a custom solution might be redundant at the beginning, but might pay off on the long run. For instance you might be satisfied by Matomo/Piwik for your current analytics, but this might not be a good basis for the extended ones you know will come in the coming year.

How to achieve flexibility

Different jack plugs
Different jack plugs
Each dependency implies coupling with a specific contract. How to limit such coupling?
  • know better your needs as your API will contain only what your app needs and probably not the whole offering of the third-party product. Thus you might be able to better know what is underused or not and if that product could be easily replaced or not by a better or lighter solution.
    For instance by wrapping a Moment.js behind your TimeUtils.js API, you might discover that you could replace that product by a simpler and lighter one, possibly even your own custom code.
  • de-couple your need from the product offering: When you’re using a product, you also might be limited by this product. What if you need a service that is not provided by your logging product? By hiding that product behind a facade, you are free to aggregate a set of products (or custom solution) to provide the facade contract. For instance you might want your logging API to send PagerDuty messages in case of critical errors, as a supplementary task to the usual logging operation.


Integrating a third-party product might be a good or bad choice depending on the coupling it induces and of how the product offering (over)fits you needs.

Written by

Software engineer for three decades, I would like to share my memory. Also author of

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store