Why Abstraction is important and how does it helps?

6 min readJul 27, 2022

If you have been in technology for quite enough time, you may have seen how rapidly it changes, and maintaining these changes in the product we develop on a daily basis is a nightmare but still, we have to do it. Abstraction can be super helpful when we want to reduce the overhead of making large changes due to a change in packages, libraries, or utilities we use in our application.

What is Abstraction?

Abstraction is the act of representing essential features without including the background details or explanations. In the computer science and software engineering domain, the abstraction principle is used to reduce complexity and allow efficient design and implementation of complex software systems.
— techopedia

This means Abstraction helps to represent complex systems in a very simple manner by hiding the complex software logic behind the simple APIs for the user to use the application. To understand it in very simple terms, let’s explore with an example

We open and close our tap multiple times on a daily basis, have we ever thought of that complex system that brings water to that tap. Simply no, we don’t really have to, we expect the tap to run water as soon as we open it.

So the concept of the abstraction is very similar to that tab water example. We hide the complex logic of our application behind very simple APIs for users to interact with. In the same way, the complexity of water lines is hidden behind that simple tap with which we interact daily.

Why it's Important?

The first very important use case is to hide the complex logic, which we have already looked at with the tapping example, let’s talk about other important features Abstraction brings into your architecture.

Define a clear and concise boundary

Code we interact with on daily basis has been contributed by many developers throughout time and every developer has their own special way of writing code which introduces fragmentation inside the code. We invest in Frameworks, Linting, Code Style Guide, and other many tools and techniques to reduce the fragmentation inside the code. But I have seen them fail on many occasions.

Abstraction also helps to set a clear and concise boundary where developers can use simple and unified APIs to interact with our systems or internal components, and the developers developing those APIs can use the same boundaries to prevent any ambiguities in the API schema.

Changes are quick and easy

There are many libraries being developed every day and these days we have multiple libraries to solve one single problem. Choosing one of them is very difficult, as many of them overlap in features. Even after choosing any one of them, one very important question still needs to answer. What happens if we decide to change that library in the future? or What happens if we need to upgrade that library that has breaking changes?

Abstraction helps in both scenarios, let’s understand this by a very simple example

Suppose our application demands network calls over HTTP/HTTPS and we need to pick from three major ways that have most of the overlapping features, especially on the browsers.

XMLHttpRequest (https://javascript.info/xmlhttprequest)
In-built in all browsers
Support progress event
No promise supportFetch (https://javascript.info/fetch)
Only in latest browsers
Does not support progress event
Promise by defaultAxios (https://github.com/axios/axios)
Third party, supports all browsers and NodeJS
Support progress event
Promise by default

So now we need to pick any of them, let’s say Axios which is more feature-rich and have support for browser and server both. Once we choose that library and build our application use it everywhere.

Now our application becomes tightly coupled with Axios and changing it with some other library in the future becomes a huge task itself.

Using Abstraction what could have done, we would have created a simple utility with defined methods and properties to make HTTP calls, using Axios underneath.

So if we needed to change Axios from any other library in the future it will be a quick fix. We just have to update that utility to use the new library underneath without making any changes to the APIs we have exposed from our utility.

So without touching any part of the application code we have changed the HTTP library from Axios to something else.

Decouple application code from its dependencies

As we have seen in the previous example that we have changed the HTTP library of the application without making any changes to the application code with the help of Abstraction we have created using a simple utility.

We have decoupled our application code from that Axios dependency.

There are many other benefits of using Abstraction in our application architecture, especially when we talk about modularity, reusability and etc.

When to use abstraction?

There isn’t a pre-defined rulebook on where to use Abstraction and where not, but these are some good use cases where I found Abstraction can be a huge help to scalability and maintainability

Use of external libraries
Shared utilities, libraries, and packages
Remote API interfaces
APIs exposed to external parties

So, the best way to answer this question is to ask the following questions to ourself

Are we going to keep this external library, utility, or package till the eternity of the application?
Are those shared utilities, libraries, and packages will remain the same forever?
Would it be possible to keep the same remote API interfaces forever?
Are we going to keep a common interface for all the exposed APIs forever?

If any of our answers to those questions is no then we should think about creating an abstraction for that piece of code.

How to do it?

Let's deep dive and try to understand the whole thing by getting our hands dirty by building a utility to make HTTP calls in JavaScript (Browser) which provide an abstraction so that we can change the underlying technique at any given time and not worry about a huge change the application.

Explore the use case in-depth

The first thing we should do is to investigate and explore all the possible use cases before even going further into the implementation.

So for our requirements to make remote calls can be as follows

Should be able to make GET, POST, PUT, DELETE HTTP calls
Should be able to pass custom headers to HTTP calls
Should support various events especially Upload Progress
Should be a Singelton so that we can have only one instance of the utility

Define a clear interface

After we have a clear and concise use case we can now define the interface for our HTTP utility, which can be as follows based on our use cases

Should have a static method getInstance to return or create an instance of the utility
Should have public methods to make get, post, put and delete HTTP calls with a required parameter url of type string and an optional parameter options of custom type
The options parameter should have a defined type which includes headers, query params, request body and etc.
Should have a private method send to make each type of HTTP calls

Once we have a clear definition of what our utility interface looks like, it would just be created.

For example, based on the interface we have defined, our http.ts utility to make HTTP calls should look like this

Let’s spend some time understanding why those individual methods are so important and why not directly use fetch axios XMLHttpRequest to make HTTP calls inside our application.

Using this http.ts utility inside our application to make HTTP calls would act as an abstraction over the undelaying technique we are using, in our case, that technique is browser’s XMLHttpRequest and if we wish to change this technique with something else, we’ll only have to change the implementation of send method and all other methods, interfaces, and their usages remain exactly the same.

This means by just changing the one method we will be able to move our whole HTTP call implementation from XMLHttpRequest to maybe asios, fetch and etc.

How cool is that 😮

And that's the power of Abstraction, we have discussed so far.

Happy engineering!