Reservoir or Decoupling Drupal Made Easy for Anyone: Non-Drupal Developers and Editors

Here's how the ideal decoupling Drupal scenario looks like:

Stripping Drupal to its essential role, that of a robust and flexible content repository, no Drupal expertise needed. Then using it to back your front-end with; one that you'd be free to build by leveraging any modern (JavaScript) technology of your choice.

… a Drupal back-end content store that would still preserve all its content editing and managing functionalities, needless to add.

Luckily, this is no longer “daydreaming”. Not since Reservoir, the headless Drupal distribution, has been available. 

Here are some of its “promises” or well-known challenges, if you prefer, that this distribution's geared at solving:
 

1. to make Drupal far more accessible (cutting the intimidating Drupal setting up and configuration out of the equation) to developers of all stripes
    
2. to empower developers with all the best practices for building their Drupal-backed front-ends quick and easy
    
3. to provide an opinionated starting point enabling any developer to build a Drupal content repository backing his non-Drupal application with... no Drupal knowledge needed, actually
    

Your Current Situation: Why Would You (Even) Consider “Headless” Drupal?

Here you are now, dealing with the pressure of:
 

• having to deliver content agnostically across any given channel and device: single-page JS apps, mobile apps, digital signage, AR and VR-driven content, IoT apps etc...
   
• … all while storing it (content) in one single place 
   
• providing your editorial team with a... way to edit, manage and overall administrate content conveniently easy, via an editor-friendly UI
   
• … independently of the development team, of course
   
• finding a way to enable your developers to easily send content across this entire “ecosystem” of channels, devices and platforms
   

In other words: you're grappling with the challenge of making Drupal ideally accessible to your (non-Drupal) developers; so they can easily build their Drupal-based content store enabling them to deliver content to any given device.

… to serve it to any given app/site.

And this definitely calls for a decoupling Drupal approach.
 

Decoupling Drupal: The Most Discouraging Challenges You Must Be Facing 

Let's assume that you're already considering headless Drupal as a solution for your current challenge, that of delivering content to multiple channels, devices, platforms.

Whether you're planning to decouple Drupal for:
 

1. building a Drupal-backed front-end, leveraging one of your modern JavaScript frameworks of choice
2. or using it as a content store for your non-Drupal app
    

Then, it's these specific challenges that you must be facing right now:
 

1. your non-Drupal developers are having trouble maneuvering Drupal content; they're not familiar with all the dials and knobs needed for making the most of Drupal's REST API 
2. Drupal's serialization format is... alien to them 
3. there's no starting point or well-defined best practices for non-Drupalists, that would ease their way to turning Drupal into a content repository
4. … one that they could back their front-ends with
    

True story!

And still, there is hope...
 

5 Reasons For Being “Skeptical” About Distributions

You must be legitimately cautious right now when it comes to using an API-first distribution for Drupal. And that's due to some bad experiences with... distributions.

Now let me try and guess some of your “fears” regarding Reservoir:
 

1. that it might turn out to be overly complex 
2. that you risk getting “stuck with” architectural debt
3. that its maintainers might someday lose interest in it
4. that it's built primarily for other use cases, for scenarios different from your own decoupled Drupal implementation project
5. that you risk “inheriting” bugs in features that you haven't even used 
    

And the list of reasons why you're not yet jumping on this decoupling Drupal trend could go on...
 

Introducing Reservoir: The Headless Drupal 8 Distribution! How Is It Different?

Before putting it into the spotlight and giving it a “full scan”, let me try to read your mind and identify the questions that you must be asking yourself right now:
 

1. “How precisely do I use Reservoir as a content store backing my front-end website or app?”
    
2. “Which are the bare essential Drupal modules and core functionality that this distribution comes packed with?”
    
3. “How can I leverage these ready-to-use components for decoupling Drupal?”
    

And now that we've put your valid queries into words, let me try and define Reservoir for you:
 

• 1st definition: a distribution for decoupling Drupal
   
• 2nd definition: an ideally flexible and minimalist tool empowering developers of all backgrounds to build content repositories for their apps to “consume”
   
• 3rd definition: the headless Drupal 8 distribution “specialized” in manipulating content and interacting with it via HTTP APIs
   
• 4th definition: a Drupal-based content store with all the web service APIs backed into, so that any developer can jump straight to building his front-end app
   
• 5th definition: simply a... content repository; one that just happens to be Drupal-based, as the Reservoir project's maintainers admitted.
   

Now the 4 key goals behind this distribution for decoupling Drupal —  besides that of providing a simple way of building a content repository enabling you to use any technology for your front-end —  are:
 

1. on-boarding developers or all stripes, making Drupal ideally accessible to... anyone
2. providing a much-needed opinionated starting point for any type of decoupled Drupal implementation; no Drupal knowledge required 
3. keeping itself away from the scope creep that end-user facing products risk falling into
4. serving a specific decoupled use case
    

Decoupling Drupal Made Easy & Accessible: Key Reservoir Features 

“But how does Reservoir make building Drupal-based content repositories so much easier than other... distributions?” 

“How precisely does it make Drupal accessible to non-Drupal developers, as well?”

You're more than entitled to ask yourself that...

Therefore, let me outline here the out-of-the-box Reservoir features geared at speeding up any decoupled Drupal implementation. Regardless of the developer's background:
 

• an opinionated selection of API-first/ web services modules — Reservoir offers each developer a much-needed starting point/”push” so that he can ramp up and have his content stores built in no time: Simple OAuth modules here included
   
• quick and easy access to the content back-end via JSON API 
   
• auto-generated documentation (API documentation), that gets automatically updated, as well, as you're browsing it, as your content model changes
   
• OpenAPI format export, that supports hundreds of tools integrating with the OpenAPI specification 
   
• easy-boarding/tailored UI —  expect a “welcoming tour” once you've installed Reservoir, one focused on getting you familiar with modeling and managing content, web service APIs, mapping out new content models etc.
   
• a permission system and content editing UI empowering your editorial team to easily manage content 
   
• SDKs, libraries and references —  included in the Waterwheel ecosystem —  so that your development team can skip the time-consuming API learning phase and jump straight to “attaching” Drupal back-end content to their front-end apps
   

Note: Reservoir, the distribution for decoupling Drupal, deliberately shakes off some of Drupal's functionality that's irrelevant for content repositories (modules such as Breakpoint, Views, Content, the user-facing front-end etc.)

For we couldn't even talk about speeding up your decoupled Drupal project when there's an unnecessarily heavy weight of Drupal modules and features “dragging down” the whole implementation process, right?
 

Wrapping Up: What Reservoir Aims At Is...

... enabling your developers to jumpstart building self-hosted content repositories capable to serve any given front-ends.

Front-ends that they get to build independently, tapping into the technologies they prefer, on a project-by-project basis.

Pretty convenient, don't you agree?