At the end of February, I began working on an series of API endpoints that would allow for a progressively decoupled cart experience. There are a few reasons why we decided that Drupal Commerce needed an API solely for the cart.

1. Performance: when a cart block is rendered on the server it has complicated cache metadata. Cart block contents vary per user and change too often to be cached effectively. As such these blocks incur heavy logic and rendering costs.
2. Flexibility: modern consumers expect interfaces to be more reactive and match common UX patterns. These patterns almost always require client-side implementation using JavaScript that communicates to backend APIs.

In my last blog I brought up why the API-First and JavaScript Modernization initiatives matter to Drupal Commerce. I wanted to target something limited in scope that would provide big wins for Drupal Commerce users as we ventured into the fully and progressively decoupled Drupal realm.

As a result, we now have the Commerce Cart API module. Our first implementation will be the Commerce Cart Flyout module, which uses the RESTful endpoints provided by the Cart API module to create the dynamic cart interface shown in the sample animation below.

This moves us decidedly down the path of providing Drupal Commerce users with progressively decoupled components that improve the customer experience. In a following blog post, I’ll going to write about what it was like to build this module. (Hint: we didn’t “just do it” and release it into the Drupal.org namespace.)

I am planning on experimenting with more areas that we can perform progressive decoupling and look forward to connecting with folks about the topic at Decoupled Drupal Days in August. You should meet me there to join in the conversation!