Have you built your app on someone else's code? And beyond that, does the "secret sauce" of your product depend on external libraries or frameworks? While it's tempting to use the latest and greatest tech as soon as it comes out, that's not always a great idea. In this episode, Bill explains why, and what to do to protect your code. Written by Bill Sourour: https://twitter.com/BillSourour Read by Abbey Rennemeyer: https://twitter.com/abbeyrenn Original article: https://fcc.im/2HerXO5 Learn to code for free at: https://www.freecodecamp.org Intro music by Vangough: https://fcc.im/2APOG02 Transcript: “Change is the only constant…” – Heraclitus (Philosopher) The tools, libraries, and frameworks we use to build our web applications today are drastically different from the ones we used just a few short years ago. In a few short years from now, most of these technologies will have changed dramatically again. Yet, many of us make these a central, inextricable part of our apps. We import, use, and inherit from the flavor-of-the-month frameworks as if they’re all going to be around and unchanged forever. Well… they’re not. And that’s a problem. After 20+ years of developing, designing, and architecting web applications, I’ve come to appreciate two important truths: External dependencies pose a great threat to the long term stability and viability of any application. It’s increasingly difficult — if not impossible — to build any kind of non-trivial app without leveraging external dependencies. This article is about reconciling these two truths so that our apps have the greatest chance of long-term survival. The rabbit hole is very deep indeed. If we start thinking of all the things our web apps depend upon it’s easy to think of a dozen or more before we even get to the code: Power Connectivity Firewall DNS Server Hardware (CPU, Disk, Ram, …) Cooling Virtualization Platform Container Platform Operating System Web Server Platform App Server Platform Web Browser As developers, it’s good to be aware of these things, but there’s often not much we can do about them. So, let’s ignore them for now and talk only about the code. In code, there are three kinds of dependencies: 1. Dependencies we control This is code written and owned by us or our organization. 2. Dependencies we don’t control This is code written by a third party vendor or open-source software community. 3. Dependencies once removed These are the code dependencies our third-party code dependencies depend upon. (Say that three times fast!) We’re going to talk mainly about dependencies we don’t control. Dependencies we control and dependencies once removed can still cause headaches, but in the case of dependencies we control, we should be able to directly intervene and mitigate any problems. In the case of dependencies once removed, we can usually rely on a third-party to take care of it for us, since they are dependent on these, too. Why third-party code dependencies are good A large portion of your web application exists to solve common problems: authentication, authorization, data access, error handling, navigation, logging, encryption, displaying a list of items, validating form inputs, and so on... Regardless of which technology stack you use, there’s a good chance that common solutions to these problems exist, and are available as libraries that you can easily acquire and plug-in to your codebase. Writing any of this stuff completely from scratch is generally a waste of time. You want to concentrate on code that either solves an uncommon problem or solves a common problem in an uncommon way. That’s what makes your application valuable: the code that implements the business rules that are unique to your app alone — the “secret sauce.” Google’s search and page ranking algorithm, Facebook’s timeline filtering, Netflix’s “recommended for you” section and data compression algorithms— the code behind all of these features is “secret sauce.” Third-party code — in the form of libraries