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.

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.

My goal is to create the new backend and frontend apps from the ground up implementing the same functionality in them as the monolithic app currently has (basically recreating it as a part of a major refactoring).

I am aware that there is extra overhead in using REST API in PHP. However, in the end, I want to phase out the old monolithic app and keep only the new one once the new one reaches enough maturity, so this overhead won't be that important as the monolithic app would be less and less used by users while the more it's being phased out.

Using the same PHP code for database access is not an option because:

  1. I need to adopt the same ORM in the old app; many of the code constructs used in the new backend app will not be available in the monolithic app because it doesn't make use of the same framework.
  2. There is an increased security risk (as well as maintainability burden) when having both the old monolithic PHP app and the new backend API app access the same database directly (instead of the old monolith relying on the API as the single point of access to the database), especially since there are a lot of security vulnerabilities in the current monolithic app that would need to be patched.

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.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.