At some point, any enterprise project will probably need a message queue.

A message queue is used to publish information (usually known as messages) that a different "node" (usually known as worker) will consume in order to perform a specific action.

It is frequently used in web applications to pass information to background workers that consume the queue and perform long tasks, but it is also an important part when applying concepts like Event Sourcing to your architecture.

It is also really important when working with microservices, since it is a way to enable data exchange between each service.

Lately, I've been digging a lot in different ways of improving software architecture. Mainly subjects like Clean Architecture, Domain Driven Design, and such.

Those topics cover a lot of advanced and complex practices, but today, I want to talk about a simpler subject. What is the best approach to pass data from outer layers of the application (actions, controllers, async jobs, CLI commands...) to services that are part of the use case layer, by taking advantage of some of the practices promoted by those subjects.

Earlier last week I found a github repository which collects different resources related with PhpStorm. Plugins, themes, utilities...

I found it very interesting, because I think PhpStorm is the best PHP IDE by far, and I've been using it on an almost daily basis for the last 4 years.

The thing is that finding that repository gave me the idea of writing a post explaining the list of third party plugins I use and why, in case somebody is starting to use the IDE and wants some ideas on where to start.

If you want to get any of them, just search for it inside PhpStorm. It's the easiest way to install them.

I think it is doubtless that modern PHP embraces SOLID principles, and therefore, dependency injection.

That's why every modern PHP application needs a dependency injection container to deal with it.

There are several options out there, depending on the way you like to work. Every container has a slightly different approach.

My choice is zend-servicemanager, it is the one that better suits me.

Other containers rely on auto wiring and auto discovery in order to know which dependencies need to be injected on every service, and I think that leads to errors when an application grows.

I like zend-servicemanager because it is explicit, and you are always in control of what's done, without loosing flexibility in the process.

Sometimes the nature of an application requires you to change the default framework's way to structure error responses (like 404 and 405).

On this article I'm going to explain how to customize those responses when working with Zend Expressive 2.

Expressive 1. Error handler.

In Expressive 1, error handling was different.

There used to be an element called error handler, which was responsible of handling uncaught exceptions, but also, other errors, like the ones above (404 and 405).

When using the error handler it was easier to have an standard way to generate error responses for any kind of situation, like unmatched routes (404), routes requested with an incorrect HTTP verb (405) or uncaught exceptions (500), as well as other errors.