From PHP to React, then to Express. A gradual migration when you can't switch all at once (part 2)
Two tangled PHP projects couldn't be rewritten in one go. I attached React screens through iframes, shrank PHP into an API, and moved only what I needed to Express.
#PHP #React #Express #Migration
Previous post: https://blog.jaeyonging.com/en/blog/50 In the previous post I wrote about why I decided to move a project built with PHP + HTML over to React + Express. That was the decision, but once I actually got my hands on it, reality wasn't that simple. This post is a record of how I moved it over a little at a time. There were two projects tangled together The service I was in charge of was two PHP projects running tangled up with each other . The admin pages, the user pages, and the files inside them that pulled each other in with include were all intertwined, so tearing it all out and replacing it with React in one go was impossible . There was a lot of code and the structure was knotted, so if I touched the wrong thing there was no telling where it would blow up. On top of that, the service had to keep running. It wasn't something I could stop for a few weeks because of a migration. So I started with iframes Early on, I built the games, the video content and some of the functional pages in React first, and attached them by embedding them into the PHP pages with an iframe . I uploaded the built React output as static files and loaded it from the PHP page like this. iframe src="/static/react-built-game/index.html?id=123" width="100%" height="600px" /iframe This was nice because I could build UI quickly in React, but sharing state with the server was hard, and without postMessage it was hard to even talk to the outer page. Just passing along the login info had to be handled separately through a query string or postMessage. In the end this was a stopgap, and the goal was to move the whole thing to React. I wrote a separate post on how I passed messages between the iframe and React. Starting to swap things out for React completely I started moving the features I had attached through iframes into React, one at a time. The existing PHP no longer drew the screens. I changed it to act like an API server that hands React the data it needs as JSON . For a while the work was stripping the HTML out of the PHP files that used to build screens and making them return only data with json_encode. Along the way, I could see which APIs I needed As I moved the structure over to React, it became clear which APIs were needed and what data went back and forth. When PHP drew the screens, query results were printed straight into the HTML, so I never had to sort out "what data does this screen need". Once React became the side requesting the data, that list fell out on its own. Only then could I narrow it down to just the APIs that needed to move to Express. I didn't try to change everything from the start. I picked only the APIs that were really needed and moved those to Express. As a result, I could move things over in order, starting with the core features, while the service stayed up and running the whole time. This is how it ended up PHP gradually shrank into the role of a data provider The React features I had attached through iframes were all merged into the SPA I started adding Express from the parts that really needed it, and now almost all of the APIs run on Express + MySQL To sum up In a situation like this, ripping everything out from the start would have been the riskier choice. My judgment wasn't "this has to go to React no matter what". It was that moving to React step by step, starting with the areas that could be converted, was the more stable way . And because I kept shrinking PHP's role bit by bit and rebuilt only the APIs I needed in Express, the migration was possible without stopping the service. If you're in a similar situation, rather than waiting for the day you can tear it all down, I'd recommend moving whatever you can move right now, with an iframe or anything else. What I regret now I think the gradual migration was a good choice in itself. The problem was that I never decided when it would end . If you start with "change what can be changed first", the things that can't be changed just stay. A few admin screens ended up remaining in PHP, and they still are. They weren't urgent, so they got pushed back every time. When I started the migration, I wish I had first written down this much gets moved and the rest doesn't . Then what's left would have been "things I decided not to move" instead of "things I couldn't move", but as it is, it bothers me every time I see it.