9 Third-party libraries: Libraries you use become your code

When building our software systems, we have time and budget limitations. Because of those limitations, it is not feasible to write every piece of code that your software uses. Almost every application needs to interact with the underlying operating system, filesystem, and external I/O. For those interactions, we usually don’t reimplement the logic. We pick the libraries that are already present and provide that functionality for us. We call those libraries third party because our team or company does not create them. They could be developed by an open source community or other companies specializing in a specific part of the system’s design. For example, when sending data to an external HTTP system, we often pick an existing HTTP client implementation.

9.1 Importing a library and taking full responsibility for its settings: Beware of the defaults

9.2 Concurrency models and scalability

9.2.1 Using async and sync APIs

9.2.2 Distributed scalability

9.3 Testability

9.3.1 Testing library

9.3.2 Testing with fakes (test double) and mocks

9.3.3 Integration testing toolkit

9.4 Dependencies of third-party libraries

9.4.1 Avoiding version conflicts

9.4.2 Too many dependencies

9.5 Choosing and maintaining third-party dependencies

9.5.1 First impressions

9.5.2 Different approaches to reusing code

9.5.3 Vendor lock-in

9.5.4 Licensing

9.5.5 Libraries vs. frameworks