Headless Drupal

 

Why do. Why don't.

About me

  • Evgeniy Maslovskiy (@Spleshka)
  • CTO @ SystemSeed
  • Semi-active Drupal contributor (850+ commits)
  • 9 years with Drupal
  • drupalace.ru (anyone? please?)

Presentation plan

  • How it works?
  • Why did we decide to move to decoupled world?
  • Problems we met
  • Real world demos / case studies
  • Summary: why do
  • Summary: why don't
  • Notes & advice
  • Development quick start references

How it works?

How it works?

2 apps

Frontend app

React.js

Backend app

Drupal

How it works?

Browser

Node.js

FE APP

Drupal

Browser

FE APP

Drupal

FE APP

Why did we decide to change?

Why did we decide to change?

  • Non-developers hate Drupal
  • Everybody have website they love. It's not Drupal.
  • Much. Better. UX. People buy with their eyes
  • Less features but perfect over more features but ugly
  • Faster & reusable prototypes
  • Faster concurrent development
  • Frontend web development is the future

Problems

Problems. Level 1

  • Hosting
  • Lack of knowledge & expertise. jQuery level developers
  • Learning & teaching
  • DevOps rework
  • Local environment
  • Frontend security 

Problems. Level 2

  • No coding standards. Define your own or pick someone's.
  • Server Side Rendering (SSR)
  • Brand new syntax. ES5, ES6, ES...  WTF?!
  • Brand new world. SSR, Webpack, Babel, JSX... WTF?!
  • Multi threading Javascript VS single threading PHP
  • Unmanaged & immature (to some degree) community 
  • Too much frontend freedom

Problems. Level 3

  • Authentication
  • Menu / routing
  • Image styles
  • Forms. New frontend forms or based on Drupal entities?
  • Custom pages / blocks content
  • Doman VS subdomain VS another domain
  • Testing coverage 

Case Studies

Case Study #1

Case Study #2

Case Study #3

site1.com

site2.com

site3.com

Drupal Commerce Backend

Summary

Summary. Why DO?

  • Much. Better. UX
  • Independency of backend & frontend. Much easier changes.
  • Offline-first approach
  • API-First approach. Ready for multiple consumers.
  • Complete development freedom
  • All UX gets built from scratch
  • "This is how Drupal does it" VS "Let UX experts do their job"
  • Potentially more performant web app

Summary. Why DON'T?

  • Usually much more development effort
  • More senior devs needed (or new developers)
  • A lot of dev effort to learn the new language / community
  • DevOps / processes rework
  • All frontend UX gets built from scratch
  • Drupal out-of-the-box only for backend 
  • Does not fit all projects / clients

Notes & Advices

  • Try on the internal projects first
  • Try on as simple app as possible first
  • Establish unified local dev environment
  • Your first project will be double size of what it could be
  • Every backend request matters
  • Do not ignore frontend security

Dev Quick Start References

  • JSON API (+ Extras)
  • Consumers
  • Simple OAuth
  • Config Pages
  • Decoupled Router
  • Fieldable Path
  • REST UI
  • Subrequests
  • Create-react-app (no SSR)
  • Next.js (SSR)
  • Awesome React Components
  • Express.js (server)
  • Redux (+ Saga)
  • Lodash
  • Dotenv

Drupal

React.js

Thank you

Headless Drupal 8 / React.js

By Evgeniy Maslovskiy

Headless Drupal 8 / React.js

  • 1,051