
Software in place of architecture
Often, developers will seek to rectify a system's architectural issues at the software development level. While this has use cases, I am a huge fan of seeking to avoid this practice where it is not necessary. Moving issues from the software architecture layer to the infrastructure layer has its advantages.
For example, suppose you need to proxy a request for a particular URL endpoint off to another server. I believe this is best done at the web server level as opposed to writing a PHP proxy script. Apache and Nginx can both handle reverse proxying, but writing a library to do this may mean you come up against several unheard issues. Have you thought you that you'll handle HTTP PUT
/DELETE
requests? What about error handling? Assuming you nail your library, what about performance? Can a PHP proxy script really be faster than a web server level proxy, utilizing a web server written in a low-level systems engineering language? Surely one or two lines in your web server configuration is far easier to implement that an entire proxy script in PHP?
Here's an example of just how easy it is to create a proxy in a VirtualHost. The following configuration as an Apache VirtualHost will allow you to reroute everything from test.local/api
to api.local
(it's even easier in Nginx):
<VirtualHost *:80> ServerName test.local DocumentRoot /var/www/html/ ProxyPass /api http://api.local ProxyPassReverse /api http://api.local </VirtualHost>
This is far easier to maintain than thousands of lines of code in a PHP library that imitates something that is already available in the ProxyPass Apache module.
I've heard a criticism of microservices that they seek to move problems from the software development layer to the infrastructure layer, but are we really saying that that's always a bad thing?
Yes, software developers have a vested interest in doing things at the software development layer, but it is often worth educating yourself about the functionality you have available higher up the chain and seeing if that can rectify any issues you are having.
Think in terms of Occam's razor: the shortest solution is often the best, as it is translated literally "more things should not be used than are necessary."