- When to go Headless
- Speed of Development
- Separation of teams/resources
- Same data, lots of different consumers
- Architecture Patterns
- Architecture Patterns for Decoupled sites.
- Faster if you have a REST API in place.
- Not always initially faster. A headless approach to developing a Drupal site can lead to gains later in a project.
- Dedicated teams for building 'Drupal' resources, and dedicated teams for building rendering/presentation resources.
- Lack of technical debt on teams. Focusing on a single set of tasks.
- Building one backend that will be consumed with many different systems.
- Separation of concerns
- When the the Drupal presentation layer is getting in your way.
- Routing
- Clean URLs
- Caching
- Templating
- Error Handling
- Interactivity
- Authentication
- Permissions
- API Versioning strategy & implementation
- API Documentation strategy & implementation
- Cache & Theme
- Client Side templating
- Static Site Generator
- Drupal to Drupal
You can add an API to your existing Drupal site and use it as a superset of the existing functionality.
- The Tonight Show Starring Jimmy Fallon (Node.js + Backbone.js): / DrupalCon case study /via @vordude
- Weather.com (Angular): / DrupalCon case study /via @DamienMcKenna
- Radio France Internationale (Symfony 2): /via @slybud
For a bigger list of examples see this list
A roundup of some great Headless talks at Drupalcon LA
Here's a blog post about some of the Four Kitchens' Headless talks at NYCCamp