Web Application Dependencies - use them wisely

This post is about node dependencies and their meaning in your web applications. If you're using external dependencies in your project (and you're probably are), this post is for you!

The best thing about being a developer in 2020 is that there are a lot of open-source projects that can help with speeding up your developing process, and there are a lot of external libraries that can solve common problems seamlessly.

Using external dependencies has changed the game years ago since developers were able to invest more time in their application logic, by using out of the box solutions.

There are two kinds of dependencies:

• Development
  • dependencies that are executed on developers environments or on remote hosts for internal processes (e.g CI/CD, deployment...)
• Runtime
  • Back-end dependencies
    • dependencies that take part in HTTP communication
    • dependencies that are running on you back-end environment
  • Front-end dependencies
    • dependencies that execute on your user's environment (browser)

External libraries have given the ability to use code that was tested across many environments, and major projects usually have supportive communities and hard-working code owners (god bless them all), that keeps those projects alive.

On the other hand publishing, an open-source is not require anything but a valid user, and there is no regulation on the quality of open-source projects.
npm registry has more than 350k published packages at the moment, so statistically, some of them are not too good for your project.

External dependencies have three main effects on your web application (including dependencies from your HTML file)

Security
Using external code could be dangerous since ambiguous libraries could add malicious code to your development environment or your user's runtime (intentionally or by supply chain attacks)

examples: back-end dependency that steals development credentials or front-end dependency that steals PII from your users.

Performance
Code execution is not "free" (Newton’s third law 😁 ), so adding external code might cause some performance issues since using generic and solutions for relatively easy problems could cause an overhead.

example - using lodash.concat function instead of Array.prototype.concat with no good reason

Also, some libraries "hide" bugs, that might cause memory leaks or CPU overuse when used in scale or untested environments.
Some of these bugs are hard to detect, but as popular the open-source is, the less likely it will happen (or won't be fixed)

Bundle size
Adding dependencies to the front-end bundle will increase the loading time of a page (more resources -> more bytes to download -> more time), and page loading time has a direct effect on conversion rate, so heavy and not optimized front-end libraries might become expensive to your business.

There is a trade-off between using dependencies freely and investing time on investigating them since dependencies are used to solve problems fast, and not to create more work.
Developers should have the freedom to use dependencies since they are decreasing development time and serve smart solutions out of the box, but dependencies should be used wisely.

Solutions

Security

• Scan your static dependencies using services such as Snyk. You can also add security alerts to your Github repository and to your CI/CD process.
• Use lock files (package-lock.json, yarn.lock) to ensure that dependencies are installed currently between environments, and be strict with your dependencies versions (do not use * for versions in your package.json file)
• Monitor your front end execution using web security services such as PerimeterX Code Defender. You will never really know what is happening in your runtime if you won't monitor it in the right way (you shouldn't do it yourself).

Performance

• Runtime monitoring
  • rendering
    • Largest Contentful Paint
    • first-paint, first-contentful-paint)
  • long tasks
  • Document state change time (load, DOMContentLoaded)
  • Conversion rate changes (any business has its own conversion metric)
  • Measure your own code and your business logic (which is using the external dependencies)
• Use lighthouse
• Use chrome's performance tab to investigate performance issues

Collecting data from 1% of your users is sufficient enough to detect bottlenecks

Code size

• Check the size of any external code (e.g don't add 10k library only for one function...)
• Avoid adding dependencies from your HTML file as much as you can. Adding dependencies in the compilation time will allow to us tree-shaking to reduce the final payload size.

Personal suggestions

• Read the code of open-source projects that you're using. It will help you to detect potential bugs and will improve your coding skills.
• Check for known issues and bugs of libraries that you're using
• Use only up-to-date dependencies (you can always check for the last commit). "Dead projects" means bugs and future compatibility issues.
• Don't use dependencies to solve all of your problems. Try to create your solution from time to time (when it make sense), and it will make you a better programmer.
• Create or contribute to an open-source project. It is fun to contribute to the community, and it nice to know that your code is helping other projects (I'm working on these two projects these days: webscanner, script-pattern-factory)

Thanks for reading!
This post is more about the awareness of using external code, and I hope that I could help you manage your dependencies in a better way.