How to Kill a Giant
Branislav Bujisic
Drupal 7 has been there so long, and it offered us unprecedented flexibility to build some pretty huge projects -- special kind of beasts that have nothing to do with the original "Drupal-as-a-CMS" paradigm. Think about Drupal sites that behave as OAuth2 servers; or sell content access, or prorate prices and bill them monthly; or news portals that are also exposing the API's for popular mobile apps; or membership databases of really big organizations. Sometimes, these projects would be so big and so crucial to our businesses that there would simply be too much disruption if they went offline.
But Drupal 7 is getting closer to its end of life. We have good migration scenarios for most of the use cases. However, the above giants are marginal cases which cannot simply be migrated to Drupal 8. And even if they could — that may result in building a new giant which would have to be killed once again at Drupal 8's end of life. Sometimes, a transition to something service-oriented may make more sense.
This session suggests a strangler application pattern in a Drupal 7 project. Martin Fowler describes the strangler application as “…a new system around the edges of the old, letting it grow slowly over several years until the old system is strangled”. In our PHP/Drupal realm, that means:
decoupling the frontend of a Drupal 7 project;
placing a middleware API proxy between the frontend and Drupal;
finally replacing individual parts of the old system with the newly developed ones
This approach promises zero downtime and makes no assumptions on what will be the resulting tech stack. The decoupled frontend can be a GatsbyJS project, or a React app, or even a static HTML served from the middleware. And the middleware itself can be a NodeJS/Express app, or a Golang API proxy, or something third. The backend can be replaced with a Drupal 8 monolith, or multiple Drupal 8 projects, or with a full-blown microservice architecture.
The sweetest part of the pattern is that even if you make an error in the architecture of your backend, which will require serious refactoring, you will be able to correct it without a downtime.
https://2019.badcamp.org/session/how-kill-giant
Drupal 7 has been there so long, and it offered us unprecedented flexibility to build some pretty huge projects -- special kind of beasts that have nothing to do with the original "Drupal-as-a-CMS" paradigm. Think about Drupal sites that behave as OAuth2 servers; or sell content access, or prorate prices and bill them monthly; or news portals that are also exposing the API's for popular mobile apps; or membership databases of really big organizations. Sometimes, these projects would be so big and so crucial to our businesses that there would simply be too much disruption if they went offline.
But Drupal 7 is getting closer to its end of life. We have good migration scenarios for most of the use cases. However, the above giants are marginal cases which cannot simply be migrated to Drupal 8. And even if they could — that may result in building a new giant which would have to be killed once again at Drupal 8's end of life. Sometimes, a transition to something service-oriented may make more sense.
This session suggests a strangler application pattern in a Drupal 7 project. Martin Fowler describes the strangler application as “…a new system around the edges of the old, letting it grow slowly over several years until the old system is strangled”. In our PHP/Drupal realm, that means:
decoupling the frontend of a Drupal 7 project;
placing a middleware API proxy between the frontend and Drupal;
finally replacing individual parts of the old system with the newly developed ones
This approach promises zero downtime and makes no assumptions on what will be the resulting tech stack. The decoupled frontend can be a GatsbyJS project, or a React app, or even a static HTML served from the middleware. And the middleware itself can be a NodeJS/Express app, or a Golang API proxy, or something third. The backend can be replaced with a Drupal 8 monolith, or multiple Drupal 8 projects, or with a full-blown microservice architecture.
The sweetest part of the pattern is that even if you make an error in the architecture of your backend, which will require serious refactoring, you will be able to correct it without a downtime.
https://2019.badcamp.org/session/how-kill-giant