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.
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.
In a project I'm working on, we recently needed to add some kind of encryption system that allowed us to store sensitive information in a secure manner, but being able to access to it at runtime in order to pass it to third party services.
Securely storing your own app passwords is easy. You just hash it, and the password can be verified without having to decrypt it, but if you need to "decrypt" it, the solution is not that easy.
We started by building our own solution based on zend/crypt, which is an excellent solution and works like a charm, but you still need to store the master key somehow, and that's the big problem.
Recently I have been testing one service and its clustering capabilities, in order to see if it fits in a project I'm working on.
I decided the easiest way to do this was by creating a couple docker containers and setting up a cluster between them. It should be an easy task in theory.
My first approach was using a docker-compose file and linking the containers between themselves:
version: '3' services: test_1: container_name: test_1 image: some:image links: - test_2 - test_3 test_2: container_name: test_2 image: some:image links: - test_1 - test_3 test_3: container_name: test_3 image: some:image links: - test_1 - test_2
The day Zend Expressive 2 was released I was super excited. I have been using it a lot for both professional and personal projects, so I'm quite used to it.
Since I've been using it in many projects, being able to update all of them to version 2 was a challenge, but I can say, I have succeed :-)
When I migrated my website to expressive, I had to create a custom router for backward compatibility reasons, because none of the provided implementations supports optional params at the beginning of the path, and I was using them.