What is it?
Included for example in the DurableDrupal Content Migration Rescue Website repo, and free to use with the same license used by Wikipedia, and on this site (the Creative Commons Attribution-ShareAlike License) are a Node.js/Express.js/Mongoose/MongoDB API-first structured content server which exposes that content in a simple REST API (see the
scs folder); a sample Vue.js/Nuxt.js/Vuetify.js based Client Web Application which consumes that REST API (see the
cwa folder); a command-line and yaml/markdown based CMS which allows you to edit your content and send it to the structured content server (see the
cms folder); together with a set of videos which explain in detail each step outlined in the repo Project, broken down into a sequence of atomic commits implementing the requirements outlined in the repo issue queue. The transcript of each video will be published in the repo Wiki.
And this is only the beginning. As soon as the website is up and running, we will publish our first case study, the migration of AwebFactory.com, the project founder’s professional website now running on Drupal 6, to the same decoupled, API-first solution we are sharing here. The steps taken there will also be thoroughly explained and published in the form of a set of videos and a book, to be published on the DurableDrupal Content Migration Rescue Website we are building.
Why do we need it?
Drupal 8, 9, 10… themselves may very well be the ideal solution for many use cases. However, in the case of wishing to go API-first in the form of a decoupled approach, things may get complicated very quickly. Even though Drupal content may be served in the form of a REST API, the need for an asynchronous or otherwise optimized server proxy has proven necessary for actually serving that content in real time. And so on.
And when one turns to lists of other Headless CMS hoping to find enticing alternatives, countless articles by dozens of developers witness the difficulties to be found in sifting through all these choices, both open source and commercial.
We place this project at the service of a growing community of individuals and organizations willing to freely share and contribute to a set of simple, straightforward and transparently organized resources aimed at moving on with our content and web applications in the face of growing complexity and skyrocketing costs, both up-front in commercial form, or else hidden in the often disappointing experience of real adoption.
At the hour of needing to move on to industry standard structured content managed and published on the basis of a decoupled and modern, scalable architecture, more and more we are faced with mystification, buzzwords and the unwillingness of companies born and raised on open source communities to share their solutions.
At the hour of adopting API-first structured content servers, more and more we are faced with the sole option of going behind a “serverless” paywall, which, to add insult to injury, powns our stuff.
At the hour of wanting to spin up client web applications, once again we are chronically placed at the mercy of open source projects made hopelessly chaotic to use due to a mind boggling rate of change as a result, once again, of having individual and community needs chained to the needs of large corporations and their compulsive and often irrational zigzags as they follow, cross-eyed, their own rapidly evolving crises and “opportunities”.
Perhaps by sharing our results in the community, we can turn a difficult and sometimes overwhelming journey into a pleasing, exciting and above all, empowering experience.