I've spent the last two weeks migrating one project from Angular's deprecated Http module to the new (more elegant) HttpClient. Two weeks -- in my opinion that's way too much maintenance time on a single layer of the app. I encountered something similar in the fall with Angular Material.
Which brings me to the question: should we wrap critical built-in modules to avoid this kind of massive overhaul?
While Uncle Bob suggests that we should avoid concrete dependencies where possible, you'd think that concrete dependencies on the framework itself would be okay. But this HttpClient debacle is proving otherwise.
Additional follow-up question: If / when we should put our own interface around critical modules, how do we define "critical?" What sort of modules warrant this kind of architecture?
Top comments (6)
I have heard a lot of troubling things about Angular: that the API is not very stable and developers change it quite often...
I usually use
request(backend) orfetchAPI (client) for handling HTTP requests which I know are quite stable (the first one is quite old and the second one is a standard). Nevertheless, I also have a wrapper :-)One approach to deciding if you should write a wrapper is to see if you can improve or simplify the API of the original module. Many modules have way too many options, and you might not need all of that. So it's good to write a simple wrapper with much smaller API surface and use it in the application code. I think if you just wrap every function of a complex module you won't gain much because it will be still a lot of work if you decide to migrate to an alternative.
I agree. The JS community might seem to think of this as the price of doing business sometimes. Code against the possibility of overhaul or get out. The scenario is tricky, but with the recent history of JS and browsers I wouldn't bank on a ton of stability any time soon.
Tangential, but speaking of JS instability, this article is interesting: theverge.com/2018/1/4/16805216/goo...
On your tangent:
I saw the article earlier and think it is very misleading. While I do think they bring up some valid points. I wholeheartedly disagree Chrome is the new IE. The biggest problem I see that the article talks about is the rise in "Chrome only" sites. And while it is an issue, it's not born from a lack of features in Chrome or Google abandoning standards and forcing web developers to deal with quirks purely for market share.
These "Chrome only" sites are born out of (for one reason or another) other browsers, including Firefox and Edge, being behind in the implementation process. I was working on an app just the other day where I discovered it didn't work in Firefox because it still does not support JS Modules and one feature didn't work in Edge for lack of support of HTMLCanvasElement.toBlob and ImageBitmap.
I would be much more prone to say Safari is the "new IE"
I agree with the sentiment in general. Google is a much better player in the browser space than some others, especially Apple, but I think they still deserve scrutiny with a direction that makes Google into the web in a way. It's no one thing but it's an ongoing thing to pay attention to. AMP, PWA, certain other Chrome APIs all create scenarios that blur the line in a way. It's not necessarily great for developers all the time. Microsoft and AOL before them put out services that hurt the web in ways reflective of what Google's doing.
Google is simultaneously the best thing for the web and a potential thorn and danger at the same time. Food for thought is all.
With how much investment they have in the web, it only makes sense they would also be the bearers of so much great web content as well. As time moves on I can only hope that they are able to properly balance the needs of the Web and themselves.
So far I think they've done a good job but it hasn't been a perfect road even though I do commend them on all the work they do on writing standards and developer education.
Ideally you would separate your code from third-party modules with an abstraction layer. Never expose the entire library, expose only the pieces you want, wrapped in a way that makes sense for your code. This shields against API instability as well as vendor lock-in.
Practically though, ideals are more like lofty visions than achievable goals. You strive for this, but you're going to take shortcuts. It's the conflict I talk about in this article.
Business priorities must play a role in your software design. Paying a hefty future cost is often more attractive than paying an upfront cost.
I'm also not really scared of difficult refactoring, or other code surgery. Sure, two weeks is a lot of time, but is it really a problem? This is a critical piece of code, who knows how long it took you to get this in place the first time.