Code dependency is a crime.

"Change is the only constant …" – Heraclitus (Philosopher)

The tools, libraries, and frameworks we use today to build web applications are very different from the ones we used just a few years ago.

For a few short years from now, most of these technologies will once again change completely. However, most of us still turn these tools into a central part that cannot be removed from the applications we make.

We import, use, and inherit everything from "interesting months" frameworks as if they will forever remain unchanged. Well … there's no such thing. And the problem lies there.

After more than 20 years of programming, designing, and structuring web applications. I began to experience two facts:

1. External dependency is a frightening threat to the stability and long-term survival of any application.
2. Building any type of non-ordinary applications without taking advantage of external dependencies is also extremely difficult (if not impossible).

This article will neutralize these two facts, thereby helping our application have a better chance of survival.

The rabbit cave is really deep.

If we start to think about what our web application needs, this list is up to a few dozen items before we can write code:

• Source
• Connect
• Firewall
• DNS
• Hardware for server (CPU, Hard Drive, RAM, …)
• Radiators
• Virtualization Platform
• Container Platform
• Operating System
• Web Server Platform
• App Server Platform
• Web browser

As a programmer, notice that these things are dark, but usually we can't manage these. So now let's put this list aside and just discuss the code.

In code, there are three types of dependecies:

1. Dependencies controlled by us

This is a code written by ourselves or our company.

2. Dependencies we can't manage

Code is written by a third party provider or an open source community.

3. Dependencies once removed

These are the required code dependencies for third party dependencies.

We will mainly discuss the dependencies we cannot control .

The Dependencies we control and the once removed dependencies can still hurt us all, but in the case of controlled dependencies, we will be able to intervene and prevent any problems.

In case of dependencies once removed, we can often rely on a third party to help us manage.

What's good about third-party code dependencies?

A large part of web applications exist to solve common problems: verification, licensing, data access, error handling, navigation, logging, encryption, list display, data entry moderation go to the form, …

No matter which technology combination you use, it is possible that the solution to these problems is already available somewhere, such as a library, you can easily access and 'add 'go to my codebase. Sitting around completely rewriting these available items is a waste of time.

You will want to focus on how to solve these unusual problems, or at least normal problems, but in an unusual way. That's what makes your app worth: the code applies a unique business rule that's only available in your application – the "secret sauce" formula.

Google's search algorithm, Facebook's timeline filter, Netflix "hint to you" – the code behind these features are all "secret sauces".

Third-party code – in the form of a library – allows you to quickly integrate the commercial features of the application you are developing, from which you can focus on your "secret sauce". .

What's wrong with third party code dependencies?

Consider any non-trivial web application developed in the last few years and you will be surprised by the amount of code coming from third-party libraries. What if some of these libraries have drastic changes , disappearances , or breaks ?

If it is an open source application, you may be able to solve it yourself. But that library is not yours, how much do you understand the code in it? Most of the reason you go to these libraries in the first place is to not worry about too much detail. But you go into a dead end. You have completely tied your property with non-personal depenencies, and uncontrollable.

Maybe I am exaggerating the problem, or speaking in a theoretical perspective. But I assure you – I have witnessed many customer cases completely stuck when I embed too many third-party code into my application. The following is just a recent example …

An old client of mine built the application through the Backend-as-a-Service provider owned by Facebook, Parse . They use a JavaScript client library provided by Parse to use Parse's service. In this process, they closely linked all their code (including the "secret sauce" code) to this library.

Three months later after this client's first launch – just as soon as they started attracting real paying customers – Parse again announced to close.

And instead of focusing on the product and expanding the number of customers, this customer has to find a way to fix this vulnerability, switch to Parse version, host, open source, or replace Parse completely.

This disruption was so serious that they had to completely remove this application, a potential but too young application.

Balance good or bad

A few years ago, the solution was to solve the problem, and took advantage of the third-party libraries: wrapping them with Adapter Pattern .

Basically, you will pack third party code in a class or adapter module that you have written down. This trick will help you somewhat control the features of the third-party library.

When using this method, if a third-party library or framework changes, or loses, you just need to modify the code adapter a bit. The rest of the application remains unchanged.

In theory, it sounds reasonable. When you have closed dependences that provide only a few features, this solution is enough. But things will quickly break down.

As you can imagine, how long does it take to pack a React library (including JSX)? So what about jQuery, or Angular, or Spring framework in Java? Listening is also frightening.

So, I think you should take a more flexible approach …

For each dependency you want to add codebase, assess their risk level based on the following two criteria:

1. The ability to change (in substance) of dependency.
2. The level of damage that the change (of substance) of dependency can cause to the application.

A library or framework will be less likely to change if some or all of the following are true:

• Has stood firm for many years and has had many major releases.
• Widely used by many commercial applications.
• Supported by a large community.

A library or framework will cause less damage if some or all of the following are true:

• Only a small part of the application used.
• The code that relates directly to it does not involve the "secret sauce" that we mentioned.
• Removing it requires very little change to our codebase.
• Your entire application is very small, and can be rewritten quickly.

The more risky the library is, the more you should package it, or avoid using it completely.

You must be extremely important and anxious to protect the central value of the application, 'secret sauce'. Please make this code as independent as possible. If you very need to dependency, please inject instead of reference. Even when injecting, you must be careful.

Sometimes, this means that it will give you a "good word" for a particular library (or you really want to use it for many reasons). Be strong. Believe me, this sacrifice will be rewarded. Watch if people invest heavily when Angular launches, or my client uses Parse. Not happy.

Talking about "fun". Have a look at the picture below …

Dependency graph for TinyTag explorer

The image above is a dependency chart for the application called TinyTag Explorer.

Drawing a dependency chart for the applications you have created is a great way to understand more about the level of risk brought by dependencies. This is the tool I often use to create charts of these types in many languages ​​like JavaScript, C #, Java, PHP, and Python.

ITZone via medium