1. EPAM presented on their successful implementation of a headless Drupal architecture for a mobile app and website project for the USCCB within a 6 month deadline. 2. They initially tried using the Services and Views Datasource modules but found these added too much overhead. They ultimately used the RESTful module to build out the API due to its flexibility and extensibility. 3. The project involved building iOS and Android mobile apps, a responsive website, and integrating with Salesforce data. Search was implemented using Solr and facets. Caching was handled by Varnish. 4. The project was a success with high traffic during the visit of the Pope without any crashes. Lessons involved opportunities to

1. 1
HOW TO SUCCESSFULLY
IMPLEMENT
HEADLESS DRUPAL
(How WE implemented decoupled Drupal, successfully)
OCTOBER
20,
2015

2. 2
Brief Agenda
Who we are & project overview1
Architectural design decisions2
Application components3
Outcome4
Q&A5

3. 3
ABOUT
EPAM

4. 4
NavigationArts is now EPAM

5. 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 SERVICESTECHNOLOGY 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. 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. 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. 8
WHY
(AND
HOW)
WE
DID
IT
(SUCCESSFULLY)

9. 9
USCCB App
iOS and Android mobile apps1
Website2
16,000+ microsites3
Salesforce data sync and single sign-on for microsite management4
Hard deadline in 6 mo. (the Pope is coming - literally.)5

10. 10
WE
CAN
DO
ALL
THE
THINGS

11. 11
What we decided
We want it to feel as “application-y” as possible1
Start with a website2
Cordova-based wrapper for native apps3
We’ll use AngularJS4
We’ll use decoupled Drupal5

12. 12
Proposed architecture
Mobile app (Ionic w/ AngularJS)1
Website (AngularJS)2
Content entry (Drupal 7)3
API (Drupal 7)4

13. 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. 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. 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. 16
Re-evaluate
• RESTWS
– Similar
problems
to
Services
• Custom
soluPon
– The
Pope
is
coming
• There
is
another…
– RESTful!

17. 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. 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. 19
NOW
WHAT?

20. 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. 21
Search?
• Standard
Search
API
Solr
• Used
RESTful
Search
API
module
as
a
base
• Built
out
facets
using
facet
realms
for
configuraPon

22. 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. 23
Caching
• Using
Varnish
to
cache
the
API
• RESTful
has
its
own
caching
(can
turn
on
or
off
in
the
plugin)

24. 24
• Main
site
menus
handled
by
Angular
• Custom
sub-­‐menus
handled
by
API
• Custom
Drupal
interface
for
custom
menus
Menus

25. 25
• Easy
to
leverage
panels
+
views
for
a
custom
administraPon
area
Admin section

26. 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. 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. 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. 29
Q&A
David Vespoli
Software Engineering Manager
david_vespoli@epam.com
Kris Graham
Lead Software Engineer
kris_graham@epam.com
QUESTIONS?
Seth Gregory
Software Engineering Manager
seth_gregory@epam.com

30. 30
THANK
YOU!