An Introduction to Static Site Generators for Drupalists and Static Site Show and Tell

- [Brian] Everybody, welcome to

an introduction to static site
generators for Drupalists.

So you're in the right place.

I will keep this short because I've,

you may have already heard from me

in some capacity at this camp.

But I'm Brian Perry.

I like components,

the JAMStack,

which we'll be talking
about a little bit today,

and Nintendo.

I'm on the internet in a bunch of places

and would love to internet with you.

And I work for a company called Bounteous

with a bunch of great Drupal folks.

Drupal is one of a handful
of things that we do.

The most important thing that I'll mention

is that we do have an open
listing for an architect role.

So I'd love to work with you

if that's the sort of
thing you'd want to do.

But, let's jump in and talk
about static site generators.

So give a little bit of an overview.

But just a quick mega-informal poll.

Like who has used a static
site generator before?

Awesome, of you people
who raised your hands,

how many of you have used it
with Drupal in some capacity?

Okay cool, great.

So it should be something
interesting for almost everyone.

And if not, there's this.

(audience laughing)

So let's talk about what
a static site actually is.

This is the Space Jam website.

Thankfully, recently there have been no

new negative connotations
with the movie Space Jam.

But we can still use it as a great example

of the static site.

Maybe there was some sort of rudimentary

CMS like thing that this
site was built with.

But I bet it was probably just
painstakingly coded by hand.

So you can get your super
awesome Space Jam wav files.

But it's definitely a static site now.

Just HTML and CSS.

This is the Captain
Marvel website recently,

which is also really awesome.

I poked around at it to try to figure out

if it was really static.

I wouldn't have been
shocked if I looked at it

and it's like React that does all this.

(audience laughing)

But I don't think it is.

There is some JavaScript.

But it does feel like it's
mostly static and prebuilt.

But nonetheless, a cool little site.

But no, all static sites
don't have to look like this.

This is another example of a static site.

This is the React documentation,

which happens to be a Gatsby project.

So all of the docs are
generated statically.

And then another example of

something that happens
to be a Gatsby project,

that's just a great
example is outrider.org.

And this kind of, you know,

makes you think a little bit differently

about what static might be.

This is a really cool, animated,

really fluid and responsive site

where a lot of what you get

is a pre-generated static bundle.

I think there's a couple of places where

it might reach out to an API

and rehydrate some of the app.

But this static site
doesn't have to look like

the Space Jam website.

So now that we know what a static site is,

although I'm sure we all did,

we can talk about what a
static site generator is.

So it's a tool that generates
a static build of your site,

HTML, CSS, maybe JavaScript,

based on some raw data
source that you give it.

And that data source is often markdown.

But it could be a whole
host of other things,

like a database, an API, a CSV,

some data source that you create yourself.

And it usually makes use of
some sort of templating engine

so that you can format the data

as it's passed through
the static site generator.

And because the end
result is static assets,

you don't really require
the larger LAMP stack

that we might be familiar
with as Drupal people.

And you can host it pretty much anywhere.

If you can't post static HTML,

is it really a web host, I don't know.

Existential question.

A lot of tons of different projects,

a lot of really popular projects.

Jekyll is kind of the big
grandfather of them all.

Hugo and Hexo are popular.

Gatsby is really popular
in the Drupal community.

I mean even got somebody
wearing Gatsby clothes so.

But there's tons of 'em.

So talking about some of the
advantages to a static site.

Speed is one of them.

Browsers are great at
rendering static HTML.

You can put it on a CDN
so it can be distributed,

and delivered fast

to the people that are
going to your website.

There's advantages from
a security perspective

because your data only needs
to exist at build time.

So it doesn't have to be
available all the time.

It could be password
protected behind a firewall,

or just literally totally spun down.

And we talked a little
bit about the stack.

It's a lot easier to scale,

and a lot cheaper to
host these static assets.

And then depending a little bit maybe

on the tool that you're using,

there can be some improvements
in developer experience.

You don't have to have a full VM pull-down

and sync a database file to be able to get

a build up and running.

And then you might be wondering, you know,

I like Drupal.

We all love Drupal most likely here,

or maybe we're trying to
infiltrate the community

in some weird way, but.

(audience laughing)

So why would you use a static
site generator with Drupal?

I like to think about all
the effort that we go through

to make our Drupal sites like static-like,

so that when they're being rendered,

they're as close to static as possible.

Think about varnish, and memcache,

and the layers and layers of caching

that we have within Drupal.

It's a lot of work when in some cases,

we might actually just
be able to always have

something that's static.

Think about the next security update.

There was one Wednesday

while I was in the training, for example.

And you know, this might change
the game a little bit here

in that you don't necessarily
have to have your Drupal

CMS available all the time

just to build or, you know,

password protect.

It's only content editors
that are looking at it.

Impact on hosting.

And then the last one
is kind of interesting

and maybe a little
counterintuitive with this audience

'cause I know that we have
things that we want to improve

in Drupal's admin UI.

But it's still a really solid
content editing experience,

especially compared with
like not having one at all,

or editing markdown files.

So it can be a major advantage.

All right, so we're gonna,

everybody still doing good?

All right, so we're gonna look at

the static site generator landscape

from a Drupal perspective,

specifically through the
lens of three projects.

And again, there are billions of them.

But I feel like this is
a nice little sampling

of projects that all have their

little slightly different
twists on static sites.

So the first one we'll
talk about is Jekyll.

And Jekyll, it was
definitely the first project

that introduced me to this modern take

on static site generators.

I'm sure there's older ones.

But it's a Ruby project.

It uses a templating engine called Liquid.

Typically the data is gonna be markdown.

Most of what Jekyll expects
is markdown coming through it.

But it can look at YAML,

and JSON,

CSV data sources.

It also kinda introduced
me to the concept of having

content in version control.

So you have your markdown
content potentially committed

so that it's in source control

rather than in your database.

It's supported natively by GitHub Pages,

which I think really
helped its popularity.

It also supports incremental builds.

And not all of these tools do.

So incremental builds,

it's only going to when
it does the build process,

look at the stuff that has changed

rather than going through
all of the content

to create a new build.

And yeah, it's super-duper popular.

So Jekyll certainly is
not the one that I use

the most recently.

But just to go through a
few things at a high level.

Here's what data is gonna look like.

This is actually just an example

when you spin up a
default Jekyll instance.

But it's markdown.

So there's front matter at the top.

And a few of those things
are kind of Jekyll specific,

like the layout.

And then it's just markdown

that you probably are
already familiar with.

There's a few things that
Jekyll can do in there

that are specific to Jekyll,

like the code snippet
highlighting and stuff like that.

But it's valid markdown and
HTML can be valid markdown.

So there's a lot of stuff
that can be in these spots.

And then templating, it's Liquid.

Even if you haven't used
this templating engine,

I would think that it's probably gonna be

reasonable for you to work with

if you're familiar with
other templating engines.

It also even looks reminiscent
to Twig in some ways.

So while there's a few
little bells and whistles

that you'll have to become familiar with,

it's probably something you
can work your way around.

And then talking about
using Jekyll with Drupal.

From my experience,

there really aren't a lot
of kind of formal options

with Drupal 8.

Jekyll has this concept of importers.

And there are importers
for Drupal 6 and 7,

but not like a final
finished version for Drupal 8

that I could find.

And what those do,

they look at the Drupal database

and basically export a
bunch of stuff as markdown

that you can then feed into Jekyll.

So if you wanted to use Jekyll,

then what would you do?

So any way that you can get your data

out of your Drupal site
as flat files would work.

Also you could do things like

a CSV views data export to
get your data into something

that Jekyll could read.

It could read in RSS feeds.

That might be another way to
get that data into Jekyll.

And then you could also put like any YAML,

or JSON, or CSV data
in the data directory.

So there's a lot of ways to do it.

But really not as many
kind of prepackaged,

ready to go with Drupal ways

when compared to some of the other things

that we'll look at.

And then, this is a really
simple like demo example

that I put together.

Very little effort into
it on the theming side.

But uses the data from
the Umami demo profile.

Gets that into Jekyll,

and just has a static
list of all the posts.

And you can drill into the
details of all the posts.

And it's nice, fast HTML.

So thinking about Jekyll,

Jekyll might be for you if you want

a simple, road-tested option.

You want your content in version control.

Although, that's maybe
less specific to Jekyll

now that I read that out loud.

But markdown and flat file data

is practical for you.

And you also have to not hate Ruby.

(audience laughing)

So this slide with additional resources.

Mainly if you could hear for the video,

and also the slide deck is up online.

But the Jekyll docs are great.

Mediacurrent has a blog post.

I believe their still current
version of their site is

a Jekyll and Drupal project.

And there are some
similar projects as well.

Hexo is a Node static site generator.

Hugo as in go.

It's supposedly super fast.

And Eleventy is another Node generator

that's really stripped down

and simplified as I understand it.

But I've been hearing a
lot about it recently.

So on to Gatsby,

which is great because
this is covering for

a Gatsby section.

And maybe some people
came here just for Gatsby.

But Gatsby, the way they
pitch themselves now is

it's used to build blazing fast

apps and websites with React.

And they've kind of
changed their positioning.

They used to actually talk about

using it as a static site generator.

But now they focus on
the fact that it's React.

And it's also just an easy way

to create a performant React app.

So it's a React project.

Templating, which is a
little bit loaded of a term

here with Gatsby.

We'll look at that.

But it uses JSX because it's React.

Gatsby uses GraphQL to query the data

that you're importing into the system.

It has a thriving plugin ecosystem.

So that could be like actual React plugins

that you're gonna use on your site.

Things like, you know,

CSS and JS styling
options, other libraries.

But also they have the
concept of source plugins.

So it's possible to have

easily configurable plugins to get data

from a variety of data sources.

You can even use them together.

There's a Drupal plugin.

There's a Wordpress plugin.

There's probably plugins
for many of the things

that you're looking for.

And it's really, really fast.

It does preloading

using what is called the
PRPL Pattern I believe.

But it preloads based on like links

that are about to go into the viewport

and a bunch of fancy
things like that so that

oftentimes when you click on a link,

the data has actually already been loaded

on the client side,

and it's instant,

to the point where

if you haven't actually clicked around

and tried out a Gatsby
site, definitely do it.

But the first time that I did it,

it was like so fast that it was like

kind of weirdly off-putting.

Like websites aren't
supposed to be like this.

(audience laughing)

And it's not just for static sites.

So it's React.

So you can statically
build a bunch of routes

and then have other portions of the app

that still hit an API
and rehydrate as needed.

So a little bit about
installing and running Gatsby.

So it's a Node project.

So you'll require it in your package JSON.

And then you can run npx gatsby new

and then the name of your project.

That's how they recommend you do it now

in the latest version of NPM.

You could also install,

they have like a global
version of the Gatsby package

that a lot of us might be
familiar with that approach.

And then in your project,

you can run npm run develop.

And that's gonna launch
a little local web server

that does hot reloading

so you can see your
changes reflected instantly

in your web browser when you make them.

And then you can create a production build

by running npm run build.

So that's gonna create a
production optimized bundle

that you can then host somewhere.

And you could run npm run serve.

And that will actually
allow you to test out

and tinker around with your
production build locally.

And you should definitely do that.

I have been bit by not doing that.

Sometimes there are problems

and you shouldn't put them up on hosting

until you've worked at them.

Or, there's also the concept of starters.

They have a bunch of starters.

Some of those have like
elements of themes.

So a particular look and feel.

Some of them are configured to work

with certain data sources.

So there's like a,

there's a Drupal starter now.

There's a blog starter.

There's, you know, baseline starters,

portfolio starters,

all kinds of stuff like that.

So it's another place you can start.

So talking about data,

for Gatsby it actually can be
a handful of different things.

So it could just be a React component

that's in your source pages directory.

So this is actually just
gonna render out, you know,

it's a default example from
the kind of default starter

that just renders out a
basic page with a heading

that says hi.

And then you can have other
pages that link to each other

in the pages directory.

More interesting,

you can deal with data from other sources,

like markdown from the file system.

So this is gatsby-config.js

which allows you to
configure these plugins

along with a handful of other things.

So it's saying that we're going to use

gatsby-source-filesystem
as a plugin to get stuff

from a directory in the file system.

And then it's using the
gatsby-transformer-remark plugin

to parse the markdown data.

So you can do some cool
stuff like have teasers,

and renderings of the markdown data,

and all kinds of stuff like that.

And a lot of other Gatsby plugins

assume that you're using markdown.

So if you can get your data
to be markdown in some way,

there's a bunch of other cool things

that you can do with a plugin ecosystem.

And then your queries to
get your data are GraphQL,

as I mentioned before.

So this is Graphi-cool, GraphiQL.

I still don't know how
to actually say that,

but it's a really cool browser tool

which lets you construct GraphQL
queries and see the result.

And as somebody who was new to GraphQL,

I probably wouldn't have
been able to get anywhere

without having this.

But it has built in documentation,

and you can preview your queries,

and then add them to your components.

And it also lets you kinda
see the structure of things.

So you can see the structure of your data

after it's brought in through
Drupal for example here.

And then on the templating side,

you know, templating's in
kind of air quotes here

'cause there's a lot going on.

It's at the end of the
day a React component.

But there is, you know, JSX
that renders out the data here.

So this is from the using Drupal example

in the Gatsby mono repo.

So it's rendering out all of the recipes

from the Umami demo data.

But also at the bottom of the component,

there's this GraphQL query that's defined.

And that, you know,

based on what we saw before

is getting all of the recipes
from our Umami demo data.

And that's the data that's
available to your component

that you can then spit out on the page.

And because you defined
those queries and events

it can build things statically

and make things super fast.

And then using Gatsby with Drupal.

There is a gatsby-source-drupal plugin

that works with the JSON API module.

So you have to have JSON API exposed.

And then in your Gatsby config,

you can specify what the
base URL of your API is.

And then the plugin at build time,

it goes and hits the API,

crawls everything,

and brings all of your
data into Gatsby's API

so you can query it.

And it does a bunch of cool
stuff at the same time.

Like it can handle reference entities

for things like images.

It takes the image from Drupal
and makes a local copy of it

so you're not referencing
the Drupal sites.

Everything's part of that static build.

You can pass it through some of the

image manipulation
plugins that Gatsby has.

But yeah, at the end of the day,

you get all of the data from Drupal

query-able in GraphQL.

And then this is again from that

using Drupal demo in the mono repo.

Just a different representation
of the Umami demo data

in a nice fast Gatsby setting.

So Gatsby might be for you if

you prioritize performance,

you like React,

you want flexibility in your data sources.

And you know that's also true

of potentially something like Jekyll

or some of these other options.

But the way that everything
is kind of combined together

in that GraphQL schema

opens up some interesting possibilities.

And as I understand it,

there were also some
new features in Gatsby

that let you kind of
modify the GraphQL schema

so that you can kind of normalize data

from different data sources.

So there's a lot of power there.

You want to use GraphQL to
have control on the front end

of the data that's available
to your components.

And also it's a great option

if you want to go beyond static.

So maybe part of your app is static

and then there's some typical
React fanciness beyond that.

So the resources,

the Gatsby docs are great.

There are so many tutorials,

and blog posts,

and talks in the Drupal
world about Gatsby and Drupal

that I'm not even gonna try to list them

or one specific one.

Recently, the Boina folks

released a Drupal starter
and a Drupal distribution.

It's definitely worth taking a look at.

Benji, who's kicking
around here at this camp

also created a Lando Gatsby
Drupal development environment.

So that's worth checking out too.

And then the gatsby-remark-drupal plugin,

it kinda ties into the starter
and distribution up above.

But I think that's really cool.

And if you're working
with Gatsby and Drupal

and haven't played around with,

that's worth taking a look at.

It lets you process data
from like a body field

on a Drupal node as markdown.

So it again lets you get into

some of those markdown super
powers that Gatsby has.

And there are a number of similar projects

that are trying to be Gatsby.

Well Gridsome is the one
that's trying to be Gatsby.

The other ones are static site
options in other frameworks.

And also,

you might be interested in
the Quicklink Drupal module.

Mike Herchel from Lullabot
released this module recently.

It uses a Google library

that does a lot of that same preloading

that Gatsby does out of the box.

And you can just use it
with a regular Drupal site.

So if what you want is the
incredibly fast-feeling website,

definitely take a look at that.

Okay, last one we're
gonna focus on is Tome.

So Tome is interesting
because it's a Drupal project.

It's a static site generator for Drupal 8.

And it's gonna generate a static site

that looks like your Drupal site.

And it also exports and
imports your content as JSON.

So you can also use it to
easily import and export

content across different environments.

It does support incremental builds

along with a bunch of other nice features.

Samuel, who's the kind
of lead on this project,

has really been putting
a lot of time and effort

and doing some cool stuff with this.

So installing and running Tome.

This is from the getting started guide.

And I definitely encourage you
if you're interested in Tome

to walk through it.

It's really quick.

But there's a default
project you can start with.

And then composer install.

And at that point you
can run drush tome init

which will do an install
and export your content.

And then at that point, you know,

this getting started actually uses like

a local SQLite database.

So you can just run a
little web server here.

But you can go in and edit content

and see that the content is added into

the slash content directory.

JSON files, images,

all kinds of stuff like that.

And then at that point, if
you run drush tome install,

it's just gonna wipe out
your entire instance,

reinstall based on all the content

that you have exported.

And then you can run drush
tome static and it just

in an HTML directory,

I forgot what the default
actually is called,

it just creates a static
build of your Drupal site.

And you can also install
into an existing project,

require tome, tome drush I believe.

There's documentation on
the project page for that.

So the data that tome deals
with and looks at is JSON.

So it's just a big JSON file

with a bunch of fun Drupal
uuids all over the place.

(audience laughing)

But even beyond this,

it opens up some interesting possibilities

and that you could use
this data outside of Tome

if you wanted to.

And then it's Drupal.

So the templating is Twig,

which you know and perhaps love.

And then the output is gonna
be what you see in Drupal.

There are certainly some cases
where there might be things

in your Drupal site by default

don't make sense for a static site.

So maybe you have to
turn those things off.

But the whole idea is that, you know,

you look at things in Drupal,

and your static build
is the exact same thing.

So Tome might be for you

if you want to keep using

the tools that you know
and love with Drupal,

but you want a static site.

You want your Drupal content
under version control,

or available as static
files somewhere else.

Another cool use case for this
is archiving a Drupal 8 site.

You know, maybe that's down the line.

But a site that maybe
you want to take offline,

the content's not gonna change,

but you still want the
actual static content

to live somewhere.

That's awesome.

And then yeah,

so you want to use this flat
file data in another system.

But definitely give it a spin.

The docs are great.

The getting started
walkthrough is really awesome.

Try it out with your
site, see what happens.

I'm sure they'd love to have issues

about things that it can
or can't handle well.

There are some similar Drupal projects

that also aim to give you a static site.

Okay so

last couple things to talk about is,

one is automating deployments.

So perhaps you've found a good
use case for a static site

and you're using it with Drupal.

But how does it work
when I change my content?

- [Siri] Sorry, I can't
search the web on Apple Watch.

- [Brian] No, go away Siri.

(audience laughing)

Oh my God.

So you update your content in Drupal.

Then what happens?

By default, nothing.

But how would we deploy this somewhere?

So you could run your build process

and then just commit that
output and post it somewhere.

So you know, put it up on your host,

deploy it to GitHub Pages.

That's what I currently
do for my personal site.

Then there's other hosting options

that play nice with static sites.

Things like Netlify.

That's the one that I've used.

So they have options to be able to

deploy when there's a commit
on a particular branch.

And it knows how to work with Gatsby

and other static site generators.

So if there's a commit,

it's gonna run Gatsby's build process

and take the assets and host it somewhere

where you can review,

and then promote to production.

And then on the Drupal side,

you can also trigger a
build with a webhook.

There's a bunch of different
options for doing this.

This is the webhook module.

There's also a build hooks module

that was released recently
to do similar things.

It's also not that hard to
write custom code to do this.

But Netlify, for example,

has the concept of a webhook.

You can post to it to trigger
a build on a specific branch.

So you can say when a
certain node is updated,

then it triggers the build hook.

So then, for example if
you have a Gatsby site,

it's gonna look at all of your data,

do a new build,

and then that's automatically deployed

and ready for you to review,
which is pretty cool.

And then Tome has some nice
Netlify integration as well.

Another thing I didn't mention is you can

generate static builds,

preview the static build in the Drupal UI.

And also if you use Netlify,

you can trigger a deployment to Netlify

from the Drupal admin,

which is also pretty cool.

And then challenges here.

And with the time that we have after this,

we can certainly talk more
about these if people want to.

But you might be thinking well,

my site can't be static,

and you may be right.

But, especially for people who
are used to our Drupal sites

that function a particular way,

I think we have to kind of

change our perceptions here a little bit.

So things that could be a road block

could be the volume of your site,

the data that you have.

So if your build times take so long,

and the content changes so frequently

they start to bump into each other,

that can be a problem.

It's a different preview experience

from what Drupal offers.

Really you have to have a build

that you preview somewhere.

I know that Gatsby is actually
working on an offering

that is gonna improve
the preview experience.

So that potentially is
gonna start changing

some of these tools.

And then things that are actually dynamic

like forms, or authentication.

There are definitely a lot of
options there like Netlify,

and some of these others hosts

offer their own solutions for that.

For something like Gatsby,

any way that you handle
authentication in a React app,

you could do that.

You could use like a
lambda function on AWS

to handle some of this stuff.

But maybe if you have a form-heavy site,

Drupal's form API is great.

Maybe like that's the real solution

and then a static site
wouldn't be the right option.

But in general,

I would definitely encourage
yourself to ask yourself

why can't the site be static?

Maybe start from there and

challenge your perceptions
and see, you know,

is there a portion of
the site could be static?

Rather than assuming that
everything has to be dynamic.

And maybe in some cases it does.

But definitely think differently about it.

Okay so yeah.

The few things to mention here

before we can go on to some other stuff.

Contribution Day is tomorrow.

We'd love to see you
there from 10:00 to 4:00.

Amy June is gonna be doing
a new contributor training.

If you haven't done that, it's amazing.

I'll also be there
helping triage some issues

for the new admin theme, the Clara theme.

So we'd love to work
with some of you folks

if you want to try to track down some more

front-endy things.

So it's gonna be great tomorrow.

And then we'd also love
your feedback on this talk.

So it's mid.camp/241.

Fill out the form, I'd appreciate it.

And the top rated sessions
are gonna be captioned,

which is also super-duper amazing.

Okay, so we did the first half

and now we're at the second half.

Everybody feeling good?

Yeah, all right.

I'm also in between you and lunch

which is always a risky thing.

So, does anybody have anything

that they want to show and tell or share?

Anybody have a static site project

or a static site generator
they want to talk about?

It's cool if you don't.

But it'd also be amazing if you did, yeah.

- [Participant] I just
had to mention boost.

I thought that was,

going way back, that was such a cool.

- [Brian] Yeah the boost module, yep.

- [Participant] Cool way
of doing that back then.

- [Brian] So somebody
mentioned the boost module.

Yeah it is cool.

And Tome I believe is
specifically trying to address

some of those use cases from boost.

One that I remember seeing
something about recently is

I think boost had a way to

dictate what paths were
static and which were not.

And there's documentation
in the Tome guide

about how to do that with Tome.

So you can pick a chunk of
your Drupal set that's static

which is pretty awesome.

Okay yeah.

All right so just rock some Q&A I guess.

- [Participant] I've
got a question for you.

So if I was just hand-coding a site,

HTML, CSS, and JavaScript,

you know, I could put in a widget

that was an interactive widget.

Like if I was using React or Angular

to create some sort of like, you know,

cool photo thing.

Is that something that could be done

with these static site generators?

Because you talked a lot
about them being in markdown.

And what if I wanted to
insert an interactive widget

inside of one of these sites?

- [Brian] So the question was, you know,

what if I wanted to include
some portion of dynamic content

inside of one of these sites.

You can definitely do that.

It varies depending on
what the solution is.

So for something like Jekyll,

or something that's markdown based,

any valid HTML is also valid markdown.

So that kinda opens the door there.

And if you include the right JavaScript,

that might be part of the way into it.

For Gatsby, it's just React
at the end of the day.

So even a page that's
initially rendered statically

can then do dynamic things.

And then also there's,

I've never used it,

but there is a,

I can't even remember what it's called,

but there is an interesting React project

that lets you

specify React components in markdown.

So that might be also a funky way

to have things that are more
dynamic in markdown data

that goes into Gatsby.

But yeah, it's definitely doable.

One of my coworkers who's
interested in Gatsby

with a project that he's been working on,

he has a demo that has

everything generated
statically by default.

And then it's possible to authenticate.

And then when you authenticate
it knows your location.

And based on that, all of the listed data,

you know let's say like
available deals or something,

they update it based on your location.

So once you log in,

you go from the static experience,

which is basically just rehydrated data.

So part of it's still static.

So it's possible.

- [Participant] Okay, great.

- [Brian] Any other questions?

I can like demo some stuff, yes.

- [Participant] I was gonna say,

in the past I've just tried
to find some way to do this.

And one way I've come up with was like

using like HTTrack as just kind of this

open source project I think

where you can just download.

You can probably just download

any website that's on the
internet with it, you know,

or something like that.

So I've done that with
some of my Drupal sites

just kind of download that to a site.

It's pretty similar to
kind of some of these.

- [Brian] Okay cool.

- [Participant] But these
probably work a little more better

with Drupal too, so.

- [Brian] Yeah, so HTTrack you said?

- [Participant] Yeah, yeah.

- [Brian] So HTTrack might be an option

to get a static archive
of an existing site,

older Drupal sites.

- [Participant] One thing
I did find though was like,

you know, a website that
had a lot of content,

you know, each page kind of has,

at least in that thing,

has its own copy of all
the content to some extent.

You know so,

a site with a lot of content,

it started becoming like

gigabytes and gigabytes of data.

So I was like,

maybe this doesn't work for huge sites.

It works for small sites.

- [Brian] Yeah, that makes sense, yes.

- [Participant] So about how long

do some of these builds take?

Like for you know a standard,

whatever you want to consider
like a standard site.

- [Brian] Yeah, so the question was

how long do these builds take?

That is a tough question to answer

'cause there are so many variables.

And I have not

done like production builds

that have a really, really large data set.

They can definitely take minutes.

So like my site,

my personal site probably
has like 100-ish nodes.

And that just takes a minute or two.

But yeah, it can over time scale up.

But yeah, that's a question
that comes up all the time.

It would be interesting to kind of know

where the threshold is.

And I would imagine

there's probably some
sort of practical limit

for the gatsby-source-drupal
plugin for example.

So that's a great question.

But also the kind of flip
side of that is, you know,

how often is that content changing?

Like let's say that your build
process takes 45 minutes.

God I hope that's not the case.

But does that matter?

Maybe it does, maybe it doesn't.

Yes.
- So I'm curious about images.

So in Drupal, you know,

we can upload an image.

We can define image styles to like

resize the image for thumbnail etc.

When using a static site generator

and pulling that data from Drupal,

are we able to pull in those images

that are already styled and cropped?

Or do we have to manufacture that

with a static site generator?

- [Brian] Yeah, so the question was

images and how do we
handle responsive images,

and just images from Drupal in general.

You can do either.

So there is a,

not gonna bring it up,

but there's a blog post.

I think on the Lullabot site,

a series of like decouple
Drupal hard problems post.

There's one specifically about images.

And that has some options to
be able to like using JSON API

get at different variants of
an image for responsive images.

So you can do that.

It seems like a lot of work.

So if there is an option to do
it in your static site tool,

that might be the easier way out.

So the Gatsby demo does that.

So when you refresh the page here,

you see that it has that
little scale up effect.

There's a handful of
different image options.

So that uses

one of the plugins.

So I think it's some
combination here of Gatsby sharp

and Gatsby transformer sharp.

I thought there might be one other.

So how that works on the
Gatsby side for example is

when the gatsby-source-drupal
plugin crawls the JSON API,

it can determine when
something is an image.

And then when it does that,

it takes the image file locally

and then creates,

might be the wrong term,

but what Gatsby often
calls a node for the image.

And then it can take that
image and pass it through

any of Gatsby's image processing.

So you can define different break points.

You can use those image
processing options.

So in that particular case,

that's probably your best
bet to let Gatsby do it.

- [Participant] Okay.

- [Brian] Did that answer your question?

- [Participant] Yes it does, thank you.

- [Brian] Cool.

All right, maybe something over there?

No just a chin thing yes?

- [Participant] I was just gonna,

the markdown React thing
I think is MDX maybe.

- [Brian] Yeah, MDX yep.

Yeah the markdown React
plugin is MDX, yes.

- [Participant] Is there
time we have people come up

and give demonstrations of
things that they've done?

- [Brian] Yeah, do you have a static?

- [Participant] No, I'm
interested to see some though.

- [Brian] Okay, what do you want to see?

- [Participant] Just an
example of, you know,

what the static site looks like.

- [Brian] Okay, I mean
I have a Gatsby site up.

So I can certainly do that.

So this is just the,

who has seen a Gatsby site,

or specifically this
Gatsby example in the repo?

One, okay.

So I'll only bore you.

So this is what the default
Gatsby example looks like here.

So it has the Umami demo data.

And then if I click on a recipe,

I go to the recipe page.

And you know, because
it did that preloading,

it was, you know, basically instant.

You know, the image kinda scales in.

But the data's already there.

It's super-duper fast.

And then I think if I open up
that console I can show you

a little bit of

like what the preloading looks like here.

Probably need to bring some of this up.

You can see that as you scroll here,

as I kind of hit new portions of the page,

it starts to load in additional data.

Like here, these are
some examples of getting

like additional content for the page.

So as you scroll down it's
doing that preloading.

And then since it's running,

like I can show you a little bit about

like what the developer
experience looks like.

So here, let's see,

this is the recipe component.

And I'll get to the page that has that.

So go to a particular recipe here.

And we see that it's got the prep time

and all of the data coming
from this particular recipe.

You know, if I go here
and I change the markup.

Hi demo.

Save it.

It automatically just
reloads in the browser

and we can see our changes there.

When you start getting
into the data part of that.

So on the Drupal side,

if you change your Drupal data,

or the structure of your Drupal data,

you actually have to like

restart the dev process to get
your latest data from Drupal.

But if it's up on the file system,

even if you change your data
source on the file system,

it just automatically reloads.

And you know it's a React site.

And the same deal with any of
these static site generators.

Get the data and then
there's a templating layer

on top of it.

So you can make it look
like whatever you want.

And then some of them also have things

that are similar to themes.

Like Jekyll has themes.

Gatsby has a lot of starters.

And they also did introduce
a concept of a theme as well.

Any other Gatsby particular questions?

Or is that something, cool, yes.

- [Participant] I just wanted
to say that on gatsbyjs.org,

they have a showcase of nice Gatsby sites

that you can look at.

- [Brian] Cool, yes.

- [Participant] So this
is a kind of a scenario

that we're facing.

We have a static,

they're essentially static sites,

but they're in ColdFusion.

And they're old and we want to,

we were thinking we would just use React

to bring them into,

to kind of crawl them and convert the data

from the ColdFusion rendered pages into

I don't know, Drupal, or wherever.

Maybe just, I don't know JSON,

I don't know.

But how would you
approach that with Gatsby?

Could you define the source that was

a template that was a rendered page?

- [Brian] Nice easy softball question.

How do you migrate a
bunch of ColdFusion sites?

Just kidding.

(audience laughing)

- [Participant] The
ColdFusion sites were migrated

from Dreamweaver templates.

So if you think of it that way,

they're templated sites.

The ColdFusion isn't the issue.

- [Brian] Yeah, the first
question I would ask,

I'm sorry, I just made fun of things

that are different and scary to me.

(audience laughing)

The first question that
I would ask is what

is the easiest way for you
to get at that data reliably.

And I don't know ColdFusion.

So I don't know what the answer is.

But if you could expose
that data over an API,

that would work.

So if it was some sort
of REST or JSON endpoint,

there's plugins for that.

And you could use that approach.

If there's an easy way for you
to export the underlying data

out of ColdFusion,

you can do that.

Is it database exports?

Can you get,

you know, some sort of static
representation of the data

in a ColdFusion site?

But whatever ends up being the easiest way

for you to get the data
in a reliable manner

that you can work with,

that's where you'd start.

I mean, not very specific,

but hopefully a little helpful.

Cool, thanks for hanging in there.

We got this.

Any other questions or
comments or anything?

Was this useful, interesting?

Good, some nods.

For the video, some nods.

(audience laughing)

All right cool.

We made it 15 minutes
into the bonus section,

so I'll take it if he doesn't
have anything else to do.

But happy to talk about this

if you have other static site ideas.

And definitely play around with it.

Try it out.

I think there's just some
interesting possibilities

in the Drupal community what
we can do with these tools.

So thanks.

(audience clapping)

Captions made possible by ClarityPartners.com. Chicago area Drupal consultants