For instance, PHP is great for server side frontends. It has great frameworks like Symfony and great templating engines like Twig. While it’s easy to find an alternative to Symfony in the Java world, I couldn’t find anything that’s was as awesome as Twig. (I know there’s Jtwig now — a Twig clone in Java — but it didn’t exist when I was looking for options and it’s still not as evolved as Twig. Yet?)
But PHP is worse than Java when it comes to working with databases. Java has more evolved ORMs like JPA/Hibernate and even higher level abstractions on top of them like Spring Data with its awesome specifications support. Even though Doctrine ORM is a pretty good PHP clone of JPA, it has always lagged years behind the original.
Java also has great database migration tools like Flyway. No one stops me from using command line Flyway in PHP projects — which I do — and that works pretty well. But it’s awkward to call Flyway command line commands from PHP when I need to clear and recreate the empty database before each test. In Java, there’s native integration with Flyway because, well, Flyway is written in Java.
There’s also a difference in how I execute database migrations using Flyway during deployment. With Java, whenever my Spring Boot application boots up, it executes Flyway directly since it’s included in the application JAR. With PHP, I either need to run Flyway during the deployment process itself, or create a cron job that executes Flyway on server boot. Subtle, but still annoying.
The same applies to integrating with Kafka, Elasticsearch, Cassandra, etc. All those systems are written in Java and hence provide native Java clients. Even though there are PHP clients for those systems, they are not as feature rich, natural, and up to date.
Let’s consider Kafka. Whenever a new version of Kafka is released, its respective native Java client becomes available immediately. I just update my Gradle file to get the new version and start using new features immediately.
It’s not that nice and easy with PHP though. I first need to wait for
librdkafka to get updated. And then I need to wait for
php-rdkafka to get updated. Oh, wait, Ubuntu LTS doesn’t have the latest version of
librdkafka. What do I do? Do I upgrade to a non-LTS Ubuntu? Or do I compile the library myself? Hmm…
Oh, and don’t even get me started on how much more natural it is to implement a daemon in Java compared to PHP.
Now, let’s talk about Elasticsearch. The situation with Elasticsearch in PHP is a bit better thanks to the fact that Elasticsearch is basically a REST API for non-Java clients. Hence I can start using new Elasticsearch features whenever they become available.
What about Cassandra? Mm. They do provide a PHP client, right? Right. And, well, it’s good enough to do most things you can do with Cassandra.
What about that awesome object mapper that’s available in the native Java client? That object mapper alone — along with the type safety you get with it — is a very compelling reason to use the Java client. Good fucking luck waiting for that to be available in PHP.
I just scratched the surface here. These systems are far from being the only things that Java is better at.
No Need to Suffer Anymore
Once you upgrade your Internet connection to 500 mbps, going back to 100 mbps is frustrating. Even though you spent years on a 100 mbps connection and were pretty happy with it, it’s still not a pleasant experience to downgrade. Once you get used to something better and then have to give it up for whatever reason, you just can’t stop thinking about how much it sucks to move backwards.
The same applies to getting a lower income than what you got used to. Or getting back to old school taxi service after getting used to Uber. Or downgrading your computer to a less powerful system and suffering from how laggy your favorite software is. Or getting back to the mobile phones that were the norm before the first iPhone. Or getting back to Eclipse or NetBeans after a couple months of using IntelliJ IDEA. I could keep going on and on, but you get the idea.
Since I had experience with both Java and PHP, I had to suffer with whatever each sucked at. Whenever I was doing a PHP monolith, I enjoyed doing the frontend stuff but hated basically everything else. It even resulted in me hating PHP as a whole. And whenever I was doing Java, I enjoyed basically everything except doing the frontend stuff.
I had to put up with suboptimal aspects of each stack just to enjoy the great aspects of them. After having experience with frontend stuff in PHP, I always had this nagging feeling of being less productive and not using the best tool for the frontend job whenever I was working with Java. And after having experience with Java, I had the same feeling whenever I had to use PHP’s subpar database abstractions and the lack of strong typing. It’s like going back from 500 mbps to 100 mbps. I just couldn’t stop thinking about how much more productive I would have been with the other stack.
And then I stumbled upon this idea of microservices. And that’s when my suffering has finally ended.
Now, I have a bunch of microservices working with all those systems that have native Java clients and I can take full advantage of the capabilities they provide. Then I have an internal API gateway that exposes all these microservices as a single unified interface. And then I have a single or multiple PHP frontends consuming that API and that lets me use the best tool for doing frontend that I’m aware of.
I don’t have to pick what I’m going to be suffering from anymore. I can just use whatever is the best tool for a problem at hand. And my satisfaction of software architecting and development is at all-time high now.
P.S. Of course, doing microservices is not the only way to have one stack for the frontend and another stack for the backend. But it’s just one of many advantages microservices bring to the table. I’ll cover more of them in the next posts in the series.