Modular pains
Picking a popular technology comes with a well documented advantage of having a vast library of plugins/add-ons/extensions/modules to choose from. Just look at a number of Wordpress plugins or number of modules in growing Node.js npm repository. These modules are effectively a reusable solutions to your problems that other people have created. Using them often significantly shortens development cycles, letting developers concentrate on solving new problems. But this model is not without drawbacks.
As with any piece of software (especially in the world of Open Source), one must always be aware of variable quality of code. The difference often comes from (obviously) expertise of author(s) and (slightly less obvious) the adoption coverage and number of eyeballs on the module. As example, with widely used Open Source projects, one can review the feedback/usage and do enough of due diligence to maintain a relative comfort level with the quality of module used. Not so much with smaller modules. This is especially true for the platforms that provide a sandbox environment for developing standalone modules, app store of sorts. Each module is designed to be self “sufficient”, with it’s own data model and its own optimizations for use. Unfortunately, often times, these modules don’t play well with others.
Think about it. You are a developer, you have a need and, like developers do, you create a solution. You optimize the hell out of it. You’re proud of your work. Then you install it on your production system, alongside other modules you’ve used to build your app and BAM! — your app performance plummets. The problem, aside from “it worked on my laptop”, is simple modular software math. A production system is not necessarily a sum of it’s components. Sometimes it’s a multiple. Or, based on (lack of) developers’ expertise — exponent. Maybe the resource you used in your module is shared with other modules that contend for that exclusive lock. Maybe the number of queries per page became too much with the addition of your module. Or maybe an author of another module (or, let’s be honest, you yourself) didn’t scope variables properly causing a weird paradigm throughout the application. Or … [ add your own disaster story here ].
Bottom line is, any system that allows for collection of third party components can suffer from this symptom. And the fine print, right below that bottom line, says that sometimes it’s unavoidable. That said, error on the side of caution before introducing third party components into critical production workflows. Remember, reusing someone else’s code is great. Until it’s not.
P.S. Relying on third party APIs instead of introducing internal modules can have even more devastating effect on your production. In case you were wondering.
