Some of you know that I work now as a full stack javascript developer, and I have interacted with a few different projects, both in front-end javascript and in nodejs.

My main concern about javascript has been that, apparently, the community has not adopted one of the practices that, for me, has been the most game changing of all: Dependency Injection.

Take into account that this is my relative point of view, from a community which is still quite new to me, so if you find that something I say makes no sense at all, you are more than welcome to leave a comment.

Current state of DI in JS

At the moment of writing this article, I have made some research, and my feeling is that only very strict object-oriented projects based on Typescript introduce the concept of Dependency Injection.

A couple years ago I wrote a post about how to improve PHP applications performance by using zend-servicemanager lazy services.

In that article I explained how the ServiceManager takes advantage of the proxy design pattern to delay the creation of services, when they are marked as lazy.

That can improve performance if the object is resource consuming, but that is not the only advantage behind proxies.

A use case

Some days ago I was working on a new feature for Shlink, an open source project I maintain.

The feature consisted on adding support to geolocate IP addresses by using GeoLite2, an IP address database which is updated every month.

I have written a lot of posts about Zend Framework in general and Zend Expressive in particular, but I have noticed that I have never talked about one of the things that, from my point of view, makes Expressive so game-changing, Interoperability.

Some context

In the past, PHP frameworks used to be very big libraries, which tried to provide solutions to any possible problem in order to retain users.

At that time, you had to decide which framework you wanted to use, by weighing pros and cons. People ended up saying "I prefer framework foo, because it has a better templating system", "ok, but framework bar has a better performance and its dependency injection approach is delightful".

There's no doubt that having tests in a project allows you to find potential bugs earlier and more easily.

Lots of OSS projects require a minimum code coverage in order to accept new pull requests from contributors, and proprietary projects also tend to have some sort of continuous integration workflow which requires certain metrics to be fulfilled in order to get builds passing.

However, the code coverage can lead to a false sense of security, which makes you think that if certain class has a 100% code coverage, it is also 100% bug-free.

This is not always true, since you could be calling a method and yet not being properly testing its output or its real behavior. The code coverage will mark it as covered, but you might introduce a bug and still have a green test.

A couple hours ago I have released the seventh major version of a module I created more than 4 years ago.

Just released #AcMailer v7! 🎉
Important improvements, with trully stateless services and support for Zend #Expressive.
Adds support for #PHP 7.2 and drops PHP 5. #ZF3 #modulehttps://t.co/AuFXJhnbra

Blog post soon 😀

— Alejandro Celaya (@acelayaa) 9 de diciembre de 2017

It was born as an abstraction to send emails in Zend Framework 2 applications, but trying to make the process simpler than directly working with the lower-level zend/mail component.

I initially created it to use it in my own project, but at some point decided to publish it as a packagist package to ease others to use it.