Java vs PHP for web application decision (again)

[jkon]

The facts: We are talking about a small company (5 persons) with many clients that making real money (we don't) . We provide our own software that has unique features against the e-commerce completion.

The problem: the first glimpse of the problem arose around 2012 and made clear around 2014 with web sockets. Some clients didn't want a simple chat with their client but instead a full live eShop where they could negotiate the prices of a product or even start a discussion with a visitor. The solution would be implementing web sockets in to our framework and that worked , but using incredible resources without any sideway compensation benefits. What that could be ?: 1) we use app scope caching (for object or list of objects) and thought that is done in the memory of the server, each request you have to deserialize / serialize (if there are changes) objects (that is CPU expensive and time consuming , I calculated that it cost almost 2 milliseconds in each response). More over if I have something running along with the app why not having a DB pool where the most common prepared statement persists?

The first solution: Was a new PHP framework that was basically a C++ extension , everything worked fine (almost (if someone interesting I could share more)) (it went in production only in one project). Application scope caching was working with lockers when those objects updated, and we could have a first r&d glimpse in db pooling in PHP. More over it would eliminate DNS lookup since the SPA app would hook to the WebSocket if available or to AJAX if not. (when I am talking about SPA here you would see the same content if you visit a URL for the first time as if you visit it through an inner link).

And then PHP 7.0.2 came: The incontinences of PHP are monumental, but the all thing shattered in the ground. In fact we weren't trying to produce a framework we were trying to produce an application server that would hold that framework. The application server part could be done with more resources and in a specific PHP version, but we don't have the resources nor do we want to bind ourselves to a specific PHP version.

The /lets move back/ moment: There is a language that you can use an application server ,you can share application scope caching objects without deserializing / serializing and also has many add ons for web sockets and more its easy and I have know know it since teenager (no it wasn't my first language) , that language is Java and an application server along with it like Tomcat for example.

The decision is difficult to make , switching to Java , would require rewriting all of our apps , but the two main goals will be achieved (app scope caching , db pool). On the other hand there is a limit to understanding how a JVM is working internally and to write good code for that , using system extensions (example imageMagick).

One plus for Java would be that after that we could share our java code without classes and one serious downside would be that we coudn't write more C++ extensions to make our life easier + faster + more efficient. But to maintain a PHP application server is far more difficult than I first thought.

I would highly appreciate any point of views on that , since I am in a crossroad.

[alan.davies]

This is way above my understanding. Would you be able to host java and php servers e. G. tomcat and apache together? As in port 8080 and 80? Or am I missing the whole point?

[jkon]

Yes you can have apache and tomcat in same servers , you can have them as completly seperate enviroments (in differnt ports), one other option is to manualy set apache forward the request to tomcat (a bit diffucult) but there is also easyapache for cpanel that you can set it to use tomcat (even with autopublish options). Easyapache 3 work with Tomcat 7 but easyapache 4 works with Tomcat 8.5 (till as in experimntal mode). But the problem isn't using the same servers , we could have more servers running only Tomcat (its not really an expensive option these days)

[rproffitt]

This sounds to me that you are vey displeased with how PHP and other frameworks, languages progress over time and what used to work, breaks as they upgrade. I've seen that with JAVA as well as PHP, Python and other systems.

While the new PHP broke your code, repairing what broke should be cheaper (hours invested) than moving to yet another framework or system.

[jwenting]

You may want to start by having a hybrid environment, with both Java and PHP, implementing new projects in Java while maintaining the old ones in PHP for the time being until a change to them is required that warrants a complete rewrite.

That's how we've over the years got rid of (most of) our extensive Perl code base.

[RabidDog5150]

What you might want to have a look at is how you can safely split the application you have built into smaller services. Just because you have changed a language doesn't mean you have to change your persistence store (Database). Isolate services that can safely be transitioned to the new language you use and begin migrating to the new language.

Something else to consider is just rewritting the one aspect of the system that has been negatively affected by PHP. You could also introduce Message Queues etc for inter service communication (PHP changes object that Java needs to know about). If you are going to go the Java route, I would highly recommend investigating Spring Boot and try avoid the larger Enterprise Application Servers.

[jkon]

Thank you all for your answers , some issues in those I have thought some others its great to read them before having to thought them myself. The dilemma here , is if I am trying to make a language behave in a way that is not suppose to , and if the implications of that justify the cost (time and frustrations) given the fact that I am part to a company that has limited recourses. Our experiment proved that is possible to build an application server for PHP with application scope shared objects (without serializing – deserializing) and a descent DB pooling system for each app with native websockets support and all that as C++ extension to PHP, but it also proved how difficult this is to maintain given our recourses and the nature of PHP (that is tremendous instable). I am in a place where I am thinking that this is something above me to create it as stable alternative. That is when Java came. When I first wrote the threading system for that , a thread for each app that has a thread pool incrementing , decrementing by max min limits and usage , and then searched of other implementations of that , I bumped into how Tomcat works (probably WebSphere works the same way but there weren't so many free documents to read). Building that in PHP as a C++ extension with all the failures that came along, my mind stuck to a question “Is it worth it ? Why just not turn to Java altogether ?”

Today we have a framework that is purely in PHP , the impact of it is something of 3 to 7 millisecond in each request , and an undocumented CPU / memory usage. Application scope caching needs to be serialized / deserialized on changes but the plain files of that are stored in memory of each server. Given the fact that non UI images are served through that channel using repository folders , that increases the impact. More over we can't have a descent solution (without using ridiculous mount of resources for doing really simple things) for websockets, and of course we don't have a DB pooling mechanism.

Thank you all for your answers , probably I will give it on more try even if that means sticking to a specific PHP version (7.0.1 for now) , and if that fails again I will gradually move it to Java.

[Trasser]

Java is more promising in all directions.