architect at the Government of Flanders, Belgium Drupal aficionado since 2006 (Vacilando at drupal.org) Staunchly open source, fanatical about solution sustainability and performance Born in Czechoslovakia, Belgian by choice, European at heart https://www.linkedin.com/in/vacilando/
of this presentation 3. Gatsby as a Jamstack family member 4. Complementarity with Drupal 5. Personal experience 6. Pros and cons 7. Summary 8. Resources 9. Questions? — for the next 20 minutes
no longer stranger to the decoupled (headless) architecture; many good front-end frameworks available. Gatsby just one of them, possibly unrivalled in the smoothness of integration. Gatsby evolved from a simple Markdown-based SPA builder into a powerful framework able to handle complex projects. One of the challenges for builders is to decide where the dividing line between the backend and frontend should be. It‘s easy to overdo it on either side. Let‘s examine • the roles of both in the case of Gatsby and Drupal, • the shape of the coupling between these two, • conditions where Gatsby may not be a good fit.
friends. Modern, blazing fast front-end framework based on ReactJS. Open source project • launched in 2016 • by our long-term Drupal colleague, Kyle Mathews. • around 48k stars on GitHub One of the most popular Jamstack projects. On the name -- it's basically because I live literature and I thought "Gatsby" was a great name from a great book about an exciting dynamic time in world history. — Kyle Mathews (Dec. 7, 2020)
a web-development architecture based on client-side JavaScript and reusable APIs. Built around the concept of static generators that basically build the whole site as a set of static (HTML / CSS / JS files) and publish them on a Content Delivery Network (CDN). Other well-known Jamstack projects include • NextJS • Hugo • Jekyll • Nuxt • Hexo • Slate • GitBook • etc.
served statically from a globally distributed Content Delivery Network (CDN). So page caching is built in. Prefetching of linked pages. Progressive image loading. Responsive image loading. Offline access. No extraneous code fetching. Etc.
– just files that can be hosted anywhere. Perfect scenario for serverless hosting such as AWS S3. CMS instance / cost can be much smaller (does not render production website directly). In many cases (no real time backend requests) the CMS can pretty much be shut down between builds.
of starters, which are kind of templates allowing a quick start of any type of website. Somewhat comparable to Drupal themes. More targeted develoment and debugging. Preview of changes without having to refresh the browser page in your local development environment. Easy to plug in new components from a library (typically NPM). Updating your Gatsby site is usually as trivial as running „npm update“. All sources can be approached using one single querying system: GraphQL. An IDE for GraphQL – GraphiQL – is included and available in local development. Clear, excellent, open, GitHub-hosted documentation at https://www.gatsbyjs.com/docs/. Usually enough to implement a new feature (no need to hunt around in blogs and case studies).
types / entities, fields, taxonomy, media, etc. • Editing – WYSIWYG, paragraphs, etc. • Revisions (content versioning) Multilingual capabilities (cf the preceding presentation by Nick today) Slug generation – simple to do in Gatsby, but the Drupal module Pathauto has added value such as integration with modules such as Redirect and Token. Back-end user management. Back-end authentication. API (JSON:API) Token Etc.
caching Prefetching Assets optimalization Image optimalization Easy connecting to and consuming external sources such as S3, Google Sheets, Google Analytics, databases, JSON, YAML, file system, other CMS (Drupal, Contentful, Prismic, WordPress, etc.) – see https://www.gatsbyjs.com/docs/content-and-data/ All accessible via GraphQL. Structured data annotation (Open Graph, JSON-LD, ...)
to implement, though coupling with the Drupal authentication (if required) is a problem. One solution might be in using a third-party authentication for both Drupal and Gatsby (e.g. Auth0). Search easy to implement in Gatsby (e.g. using Algolia) but Drupal‘s own search config (Search API) is even simpler, and there‘s a disconnect between the two. Room for improvement. Preview – great in Gatsby development, there‘s even a Drupal module, but it‘s not as seamless as in the monolithic Drupal. Closely connected with the problem of providing revisions via the Drupal API. Forms – by definition require backend involvement; often solved by using serverless tools (e.g. Netlify forms). Redirect functionality – it‘s easy to define redirects in Gatsby, but it will be useful to plug into the excellent Drupal Redirect module functionality • Patches are almost ready for the Redirect module — follow tickets #3057679 and #3073966!
almost 473 million seconds (that means starting with Drupal 4.6!) Got used to watching scores of new hip players coming up and vanishing again. Who leaves a partner after 15 years of happy life? And yet....
☺ Drupal is still way the best CMS to my knowledge (although CMS competition is intensifying). But Gatsby is definitely a game changer. Not just the built-in speed, scalability, security, and simple hosting. It‘s also modern, elegant and fresh! ( Talk about a mid-life crisis ☺ ) Clear-cut example of a decoupled setup that has more pros than cons.
can beat static files on CDN. / Drupal is able to cache on – and expire from – a CDN. Security – virtually no worry about Drupal / PHP / MySQL and other backend vulnerabilities. / There‘s no such thing as no security worries! Stability – no worries about traffic surges or DOS attacks on a site that replicated all around the world. / Even static site hosts can be crippled by attacks. Fun to build. Your devs will adore you. / That‘s not really a deliverable. Additionally to Drupal, Gatsby can easily connect to a myriad other data sources. And all data source are accessible uniformly via GraphQL. / Two words for you: External Entities.
huge Gatsby / ReactJS / JS ecosystem of plugins. Way more than Drupal alone. / Does Drupal not have enough contrib modules? Access to a vast pool of ReactJS / JS developers – less pressure on finding Drupal talent. / Hey, I‘m available for hire! Simple and full-featured access to Drupal content thanks to the excellent JSON:API module / There are edge cases like revisions ... Affordable or even free hosting on Netlify, AWS S3 and CloudFront, GitHub pages, Azure, etc. Or your HTML server! • Particularly interesting: Gatsby Cloud – extremely streamlined for Gatsby. • True magic: Surge – allows you to publish a Gatsby site on your own domain with 2 simple commands. / Never heard of Jeff Geerling‘s Raspberry PI Dramble? Hosting companies specialized on Jamstack offer useful extra functionalities. E.g. the Netlify cookieless analytics, Gatsby cache plugin speeding up builds, image optimalization at no extra price, etc. / ... making it harder for you to leave them.
Drupal requires a rebuild. Simple to automate using a hook. But there‘s no fine-grained invalidation (cf cache tags in Drupal). Since this year Gatsby offers incremental builds, but the front-end refresh remains a challenge for sites with some 100 000 or more pages. / But does every edit really need to be published immediately on your site? Easy to limit access to pages and features in Gatsby, but coupling it with Drupal user roles and perms is a challenge. / Do users and roles really need to be mirrorred on the front-end for your site — or is it just a nice-to-have? Not ideal for sites focusing on authenticated users (less security and speed advantages, complex setup) / You can still use it for all your publicly available (sections of) sites. Compared to Drupal you will face less configuration and more coding. You will have to learn JavaScript as a basis, Gatsby for the concept, GraphQL to write queries, bits of ReactJS as needed, extra benefit from Typescript, etc. / Thanks to the ReactJS components the code is very structured and clean. Learning Gatsby is fun! Gatsby still suffers from an outdated stigma of a SPA static generator based on local Markdown files... / Just check it out and you‘ll be hooked!
firmly on one or the other side. An ideal division of the Drupal and Gatsby roles remains elusive as both systems evolve rapidly. Drupal shines not only as a CMS with an API. Thanks to its ecosystem of modules it can serve as much more than just a back-end content source. Everything exposed through the API is potentially useful at the Gatsby front-end. Gatsby shines on everything that happens in the front end, with the added security, performance, easy and cheap hosting, modern feel / fun, easy connection and querying of data sources, great documentation, huge ecosystem of plugins and starters, vast pool of available resources. Gatsby‘s advantages decline for sites • with more than 100k pages (1 million is not impossible though, cf an earlier presentation today) • requiring immediate propagation of changes to the front-end • focusing on authenticated users (Possible approaches: stay with the monolithic Drupal, or a custom ReactJS / VueJS front-end.)
maroon1st
m_seki
oekazuma
riku929hr
manfredsteyer
iwatatomoya
shibuyamizuho
chobishiba
hollycummins
myamagishi
kentatada
stoneream
reverentgeek
maggiecrowley
ufuk
mza
rasmusluckow
eileencodes
quramy
paulrobertlloyd
tammyeverts
andyhume
mongodb
rmw
