Decoupling Drupal Commerce to Multiply and Scale the Front-end

[Laughter]

>> MATT GLAMAN:
thanks for coming to Decoupling Drupal Commerce
to multiply and scale the front end

my name is Matt Glaman I am product

lead at Centarro and at Centarro formally

commerce guys we power ecommerce

innovation through every stage of growth

you know we build drupal commerce and

e-commerce is our thing so to start I

wanted to go through why you would be

couple Drupal Commerce that's an often

question on when you should and when you

should it one of the main reasons to

decouple is if you need unique branding

or localization for different markets

when you decouple it allows different

teams to control how a markets design

and localization would work so if you

have markets between different countries

or even different brands that are in the

same region but they have different

design requirements you may want to

decouple if you need to reach a modern

audience that shops new multiple devices

when you decouple it makes it easier to

support different front-end applications

such as web an Apple watch you know

other smart devices kiosks a main reason

for decoupling too is to scale for high

demand when you decouple and you remove

some of the rendering bottlenecks

they're associated with full stack

applications like this isn't just a

Drupal problem its WordPress is anything

where the backend is doing logic and

presentation at the same time so those

are some of the reasons why you'd want

to decouple and now we'll go into when

should you decouple so if you kind of

meet some of those marks but you don't

know if you should quite yet so as I

said consider decoupling when you need

to separate the design in styles for

each tenant in your application so in

Drupal your sins can control the display

for every tenant and it being like your

store or brand that sells products using

a little bit of code you can actually

switch the active triple theme

based on the current store that the

person is browsing but now all of your

design changes are tied to your main

application which means that if you need

to deploy a design change for store B

it's going to affect the sales of store

a just for that design change a good

example is like a Geo Systems my cotija

systems is a multi-tenant whole stack

Drupal commerce installation built by

twinks and this is not decoupled and is

multi-tenant so each region has its each

region that they selling has its own

store and unique pricing and we'll go

through a few product one product page

real quick so this is the blk 360 in the

United States

here it is in France and here it is in

Japan as you notice the only thing that

changed was the pricing as you can see

if in US dollars euros Japanese yen but

none of the design changed so like geo

systems didn't need to decouple because

the ceilings say the same they're able

to leverage the normal price dynamic

pricing available in Drupal commerce and

meet their needs they could benefit from

this coupling if each region they need

customized branding or user interactions

let's say they wanted to change let's

say the Japanese market had a different

style of branding this is where

decoupling could be more beneficial

because they can have more autonomy over

how their part of the site looks

>> SPEAKER:  Um, consider decoupling when the business wants customers to be on their website.  This is the common thread now, the quote unquote omni‑channel, such as native applications, or now social media platforms are integrating eCommerce tools more and more.  I know Pinterest does a few things, Facebook, you can shop through their Messenger, so by decoupling, you can explore these additional revenues for sales.  One case study that I'd like to highlight is Eldum Rett, which is a food delivery service built by one Internet, and they utilize a React Native mobile application.  Eldum Rett can eventually move their main web application to de‑couple front‑end, because they've already built the API, so they built a regular Drupal site, then they added an API on top to support multiple ways that you can consume the data, and they could now leverage that to build a decoupled front end at the same time.  

You should also consider decoupling to meet demands of sales growth and high scale availability.  Small eCommerce apps could be highly dynamic.  You may not necessarily have, um, high, just because, sorry.  Even small sites that are highly dynamic, such as different pricing, you may have a small market, but there's a lot of different business logic that goes into your pricing, and when you have these different pricing rules, such as pricing by customer or pricing by region, normal cashing patterns that content sites in Drupal take advantage of kind of fall apart.  You can't use page cash, you can leverage dynamic page cash, but the Drupal render system can perform that skill, but kind of starts to teeter a bit, especially when working with the form API, because forms cannot easily be cashed, so then there's a lot of rendering and a lot of logic, especially when you have anonymous users that can't hit a cash website.  So, that's a good reason to de‑couple, and that will bring us to Centarro's case study for Matsmart.  This is a picture of their home page.  They built a grocery system business on Drupal Commerce and quickly scaled to 10 million Euros in revenue.  They went to a completely headless platform to increase their sales, so they went from a full‑stack Drupal Commerce site, and then we slowly moved them over to a fully decoupled instance, and this allowed them to scale and also launch in more markets.  

We started with full stack Drupal and form API submissions, then we decoupled the add to cart form, and then we finally went full decoupled, and this allowed us to scale to tens of thousands of concurrent customers.  It also allowed us to provide third‑party integrations, so instead of Drupal having to be the search index, they can pump that into a third‑party search index that the front‑end client talks to, but receives the data to be indexed from the back‑end.  So now, their back‑end Drupal Commerce site can focus on just serving carts and payment transactions.  As they move into new markets, they can launch new sites without building another Drupal Commerce site, they just create a front‑end, and then that marketing team can build it as they wish and then plug it into their back‑end, and they can scale out without having to reinvent the wheel.  Um, this year, that was a Drupal 7 site, their main site, but this year, they're expanding into new markets on Drupal 8.  They've been a long‑time supporter of Drupal Commerce and engaging with Centarro as the software vendor and not just a consultant, and through our partnership with them, they've helped us build a fully featured cross‑border eCommerce platform.  If you would like to know more about what we're doing with Matsmart and how you could actually take advantage of some of that, we're onboarding multiple customers right now to Centarro Commerce, which is going to be our open optimize for merchant collaboration.  It's open source, and you can take your data with you. 

 So, if you have any questions about that, I have my e‑mail at the end, and some feedback would be great.  So, taking that, what is our vision for decoupled multi‑tenant eCommerce platform?  Because that's been the trend here.  Decoupling is more, becomes more apparent as a need when you have multiple stores or brands within one site, and, so, when you have the stores, a reminder, a store could be a region, brand, or physical location, we have one client with 120 stores, and those are just physical locations in the United States.  Each store is able to define its default currency, so if you have an Italian store, it could be Euros, if it's in the UK, it could be the English pound.  You're also able to limit who can purchase for a store by limiting the billing and shipping countries per store, and then products can be assigned to each store, so that way you can have products that are only allowed at specific locations, and that helps you control your catalog.  One of the main components in here is price list.  Price list allows you to have multiple currency and per‑store pricing.  Price lists use conditions to evaluate.  These can be beyond just saying what store it's for, it could be for user roles, the purchase quantity, so if somebody buys five of a product, they can get a specific pricing, and also a start and end date.  The price list module was designed for a site with 15 million skews and price lists that contain up to and more than 300,000 skews at a time.  

One thing that we believe in the platform is that JSON API for standardized data consumption, it is an API specification that has been implemented in a Drupal module and is now part of Drupal Core.  One reason I like it is we didn't have to write code for building an API, we were able to just focus on the mechanics of how our API should work with our data model, not how you show it in a JSON blob and the way that it should be interacted with from that point.  Um, I wanted to just quick share a few things that we at Centarro have worked on that help make working with Drupal Commerce in a decoupled scenario easier.  Um, by default, JSON API doesn't let you do cross‑bundle queries, so you could just get all of your products in one site, so we did build the JSON API cross‑bundles module.  This allows you to get flash products and also see all of your clothing and, um, both at the same time, for example.  We created the JSON API resources module.  The currently, the JSON API module has no API for extending the implementation, which was kind of a roadblock for us, because we didn't want people to have to work with our Drupalisms.  So, the JSON API resource module helps kind of flesh out what it will be for extending JSON's API implementation.  One of the outcomes from that module was JSON API search API, and this lets you query your search indexes over JSON API.  Previously, you could just do a query, now you can at least custom your search indexes, which means that you can query data instead of just whatever you could query from the previous.  

Um, we also built the JSON API user resources module, because in a decoupled eCommerce site, you have customers, and they need to be able to register and change their passwords.  The JSON API module by itself does almost nothing for account management except edit your user fields.  This module provides that functionality that's currently missing in the API first ecosystem for Drupal.  Then finally, the Commerce API, which we announced last week, or two weeks ago, and is built on top of JSON API resources and ensures that, for instance, our dynamic pricing capabilities work, so when you fetch products, you're able to get their resolved price based on their user role or location.  It also provides a cart and checkout API, so the cart API allows you to interact with orders, not needing full, like, administration permissions, so this way, you can have anonymous users create carts, do the most important part, take their money, then ship them their products.  So, there's all these components that make‑up this system, and with that, I would like to introduce the Centarro Commerce distribution.  So, as I said, this is going to be an open source we're offering, because we're offering an open distribution for this platform, and the Centarro Commerce distribution will be configured for a multi‑tenant setup, it's going to have all the modules for API first Drupal that let you meet your API needs, and it's going to come pre‑installed and setup with the industry standard for doing log‑ins and authentication.  Um, oh, this is a PDF, so I can't show the image, but I will share out these links.  

If you go to Centarro‑commerce‑demo.web.app, this is a react application that is interacting with a Centarro Commerce back‑end, and we're going to have some GitHub repos soon, so we'll have that distribution up on GitHub, just like Open Social has their composer template on GitHub and Aqua has theirs, we will have our composer template.  The React application will be up there, it's a create react app skeleton.  I do have some themes in the works that will go up as well, and the stretch goal is to create a react and reduct bindings SDK, so when you build your first Javascript application using React, some of the hard parts are already figured out for you for cart and manage, and those will be available at GitHub.com/Centarro.  That's what I've got, so, thank you.  If you have questions, let's chat.  A little hard to do, since we're not physically in a room, but take note of my e‑mail, it's [email protected].  If you can please provide some feedback, and as a reminder, we are having the contribution day still, Saturday, 10:00 a.m. to 4:00 p.m., it's going to be virtual.  The information is on the website and will be led up by Amy June.  Thanks.  Are there any questions that anybody would like to ask?

>> SPEAKER:  I believe anyone that has a question can just enable their mic, turn it on and you should be good to go.

>> SPEAKER:  Yes ‑‑ inaudible ‑‑

>> SPEAKER:  Can you repeat that one more time?

>> SPEAKER:  I asked if it's going to be like the kickstart distribution for ‑‑

>> SPEAKER:  Oh, Commerce kickstart.  So, not quite, because, so, kind of.  I'll say kind of, because Commerce kickstart had two versions, the 1. X was just a, like, starter kit, and then the 2. X was a full‑blown demo, so, yes, it's kind of like Commerce kickstart in the fact that there's the 1. X version where it provides a distribution of modules, and, no, because it's not a full demo, it's more so to be, like, a package platform that lets you get up and running.

>> SPEAKER:  Thanks.

>> SPEAKER:  Any other questions? 

>> SPEAKER:  I'm not seeing any questions in Slack or in the Zoom chat either.

>> SPEAKER:  I see, Sheila, it shows you have your hand raised.  Did you have a question?

>> SPEAKER:  She's our captioner.

>> SPEAKER:  Oh, okay.

>> SPEAKER:  Matt, um, one thing that we had discussed in the planning retreat for this entire Commerce was the idea that the API could be self‑documenting, right?  So, you'd essentially install the distribution, have a full JSON API and then be able to point an application at that to basically navigate and browse the API.  Is that right?

>> SPEAKER:  Yes.  I should have added that.  So, there is a specification called open API, and open API is a mechanism for documenting your API and building documentation out of it or even clients.  Mateo, who first created JSON API, um, has maintained the open modules, and those come pre‑installed, and you can actually browse your documentation in a tool called re‑doc.  If you've worked with the CMS module at all, it uses the same, um, they use the same kind of documentation as well.  Oh, um, I see Joe had a question about the modules being, so, Joe's question is if any of the JSON API modules we've contributed are being considered for addition to Drupal Core, and I would like to put that up as a big maybe.  Parts of them will be.  I have been, all of this development, I have been talking to Whem, Gabe, and Mateo, since they are the API first containers, and have their support and they've answered so many questions along the way.  JSON API resources was in collaboration with Gabe, and my goal is to get as much of this into Drupal Core as possible.  I've got a giant list of Core issues to work on for Drupal 9.1, since Drupal 9.0 will have no features, so I've got a busy summer schedule to try to improve Drupal Core, so that way, a lot of this can make it into Drupal Core.

>> SPEAKER:  Can I ask a question?

>> SPEAKER:  Yeah.

>> SPEAKER:  Can you hear me?  Thank you for the presentation.  Sounds great.  Um, I'm interested in, um, the question does it affect, um, the normal HTML stores in Drupal Commerce in some way, or is it a parallel, um, development, or does it affect it somehow?

>> SPEAKER:  Um, so, actually, it makes it better.  So, it won't hurt anything, but one way that it actually helped is in Commerce, we have a, we call it the availability manager, which lets you check if a product can be purchased.  Previously, the add to cart form never really integrated with that, you had to use the stock module, and through the API work, we got that integrated at a data level layer, so if your product was available at a store, you had to do, like, extra logic on your end, but now, it just works.  So, a lot of the API work is improving the Core feature set that a normal installation would look like.  None of the decoupled work will ever take away from that.  A lot of times, it will just help strengthen its features.

>> SPEAKER:  And Mateas, there's the Commerce demo module and theme that kind of installed out of the box will give you that Commerce kickstart, um, 2. X styled demo at least, and then starting point, you know, we just wipe out the demo data.  Um, the quickest way to kind of take a gander at that is to go to Simply Test Me, and then there's a Drupal Commerce button, like, on the home page, and if you just click that, it'll install the whole demo store.  So, yeah, like, our focus, at least for what we're trying to build, I guess as a product out of Drupal Commerce, will be headless Commerce applications, but the spill‑over impact will be, like, as we make modules part of the, um, the system, their APIs will be improved, their feature sets expanded, and I know that Matt and Jonathan on the call have done a lot of work lately in, like, commerce shipping, just doing a lot of work to the module that improves it even for, like, a full‑stack usage, but specifically because our headless customers needed, like, something for creating shipments, collecting shipment rates, all that kind of stuff.

>> SPEAKER:  My customer scenarios, for the time to come, there will be HTML‑based stores, but the goal is to grow into the decoupled solutions over time, and I have to decide which way to go, because there will be HTML stores, classic HTML/CSS Drupal Commerce solutions for a smaller business right now.

>> SPEAKER:  Mm‑hmm, and that's where I would say the regular HTML stores, the full stack is the easiest way to go, because you're working with twig and HTP, whereas the Javascript, you're now having to reinvent a lot of things.  One example, and I talked about this in previous times, is when you have a, let's say you have a t‑shirt that has red, blue, and green, small, medium, large, you have to write in your Javascript how to determine what variation they're purchasing based off those attributes, where we've already written that P code four years ago, and that's, when I brought up that react reducts binding, it's going to try to do some of that code in Javascript, so, definitely, Drupal full‑stack with Commerce is a great, like, get it done, but once the, if the needs of the business require it right away, I would go for decoupled, or if it's something that you could slowly do progressive decoupling and then move to a fully decoupled.

>> SPEAKER:  Mm‑hmm.

>> SPEAKER:  And just so everybody knows, when I say progressively decoupled, that's where Drupal is serving everything, but you put some components in, like, a decoupled fashion.  One example that is our cart fly out module, it takes add to cart and then, like, the cart block and puts it into Javascript, and that right there saves performance, but also gives, like, a zippier user experience.

>> SPEAKER:  Looks great.  Sounds good.  Cool.

>> SPEAKER:  I'll answer Jonathan's question quick.  If the Commerce API is feature complete, what features are on the roadmap?  It is not API complete.  For instance, for checkout, you can rate your shipment, you can set the shipping address, but you can only collect payment through an off‑site payment gateway, such as PayPal checkouts.  Work needs to be done to support what we call on‑site payment gateway, where, like, when you give Brain Treat your credit card, they give us a token, and we need to build the API to receive that token and create the payment for you.  When it comes to cart management and fetching products, I would say it's API complete, and features are to be determined.  We have basic wish list integration coming, and we will be working on more, um, and if you do have ideas or questions, every Tuesday and Thursday, we hold office hours in the Drupal Slack in Commerce channel at 11:00 a.m. GMT minus 2, or plus 2, and then at 11:00 a.m. Central, which is GMT minus 5, so that's where you can come ask those questions too.  With that, I think we're now officially out of time.

>> SPEAKER:  I think we are on time, yeah, and if anybody wants to hang out for a little bit here, that's fine, or if you're going to be on the, um, the next session in this room, you can stay, and, um, I need to kind of hang out and wait for our next host so I can give them host privilege.  Thank you, Matt and Ryan.