The Drupal community has been abuzz for the past two years with talk of "Becoming Headless" or "Decoupling All The Things." The trend raises reasonable questions from end users who feel this means Drupal is moving into a space that no longer represents them. We hear similar concerns from Drupal Commerce users when we talk about delivering headless commerce. However, we don't believe anyone should be worried that improving support for Drupal as a REST API server will detract from efforts to improve its utility as a traditional CMS.
Drupal core, API-First, and headless commerce
When you remove the default presentation layer from a system, you are bound to find interesting problems. How much logic is embedded in a Drupal field formatter or field widget? What happens when those are not used to render or manipulate an entity’s values? As a quick example, work in the API-First Initiative related to taxonomy terms turned up a validation bug where code restricting parent terms to the same vocabulary only executed in the context of the default entity form. Fixing that bug to prevent invalid relationships via API updates contributed to improving Drupal core overall even though the issue wasn't affecting traditional Drupal usage.
Consider a couple examples of our work toward a fully headless Drupal Commerce improving the modules more generally:
Cart should grant "view" access to orders available from a user's cart session
While working on the Cart API module to find ways to use JSON:API, I realized we were missing some entity access control for carts to allow anonymous users to view their orders tracked in their session. With query-level entity access landing in Entity API, fetching orders over JSON:API or GraphQL automatically restricted the returned orders to carts belonging to authenticated users. We realized we needed to update Commerce Cart to support this use case for traditional and headless use cases.
Provide a constraint on the Coupons field to verify referenced coupons are available
I set a goal earlier this year to support coupon redemption through our Cart API. I ran into a problem early on while evaluating our code to remember where / how we validate coupons. I knew the code existed and expected it'd be pretty simple to reuse. Unfortunately, it turned out we only put validation logic in the default coupon checkout pane code, meaning a coupon redemption endpoint in the Cart API would have to reproduce the code to support client-side coupon validation. That sort of duplication is bound to lead to bugs or out of sync logic.
What was the solution? Add a validation constraint to our coupon reference field on orders. This constraint contains the code that validates a coupon for an order and ensures its related promotion applies. RESTful Web Services module and JSON:API automatically run validation against entities when they're modified, triggering this check and allowing invalid coupons to be detected right away. This in turn let us simplify our coupon redemption form as well. The final patch is still in progress, but once landed, it will make it easier for any Drupal Commerce site, headless or not, to add their own customizations on top of the default coupon redemption form or write their own.
What’s next for 2019?
We've been pretty busy preparing Centarro Toolbox for release at DrupalCon Seattle, so first I expect I'll take a deep breath and celebrate the Drupal 8.7 release. We're planning now how to ensure Drupal Commerce users can harness the power of Layout Builder and Media, and we'll be integrating them into our Belgrade based demo.
Second, we'll continue to improve the developer experience with Drupal Commerce over the various API based modules. Headless Drupal Commerce is already working in the wild. The team behind Spark POS uses JSON:API and Drupal Commerce to handle ZKungFu’s billion dollar business. 1xINTERNET has been pushing React based front-ends for a while and will even be presenting their work at DrupalCon. As project maintainers, we want to empower teams to build similar applications and move our support from product catalog navigation and shopping cart manipulation through to checkout completion and order management.