Right now our app is a mess. Everything is mixed together in one big PHP application. The frontend handles UI stuff, business rules, database operations, and basically everything else. It’s becoming really hard to work with and maintain.
We’re thinking about splitting things up. Move the backend logic to Java (which seems like a better fit) and keep the PHP part just for the frontend interface.
I believe the frontend should only handle display logic. Here’s what I’m thinking for rules:
No direct database access from the frontend. Database calls are tricky to scale properly.
Use async communication between frontend and backend. When the frontend needs data, it shouldn’t just sit there waiting. This would let us make multiple requests at once and set timeouts so users don’t wait forever.
Basically I want the frontend to only do UI work and talk to the backend through REST APIs without blocking. Does this sound like a reasonable plan?
Your approach looks solid and matches what most teams are doing now. I did something similar two years back - moved from a Rails monolith to microservices with a React frontend hitting REST APIs. One thing to consider: is REST really the best fit here? GraphQL might be worth a look if your frontend pulls data from multiple sources or you want more flexible queries. That said, REST’s way easier to implement and debug, especially when you’re first splitting things up. For the Java backend - make sure your team actually knows Java well. This migration’s gonna be tough enough without everyone learning a new language at the same time. We thought about switching languages too but stuck with what we knew for round one. Don’t try to do everything at once. Pull out one or two clear business areas to your new Java backend first, leave the rest in PHP for now. Way less risky, and you can nail down your API patterns before going all-in on the new setup.
cool migration! why java specifically? you thought about the pain of running two different stacks? and how big is your codebase - we talking months or years of refactoring? the async approach definitely makes sense though.
you’re overcomplicating this. start by separating the database layer first - keep everything in php but build a proper api layer. once that’s stable, then consider switching languages. jumping to java + new architecture + async patterns all at once will be a debugging nightmare when things break.