2

I'm looking for a strategy to manage my third party dependencies. I don't mean package managers and vendor techs, I mean a process of making decisions about to add a third party lib or to write something by myself.

My personal aptitude is "not invented here syndrome" - I always desire to write something from scratch "to know how it all works". Sometimes I see an opposite way of making this decision among my colleagues when we dive into dependency hell like 124 recursive dependencies for a nano service that is just making a call to an API.

Thus I'm always out of balance. Sometimes I spend a huge amount of time to reinvent something and next time I spend the same amount of time to read tons of third party libs' docs just to make a small fix.

What's the strategy to make decisions about third party dependencies when developing a commercial end product and when developing an open source library?

yannis
  • 39,547
  • 40
  • 183
  • 216
I159
  • 139
  • 4

2 Answers2

3

The decision to use a third party library is not to be done lightly. The decision to write something on your own, on the other hand, depends on the amount of work going to implementing it.

As you correctly noted, third party libraries often depend on other libraries. This may mean library A depends on B v1.0 + C v1.2, and library D depends on C v1.1, and you may not necessarily be able to have C v1.1 and C v1.2 linked at the same time, effectively meaning A and D are incompatible.

If using a third-party library, keep in mind wrappers: Using third-party libraries - always use a wrapper?

Consider also these:

  • Security problems: third-party libraries may have well-known security problems.
  • Time to learn: the hardest thing sometimes may be learning to use the interface, not implementing it, meaning you may as well write all on your own
  • Replaceability: you should have a strategy for replacing a third-party library with another third-party library or writing the functionality on your own
  • License issues: If you write on your own, you have the copyright and no need to worry about licenses and their conditions.
  • Startup time: Loading a simple homemade library is faster than loading a big honking gigantic external library
  • Memory footprint: The same as for startup time, big external libraries consume more memory.
  • Bug risk: The larger the external library is, the more likely is it has bugs.
  • Version stability: Some third party libraries do not have a stable interface, meaning updating the library breaks everything.

I would based on these suggest you to carefully consider whether you want to use a third-party library or not. For a project of mine, a scientific application, I decided to only use a line chart library and implement everything else myself. I actually wrote my own line chart library as well, but didn't bother to fine-tune it to result in as pretty graphs as possible, which is why I in the end used an existing library.

juhist
  • 2,579
  • 10
  • 14
  • Great answer! Thank you! It seemed like we are on the same page. Even these bullet points are pretty intuitive it should be verbalized to refresh it from time to time. – I159 Aug 01 '17 at 12:02
0

If you hide third party components (and other infrastructure code) behnd an interface as decribed in the onion architecture you can postpone/revert your decision at any time. So making the "wrong upfront" decision is not costly any more.

You can start with something you already know/you already have and change it later if necessary.

As a side effect: Having service interfaces makes unittesting/mocking a lot easier.

k3b
  • 7,488
  • 1
  • 18
  • 31