On your marks

Many developers who end up working on projects that use Drupal see Drupal development as a form of the dark arts. I had worked with Drupal briefly before, I knew I had to work with the ‘Mediator’ pattern — Drupal’s Hooks, but I didn’t know much about the proper usage of Views. Also, there wasn’t a whole lot of documentation available on the rather large (and very messy) existing code base hosted on Acquia Cloud. I knew we would be in for a ride.

Our brief was to redesign in stages, and the first stage — which I am currently in the process of completing and deploying — was to refresh the front page, product listings and individual product pages.

We had front end developers who had never touched Drupal before, and so I started to investigate this ‘decoupled’ thing people seemed to be talking about. Making our Drupal setup act as an API server was an attractive idea, and meant that all front end developers could just focus on writing great front end React code that could simply read off the data exposed by the RESTful API, without worrying about how to implement these changes in the Drupal project.

But this opened up a can of worms. We started to ask how exactly things would fit together. A quote from that last link above:

The cracks are the integration points between the different components. It’s not GraphQL as a communication layer; it’s that no one thinks to log GraphQL inconsistencies when they occur. It’s not “what’s my development environment”, it’s “how do these three development environments work on my localhost at the same time?”. — Campbell Vertesi, Between the Cracks of Decoupled (Drupal) Architecture (11th Feb, 2017)

There were many articles out there about the concept of decoupled Drupal, but you certainly couldn’t just search Kirupa for ‘how to do decoupled drupal 7 with react’. Lynda didn’t give a crap about our dreams.

We had to be originals.