Hi. I am a backend developer in a company tasked with recoding a legacy application, choosing the right technology stack, and then later hiring for that stack.
This is a freight/logistics application made 15 years ago in PHP with no modern framework used. In this application, customers from different countries login into theirs accounts and add a huge number of shipments, like let's say 500, and then, later on, generate PDFs for them after calling third-party APIs. This application has API integrations with lots of other companies and also offers API access to its own software as well. This application is also used in-house by warehouse people to scan different shipments using barcode scanners and to process shipments by performing different actions on them. The database being used currently is MySQL.
Now we have the choice to write this application in a modern technology stack. Performance, speed, reliability, and security are the primary concerns here.
Should I go with Java/Spring Boot with AngularJS as the front end or PHP/Laravel with Vue.js as the front end?
Switching at this point from PHP to Java will not be hard if Java is considered better here because we can hire as per our final decision.
Thanks.
First of all, Java can give you definitely better speed, especially at scale. One benefit is that you can tune it for a better response time, and another one is when you'll have millions of requests per day it'll save you some infrastructure cost.
But.. will you have millions of requests a day? How much does it matter if the API response time is 10ms or 50ms?
Rewriting an existing project is a huge deal. It can take years(!), especially if the team hasn't done such a thing yet and especially if the tech stack gets completely replaced.
So I argue against rewrite in the first place. There are two older articles on the topic, but their arguments are both valid as of today: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.jjinux.com/2008/05/joel-on-software-never-rewrite-from.html
What I'd suggest instead is to learn refactoring strategies. Even if you have some routine with refactoring it is worth reading Fowler's refactoring book: https://book-programming.com/refactoring-books/
What I would do with a "frameworkless" PHP codebase is: - Add a framework (I would also go with Laravel, but Symfony or Phalcon would also do the job) - Isolate the existing codebase in a folder if possible without any actual changes - Route the requests through the framework (with a catch-all route) and forward the request to the existing codebase - Take a simple component/page to start with and replace the DB calls using Laravel's DB layer - Doing this "experiment", you'll have a strategy that you can apply to other components - Do the refactoring for views, controllers, etc, step by step - In case you have APIs and other kinds of components apply different strategies - Keep deploying as frequent as possible - Apply the learnings on the run and do pivots if needed
There are many more details to this, but it exceeds the scope of this answer.
About Java: last year I was part of, actually sparking the rewrite of an existing API from Symfony to Java using Spring Boot/JHipster. The bottom line is that it was a bad idea.
We had a separate PM, an Engineering Manager, and a set of developers both Java and PHP, one of the developers highly experienced with the JHipster stack. We've got the support of the CEO, and despite his strong worries, the Head of Software gave it a green light too. After 20 months the old PHP system is still running and - of course - it has more features than the Java one, because life didn't stop, business demanded new features in the live system.
Java and the whole ecosystem are very different, so even if you have people with battlefield experience with it, the complete rewrite is extremely risky.
In my opinion, it's less of a technical than a business decision. I would sit down with the person(s) paying the bill for the refactoring. I would phrase the following questions and elaborate the answer together with them: - What is the problem we want to solve? (maintainability? speed? lack of people understanding the system? security?) - Is the system legacy only technically or also in the meaning "it no longer fits the business' reality"? - What are the expected outcomes of the refactoring? - What is the budget for the new/refactored system? - What is the timeframe allowed for the refactoring/rewrite? - How does the rewrite compare to refactoring, in terms of time, money, and complexity? - What happens with the development of new features during refactoring? - What resources will be assigned to the refactoring project?
+1 about MySQL and Postgres: I've been using both for years now. Both are very capable and very well scalable and can handle hundreds of millions of records. If you already have MySQL, I would not change it (yet). Even if you'd like to change it, postpone the switch after the codebase has been streamlined.
Thank you for your detailed answer. Any way to get in touch with you to discuss this more?
Can you please advise how to get in touch with you using PM?
Hi Chris, please write to budm0fyq8@mozmail.com. This is a disposable email address valid for 48 hours.
Hi Chris, I will suggest going with Laravel and MySQL since the existing system is already in PHP it will help a lot and easier to port out to Laravel and will save a lot of time. Laravel has a very robust mechanism to handle the jobs/Queues and it comes with a lot of features.
Thank you. Keeping aside the fact that the existing system is made in PHP, would you still recommend Laravel over java? Wont java give better performance and speed over Laravel?