Download pdf - How to Successfully Implement Headless Drupal

1

HOW TO SUCCESSFULLY IMPLEMENT HEADLESS DRUPAL (How WE implemented decoupled Drupal, successfully)

OCTOBER 20, 2015

2

Brief Agenda

Who we are & project overview 1

Architectural design decisions 2

Application components 3

Outcome 4

Q&A 5

3

ABOUT EPAM

4

NavigationArts is now EPAM

5

EPAM: A Pioneer in Product Development

PRODUCT DEVELOPMENT EXPERTISE

100+ clients amongst independent so>ware vendors

5 out of Top 10 largest so>ware companies are clients

Serving industry leaders as well as emerging technology companies

DOMAIN-LED ENTERPRISE SOLUTIONS

2006 Q1 2015

ISVs & Technology 75% 22%

Banking & Financial Services 0% 28%

Travel & Consumer 4% 24%

Business InformaPon & Media 8% 13%

Life Sciences & Healthcare 0% 7%

ORGANIC COMPETENCIES

Core Product Engineering User Experience Digital Strategy

AnalyPcs & Big Data Commerce Mobile Social

PRODUCT ENGINEERING PRODUCT

DEVELOPMENT SERVICES TECHNOLOGY SOLUTIONS

1990s 2000s TODAY

EPAM FOUNDED IN 1993

1990s 2000s TODAY

A foundaPon in product engineering led to accelerated growth in technology soluPons and created a strong plaWorm for a new type of services offering in Product Development that addresses many of the disrupPons facing industries today.

6

What is headless or decoupled Drupal?

•  Content and display are separated (“decoupled”)

•  Front-‐end / consumer grabs resources through defined interface

•  Typically RESTful

•  Typically JSON

7

Why would you ever do this?

• More flexibility in the front-‐end

• More flexibility in using front-‐end resources

• Mobile apps

•  Lean development workflow (lowercase lean)

•  Prevent front-‐end code kludge (can’t write db queries)

• MulPple content consumers (mulPchannel)

•  Non-‐website consumers

•  Publish “part” of a site

• MulPple / separate architectures or infrastructures

8

WHY (AND HOW) WE DID IT (SUCCESSFULLY)

9

USCCB App

iOS and Android mobile apps 1

Website 2

16,000+ microsites 3

Salesforce data sync and single sign-on for microsite management 4

Hard deadline in 6 mo. (the Pope is coming - literally.) 5

10

WE CAN DO ALL THE THINGS

11

What we decided

We want it to feel as “application-y” as possible 1

Start with a website 2

Cordova-based wrapper for native apps 3

We’ll use AngularJS 4

We’ll use decoupled Drupal 5

12

Proposed architecture

Mobile app (Ionic w/ AngularJS) 1

Website (AngularJS) 2

Content entry (Drupal 7) 3

API (Drupal 7) 4

13

OK, Sign us up for “Headless Drupal”

•  No “best pracPce” (yet)

•  Various degrees of success and degree of “decoupling” in the community

•  A variety of contrib modules

(Services, Views JSON, RESTWS) are used

14

Attempt #1: Services

•  Most widely used

•  Most experience

•  Tied to Drupal structures

•  Limited ability to customize resources (without greater effort)

•  Hard to re-‐use front-‐end code

•  Too much overhead

CONS

PROS

15

Attempt #2: Views Datasource

•  Can completely customize resources

•  Easy to create with Views UI

•  Lack of control over response structure

•  “Stuck” with views

•  Limited developer workflow

•  Hard to re-‐use front-‐end code (varying structures)

•  Too much overhead

CONS

PROS

16

Re-evaluate

•  RESTWS

–  Similar problems to Services

•  Custom soluPon

–  The Pope is coming

•  There is another… –  RESTful!

17

RESTful module

•  Doesn’t assume data structures

•  Expressive •  Lots of built-‐in features that are great for an API, such as

–  Versioning

–  Bundle based resources –  Resource discovery –  User authenPcaPon –  Caching

•  Easy to implement and extend

18

RESTful module

•  Each resource is a ctools plugin

•  It’s easy to create a new data provider or formaler

•  Very quick to extend

19

NOW WHAT?

20

“How do I know what resource to grab when a user visits a URL on the app?”

•  Landing and lisPng pages (aggregate pages) handled by AngularJS

•  Individual pages use Drupal aliases

21

Search?

•  Standard Search API Solr

•  Used RESTful Search API module as a base

•  Built out facets using facet realms for configuraPon

22

Translation

•  EnPty translaPon

•  Language toggle on front-‐end •  Some items (Main menu / nav) are translated in the app itself

•  API Language selecPon is by URL path prefix (just like Drupal pages)

•  Some nested items we decided to provide all languages for (for “look ahead”)

23

Caching

•  Using Varnish to cache the API

•  RESTful has its own caching (can turn on or off in the plugin)

24

•  Main site menus handled by Angular

•  Custom sub-‐menus handled by API

•  Custom Drupal interface for custom menus

Menus

25

•  Easy to leverage panels + views for a custom administraPon area

Admin section

26

•  The Pope didn’t excommunicate us

•  We got a lot of traffic -‐ and it didn’t crash

•  NaPonal and local media alenPon

Results

27

•  TesPng and rolling out Parish and Diocese Salesforce integraPon

•  Our API only serves anonymous traffic (for now)

•  We built a fair amount into the front-‐end app

•  There’s no “preview”

•  We made compromises to simplify things wherever possible

•  Prerender

•  Offline content

What’s next / lessons learned

28

•  D8 REST is a good step -‐ let’s make it aesthePc so front-‐end devs who don’t know a lick of Drupal WANT to use it!

•  Become a desired backend for powering fancy new frontend frameworks (drives pace of innovaPon)

•  Hybrid websites -‐ both twig and API-‐driven elements (“progressively” decoupled as Dries called it)

•  Now is a great Pme to try this technology and help steer its future. Using Drupal 8 + RESTful module is a great place to start

The potential for Decoupled Drupal

29

Q&A

David Vespoli Software Engineering Manager [email protected]

Kris Graham Lead Software Engineer [email protected]

QUESTIONS?

Seth Gregory Software Engineering Manager [email protected]

30

THANK YOU!