I have been maintaining for quite some time a monolithic web app written in vanilla PHP, SQL, CSS, and JS (no frameworks used; no external APIs used; in simple terms, it’s just PHP code querying a MySQL database and returning content formatted as HTML). However, I am planning to split it into backend and frontend (not sure what this architecture/design pattern is called, please let me know) because it is becoming hard to maintain and I want flexibility to be able to use the backend with a mobile app later on.
For this, I’ve decided to make a bakend REST API app using the Laravel PHP framework and a Next.js SPA app for the web client. (Nothing unusual.) The REST API will continue to use the same MySQL/MariaDB server, but the database will have a new data schema incompatible with the current monolithic web app version. Therefore I will need to transform the database while the monolithic app continues to run in production.
I want to do this migration to the new architecture incrementally and be able to run the old monolithic app and the new backend and frontend apps (the new “backend-frontend” architecture) running side by side for as long as possible. At the end of the migration, the old version will be phased out and used only for archival purposes (read-only access).
So far, the best way to tackle this I can think of is to replace the MySQL calls inside the PHP code with HTTP requests to the newly developed API routes. As for the database, as of now, I don’t know of any tools to use to transform it (if you can recommend some, please let me know), so if I don’t find a better way, I will export the data from the old database, transform it to conform to the new table structure manually and then import it into the new database.
Is refactoring the backend code of a monolithic app to make use of a backend API instead of directly accessing a DB the standard and best way to migrate to a backend-frontend architecture or is there a better best practice? Some other ideas that have come to my mind are using triggers, database replication, and views. (However, I am not sure they are a good fit because I believe they will only add more complexity and maintainability overhead.)