A deep, practical tour through every caching layer in Drupal — from the render cache to chained fast backends.
Get it on LeanPub
As I continue working on a Drupal Commerce demo with GatsbyJS, I have moved on towards using GatsbyJS themes. GatsbyJS themes are composable, meaning you can use more than one within a single GatsbyJS application. However, it seems like you really piece together different themes to build out sections of your site.
I finally have my workspace set up, allowing me to begin serving content from one Drupal Commerce API server to three GatsbyJS apps.
Yesterday I made an attempt to use a single GatsbyJS instance to create multiple build outputs. That didn't work out so well. I also realized I was trying to fit a square peg through a round hole. Why fight how GatsbyJS works?
As I continue to fiddle with GatsbyJS, one thing I noticed is that you cannot specify the output directory of the GatsbyJS build. This was requested, implemented, and then reverted in GatsbyJS. In fact, it may never become a feature.
As I have begun working with GatsbyJS once again, I am trying to find a way to work with GatsbyJS and Drupal locally in a somewhat streamlined fashion. Honestly, serving Drupal over PHP's built-in server and using the gatsby develop and gatsby serve command work just fine. But, I love tooling.
I have been tracking down an interesting quirk when parsing JSON:API resources with the Drupal source plugin for GatsbyJS. I have a test environment with the JSON:API Schema module installed and was receiving errors about data in the links property.
The Drupal community has taken to GatsbyJS, the React framework that lets you easily build static (and more) websites (or applications.) And, honestly, this makes a lot of sense. Drupal is a great content management system and it even has ways to create microsites within one installation (thanks to techniques like the Domain module.)
I just freed up 3GB of disk space due to random node_modules directories laying around old projects and experiments on my computer.
The project is called npkill and I found it on Reddit today. I have used disk analysis tools before, but they have made it hard to find small files which eat disk. Yes, Grand Perspective helped me find out I had 15 instances of Chromedriver due to node_modules, due to different open source and client projects. But npkill has helped be truly reclaim my disk.
Comments like these make the Drupal community such an awesome open source ecosystem to work within. Thanks, Mateu ?