A few years ago, I wrote a post on why I don’t trust 3rd party APIs. It has never been more true than today (in days of NuGet, npm and other package managers) when adding an API is a matter of seconds. Seriously, you don’t even have to break a sweat. Package managers and web searchers got you covered. We live in the days where even “evil” Microsoft decided to move to the good side of the force and went open-source. Right? APIs get updated more promptly than ever and they are available for just about anything. And code reuse saves you a lot of time. So why am I still skeptic about it?

API porn

Have you ever opened a project and looked at a reference and it was two pages long? Welcome to API porn. If there was an API that would add other APIs instead of a developer, it would be included. The problem with such products, besides obvious reasons, is that no one remembers what those APIs do. Not even original members of the team from whom, if you manage to locate them, you will only get: “I can’t believe this project is still running!”. Like code had a life span. Also, out of numerous APIs, some are bound to be obsolete, which leads to problems upgrading a .NET platform.

Dealing with API dependencies

Lately, I have been given maintenance over several projects using NHibernate. Leaving aside my cautiousness of gigantic ORMs, this in itself would not be a problem. However, someone also decided that it would be good to use Active record pattern to go along with it. You know, because, writing XML mappings and configurations is so 2000s. To do that, one had to install Castle.Core, Castle.ActiveRecord, Castle.DynamicProxy2 and NHibernate.ByteCode.Castle. On top of being tightly bound to NHibernate, Castle.ActiveRecord has a bad habit of creating all mappings on the fly on application start, making it extremely slow (I am talking tens of seconds here) for the poor soul that stumbled to the web site just after application pool has been recycled.

But the worst thing here is, to upgrade .NET framework, one must upgrade NHibernate package (the one included does not support .NET framework newer than 3.5). To do that one must also upgrade Castle.ActiveRecord, Castle.DynamicProxy2 and NHibernate.ByteCode.Castle. All of this APIs are obsolete and incompatible with NHibernate’s newest release. Groovy.

It gets even worse in JS world…

But this is nothing compared to the problems in JS world. Apparently, some still can’t comprehend the fact that each and every JS library must be downloaded to the client before it can be used. If you look at core AngularJS, it is whopping 250 KB of data. JQuery is not much better and even VanillaJS is 40KB large. And people then put other things on top of that. Like jQuery UI or jQuery history plugin (which is today obsolete). I am not kidding you, but I am have worked on a project that had (not counting jQuery core) 18 additional javascript libraries totaling to a whopping 700KB. Some of these libraries are obsolete and for half of them, you cannot even get a description of their purpose online anymore. Upgrading jQuery from version 1.4.1 to 2.0.x is nigh impossible.

Why do developers do this?

I think the main reason is that every project I worked on from scratch started as “just a demo”. It had to be done quickly and in had to have 90% of functionality. When you are pressured and in a hurry, it is increasingly difficult to stop and think hard about what you are going about to do. Also, many developers believe that this demo is “just a demo” and they will be given time to sort things out after the demo is over. I hate to break it to you, guys / gals, but it is not going to happen. If demo is good, every person viewing the presentation will think you are almost done and you will have to continue to work on existing code as there will be no time to start from scratch. On the other hand, if people don’t like your demo, your project will be cancelled before you can mouth the word “cookie”.

All of this might seem I don’t like to reuse code. But…

…this cannot be further from the truth. However, I am a firm believer that adding a 3rd party API to your project should be a well thought-out process and not something that is taken as lightly as writing npm install or Install-Package in nuget console window. Before adding an API to your project, try and figure out what you are adding in. What it’s dependencies are and how they will affect your system? Is it well maintained today and does it have a strong community? Strong community is usually some sort of assurance that API will live on. At least until something better replaces it.