Deep Dive into Drupal 8 + Gatsby.JS (Part 2)

Nagailic Sergiu (Nikro) — Fri, 04 Jun 2021 10:39:27 +0000

This post was originally posted on my personal / professional blog: Sergiu Nagailic - this is just a part of the full post.

Welcome to 2nd part - hands-on or deep-dive into Drupal 8 + Gatsby.JS. Don’t treat this article as a tutorial - but hopefully, my experience will be useful for your journey.

Who is it for? 🎯

If you’re a beginner that has some experience with Drupal (or even if you’re pretty new to it) - during some 3-4 days, you can have a full-running website, secured, fast, and with zero hosting costs. If you want to experiment, learn something new, create a professional or personal blog, a product landing page, a business website, you name it - then it’s for you.

How much time? ⌚

It really depends on your knowledge and skills. It took me 5-8 days, but I mostly did around 2-3 hours per day (maybe with a weekend spike), that’s why I consider it 3-4 days (full-time). It also depends on the approach and template you’ll choose.

Why? What are the Advantages? Etc. ❓

Most of these things are covered in the 1st article (aka part 1). But, to be short: Decoupled Drupal + Gatsby.JS combo offers a blazing fast website that looks and feels pretty dynamic, with a dynamic admin interface, editing experience, and no server costs, at the same time being able to handle almost any load. Sounds too good to be true? Don’t miss the 1st article then.

If you’re ready - let’s begin 🚀

Initial Setup

Docksal / Docker

We will be using this boilerplate repo - https://github.com/docksal/boilerplate-drupal-gatsby. It consists of Drupal, Gatsby, and Docksal (docksal is similar to pygmy (lagoon), or dd, or docker-compose - but it comes with a handy shell tool that glues everything together).

Note - that I’ll explain everything only from a Linux (Debian-like) perspective as that’s what I’m working with.

Make sure you have the following setup:

Basics - install curl, git; make sure apache / nginx / pygmy, etc isn’t running (this is explained here)

2.Install Docksal - normally if you follow the steps, this should auto-install docker as well.

Okay, now we can clone the repo - i.e. into /var/www/d8gatsby. Make sure you have some free space on the hard-drive and at least 8GB RAM in total - as this will create multiple docker containers.

git clone https://github.com/docksal/boilerplate-drupal-gatsby /var/www/d8gatsby
cd /var/www/d8gatsby
fin start

Okay, you can see things are happening now. To make sure that everything’s fine you can run: fin status - you should get similar output:

      Name                     Command                  State                 Ports           
-----------------------------------------------------------------------------------------------
d8gatsby_cli_1        /opt/startup.sh tail -f /d ...   Up             22/tcp, 3000/tcp, 9000/tcp
d8gatsby_db_1         docker-entrypoint.sh mysqld      Up (healthy)   0.0.0.0:49174->3306/tcp   
d8gatsby_frontend_1   httpd-foreground                 Up             443/tcp, 80/tcp           
d8gatsby_php_1        /opt/startup.sh supervisord      Up             22/tcp, 3000/tcp, 9000/tcp
d8gatsby_preview_1    /opt/startup.sh bash -lc n ...   Up             22/tcp, 3000/tcp, 9000/tcp
d8gatsby_web_1        httpd-foreground                 Up             443/tcp, 80/tcp

If that’s the case - all good. Here’s what each container does:

d8gatsby_cli_1 - this is the CLI container - you interact with Drupal and Gatsby through it;
d8gatsby_db_1 - this is the DB container - with Drupal Database;
d8gatsby_php_1 - this is the PHP container - runs PHP;
d8gatsby_web_1 - this is the web-server - configured to run Drupal;
d8gatsby_frontend_1 - this is the Gatsby container - it’s showing the ‘production’ version of the Gatsby build;
d8gatsby_preview_1 - this is the Gatsby container - it’s showing the ‘dev’ version of the Gatsby build - with ‘live’ changes.

If you’re already familiar with Docksal - this repo adds some extra custom commands - check those out. Also, feel free to explore the .docksal/docksal.yml.

Drupal aka the CMS

Now let’s configure the CMS side - we need to do the following steps:

cd cms
fin composer install
fin composer update

These commands will run composer install and update from within the CLI container. You can now navigate to: http://cms-d8gatsby.docksal/ and you should see an installation wizard for Drupal 8 (Note: the paths and the names of the containers depend on the folder name). I have chosen a Normal installation profile (not minimal) - so we can reuse the default defined fields and content-types.

By the way, you can also run fin init, instead of doing the wizard and all the following steps - and this will automatically install everything and wire things between them, but you will end up with an exact Umami installation profile and gatsby.js theme (like in the README file of the repo). This is not what I intend - instead, I want us to build our custom Gatsby theme and configure things manually - so don’t run fin init.

During installation - specify these details (default docksal mysql details):

Database name: default
Database username: user
Database password: user
Host: db

Don’t worry about production settings, these are temporary and only for local development (defined under settings.local.php).

Once you’re done, you have to see a fully installed Drupal 8 instance:

Gatsby.JS aka Frontend

Let’s leave the CMS at this point and focus our attention on the Gatsby.JS (frontend) side.
Because we have deliberately chosen not to go with the default setup - building the frontend as-is - will fail, but let’s see how it fails:

cd ../frontend
fin fe/code-init

This will initialize the code (run npm install, etc). And after, this we run the build command to build it: fin fe/build

You will see that it will fail - because currently our CMS doesn’t have any extra module installed, but the current Gatsby setup tries to query the JSON API and fails with http error message - 404.

Don’t worry, we’ll remedy this in a section below when we’ll be building our custom Gatsby ‘theme’.

To sum-up: Drupal’s up and running, Docksal is up and running too, Gatsby isn’t but that’s what we’ll have to work on - we’re good to continue…

That was a part of the full tutorial, full post covers:

Basics (of Gatsby.JS)
Structure (file / folder structure)
"Theme" setup
Drupal Setup & Bridge
GraphQL - query data
Putting it all together...
Deployment - going live

Read the full post 👉

Hey, I'm new here, any suggestions / criticism is highly appreciated.

From Drupal 7 to Drupal 8 + Gatsby.JS

Nagailic Sergiu (Nikro) — Tue, 01 Jun 2021 08:42:42 +0000

This post was originally posted on my personal / professional blog: Sergiu Nagailic - this is just a part of the full post.

Blog running on Drupal 7 (or any other CMS)

Running a self-hosted blog has its challenges - and I bumped into some of those eventually. Well, rather than running out of ideas / motivation or time to come up with new articles, I eventually had some technical problems: Updates & Security - being the most important one 🔑 👾.

If you’re using a self-hosted blog, you eventually will need to do constant updates. The more popular engine you’re using - the more risks of being hacked and the more up-to-date you have to be (especially if you’re running on Wordpress). I am kinda lazy, so eventually I skipped some big updates and my hosting got hacked. And this happened many times.

Many hacking waves are automated - they just crawl the web, identify Drupal websites and try commonly known exploits on them (that are documented everywhere), and if you’re not up-to-date, they breach-in. You can leave it hacked - but eventually someone will sell access to your hosting on the black-market and some shady things will start happening - in my cases I had some websites popping up on my VPS (I used DigitalOcean VPS) - and after making a backup of my website, I had enormous pleasure of destroying the Droplet with all the weird websites it had on it.

In modern days, there are ways one can automate this process, in example:

use something like Pantheon - it comes with automatic core updates, however this still leaves room for contributed modules or plugins if you’re using Wordpress, which can also act as an attack vector
use a CI tool, like CircleCI or Github Actions - you can have regular tasks that run daily, i.e. have proper Core Updates and Contributed Module Updates, maybe even run tests and if all goes well to deploy to production.
something simpler but riskier would be - to have a cronjob that just runs updates directly on production - but you never know what will happen. Normally you want to test things first on your local environment and then replicate things on production.

However, to me, these options are way overkill - I don’t want to pay extra for Pantheon, nor I want to write a CircleCI (or Github Actions) script or a crontab + shell script. Also I don’t want to constantly run updates locally and then deploy those (that’s why I got hacked in first place).

Also, other than CMS’s vulnerabilities, there are also PHP’s vulnerabilities, Apache/Nginx’s vulnerabilities, ssh vulnerabilities - so you’d have to update the operating system itself and all the packages, then restart nginx, php-fpm, mysql and hope for the best.

That's an introduction into the main post, more in this post:

Advantages of Headless Drupal + Static Front
Gatsby.JS
Migration Process (with all the steps)
Outcome