1 HOW TO SUCCESSFULLY IMPLEMENT HEADLESS DRUPAL (How WE implemented decoupled Drupal, successfully) OCTOBER 20, 2015
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
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!
Related Documents
