 Go ahead and get started. Sorry. Whoa. Okay, testing. All right. Everyone can hear me? Okay, awesome. Thanks for coming. Uh, we're gonna talk about, uh, Magento and Drupal at scale. We're gonna talk a little bit about the project that we used to, um, to do this. And then go into some technical details of, uh, why, how, and how exciting it is. Uh, my name is Justin. I'm the CEO and co-founder of Third and Grove. I'm joined by Mike DeWolf, our director of engineering, uh, and the first engineer that we had at Third and Grove. Uh, okay. So, uh, we're gonna talk about three things. I'm gonna tell you a little bit about the project, we did this for Quicken. Um, I'm gonna explain technically how we came to the conclusion to do it with headless Magento. And then, um, we have some tips, uh, if you ever want to combine Drupal and Magento for this kind of digital experience, some technical, uh, integration tips, um, uh, uh, for you. Okay, so, what the heck is Quicken? It is personal finance software. So, it's similar to Mint if you have a Mint.com account. It connects to all of your bank accounts and your financial information, um, pulls all that in and tells you you're spending too much money at J Crew if you're me. Um, and makes you feel bad about that. So, um, it's a really great way to just kind of like see into your, your financial pattern. It's regular desktop software. Um, it was Intuit's first product. Intuit, the company that makes TurboTax. Um, it's kind of like the Windows for Microsoft. It was really the first product that launched that company. It originally came out in the early 80s. It's one of the oldest technology company and brands that's still around in the valley. So, what happened is that they, uh, Intuit, they decided to divest Quicken into an independent company. So, Quicken's a multi-billion dollar company. Um, Quicken is smaller by comparison. Intuit has lots of different business units. Um, and they decided to sell it and make it its own separate company. So, all of the sudden, Quicken had to divest itself from a whole bunch of technology, everything from data warehousing to marketing automation to CMS to commerce and, and all that stuff. A majority of their sales are through, um, their website. So, Ecom was a really, really critical component. So, what they had before was this really terrible, um, Oracle Ecom platform called ATG. It was really old. Um, it was highly customized. They weren't able to update it anymore and releases took two weeks to do to production. And where they wanted to get was something where they could release rapidly, um, and put together Drupal and Vigento as sort of a single, a single platform. Um, but they really just wanted to get to, um, whatever the technology stack was, a place where they could do, you know, deployments rapidly. They had full control. Um, it was robust, modern, had good connectivity and integration. So that's really where they had to get to. Um, so, uh, the first thing that we did was technical discovery with the team to try to figure out all of the touch points that their Ecom data touches. And much different than CMS Ecom touches a ton of different systems. So, you're, you're, you're looking at payment gateway, order fulfillment, there could be sales force, CRM integrations, there's ERP, there's accounting, there's finance. Essentially every department in an organization can want some kind of touch point with an Ecom transaction. So you've got a lot more complex ecosystem than when you're thinking about a marketing website experience. So for Quicken, the really, the key requirements were, um, you know, leave the front end experience the same. They were already on Drupal at the, at the time they needed to build their store. Security was paramount. Quicken can't have a security issue because they, as a product, connect to your bank. And if there's a story in the New York Times about how Quicken's website was compromised, um, that, that really has a material impact on the value of their brand, which is their entire business. Security was key. Marketing wanted more control over promotions. They didn't have that with ATG. They had to plug in with systems like Arvato, Braintree, Avalara, Salesforce, NetSuite, lots of different backend systems they wanted good, robust integrations for. They wanted to make sure that they were good partners. I could support the technology. Um, and, uh, they had a crazy timeline of four months to, um, to move this nine figure store online. So why we recommended, uh, Magento II to the client and why they ended up choosing it. One is the ecosystem. So Magento's open source, I don't have to say the power of that to this group. It's PHP. Has a, a large ecosystem of folks that can support it and work on it as a technology. It's not niche by any stretch of the imagination. Um, Magento has great integration support. So out of the box and with extensions, you have a large ecosystem of, um, of things that you can use to plug Magento into all those backend systems that they, that they needed to integrate with. It's highly available. It's highly secure and it has great Salesforce integration. Um, so, uh, one of the questions is probably why didn't we look at Drupal Commerce for this? Or why didn't we pick Drupal Commerce for this? So we did look at Drupal Commerce as a solution. Their existing site, quicken.com, was and is Drupal. It would make sense to plug that in. There are really two sort of key points that didn't really make it a viable solution. One was integrations. The integration landscape for Drupal Commerce is, um, really very small compared to a mature e-com platform like Magento. So you're looking at a tremendous amount of additional work and more work is, is more bugs. Um, and the other big piece here was scale. So this is about 80, 90% of this company's revenue. It's nine figure revenue. This is a massive order, uh, number of orders per hour, per second, per minute. It's a lot of scale. They do a lot of their business on Black Friday. They do a lot of their business on one tax day in, in March to prepare for taxes. So, um, this is a, uh, a highly, um, volatile traffic level and it needed to be a solution that had sort of a proven, um, ability to scale. The other thing is that, um, so I'm, I, I really like food and I eat out a lot, but I have a rule where I don't eat at a restaurant that does two cuisines. It's my two cuisine rule. So if it does Italian and Japanese, I'm not going to eat there. And the only exception is fusion, but fusion is kind of a separate cuisine, right? So, so the reason I don't do that is when you try to be good at Italian and Japanese food, you're bad at both. So, and this is the same thing with, with engineering. So if you look at YouTube and you look for the car boats, um, that everyone tried to build in the fifties, they want, the idea was like a boat, you put your, uh, a car, you put your family in it on Saturday, you go drive to the lake and you literally drive into the lake, not for any nefarious reason, but because you're going to now go boating in your car. And when you try to make a car that's a good car into boat, you get something that's a really shitty car in a shitty boat. So it's hard to be good at two things. Um, and that really is, um, how we think about technology. And so when we think about a really great experience platform, we think Drupal and when we think about a great econ platform, we want a tool that's focused on e-commerce. Okay. So technical architecture, um, why did we go headless and how does it actually look like? So, um, the, uh, infrastructure or the architecture that we use for this is headless magento. So Drupal serves every interaction to the glass, uh, uh, Drupal serves every, um, interaction to the glass and it communicates to magento as it needs to via, uh, an API. So there's never magento is, is never serving a front end experience, uh, page. So we have primarily two, um, different kinds of synchronization going on. So in the absolute necessity times when we need a real time call to magento, we do it, but everything else, product, information, uh, you know, images, SKUs, pricing, everything that we can, um, is synced in the background, uh, periodically both when changes happen in either system and also just in a regular basis to keep the information fresh. Uh, we cash everything we possibly can in Drupal. Drupal has a great caching system, very robust, very scalable, um, compared to other systems. So we cash a lot in Drupal. Um, we, we did need that scale here. Um, but like I said in those, in those, uh, instances when we couldn't get around it, we did, um, how we do, we do make real time calls. Uh, the magento API is in two, in magento two is really robust. It covered 80 to 90% of our use cases. It's really, really good. Um, when it didn't, it was usually us wanting to chain sequences together. So to do, uh, you know, add something to cart might, might have taken three API calls out of the box with magento API. Um, so we just extended the API, which it's designed to be extended like, like Drupal is, um, and made that one API call. So little optimizations like that go a really, really far away, um, for, for the scale that we needed for this, uh, for this kind of thing. We also separated the data between the two systems and we try to, whenever we do this with clients, we try to mirror based on, um, their organization. So marketing data that Drupal is good at lives in Drupal, things like price skew live in magento. Those are synced between the two systems. You only edit it in one place. It's very clear where that line is. Um, and it's really easy to know where, um, where you need to go to update, um, uh, that, whatever information you want to work on. Um, so there were a bunch of benefits here. One with a headless magento, there's one theme not two. The theming layers aren't compatible. Um, you can do magento serving like the cart and the checkout pages. You have to maintain, build, test, um, and deploy two themes simultaneously with a headless magento. You only need one theme in Drupal to test and, and make great, um, nice decoupling of front end and back end experience. You can roll out updates to magento or Drupal separately as long as they're not, um, as long as you're not doing something that involves both systems, you can do a Drupal update and you don't ever have to touch magento, um, in that release. Um, so you can parallel track things with a modern system and a modern platform. They're on, they're, uh, they're on aquea. Um, and from a security perspective, because magento's headless, it's, uh, off the public internet. So you don't actually have to make magento accessible. The only thing magento needs to be accessible to are API calls from your known servers of where your aquea, or where your Drupal instances live. It's on aquea, so from those servers. Um, highly secure, right? You can't make a magento site more secure than taking it off the public internet. So that was also a huge thing. Um, and so I really won over most of these. I think, um, there are a couple of different ways you can do headless and you can do side-by-side. There's no answer to every situation. It was just in this particular use case. Headless made the most sense. Security, like I said, was really the big massive win here of why we, why we chose this. Um, we didn't want to continue to leverage Drupal as a great CMS and the team was used to that and it was, it has a really good robust support for that. Um, but then also there was some uncertainty in the business in terms of where the product was going to go. So they knew they needed to go to subscription from, uh, Drupal. They didn't know when that was going to happen. So a nice decoupling between your front-end experience and your e-com experience would make it easier if they needed to, uh, dramatically replace, extend, uh, whatever that, that e-com component. So with a nice decoupling at what they, they're not going to have to re-implement their front-end to, to potentially re-architect something on the back end, uh, in a couple of years when their, when their business changes because, um, their business plan is to fundamentally change their business model and they had to support it. Um, and, and how's it related, uh, trailblazers here, it's the largest magento two store in the world by order volume. The site has stayed up. It's, um, sustained all the levels of traffic and the, um, uh, uh, and the integration has stood sort of enterprise scale. Okay. So now I'm going to hand it off to Mike and he's going to talk about some tech stuff. Sounds good. Hello. So as Justin mentioned, my name's Mike DeWolf. I'm our director of engineering and, uh, tech lead on a lot of these integrations. And I'd like to walk you through a little bit of, uh, some of, some of the things that we're approaching, a headless integration with a platform like Magento and Drupal. Um, so the first decision to make when starting a project like this is whether you're going to go the full headless approach like we did for quicken.com or whether you want to do a side-by-side approach and there are pros and cons as you would imagine to each. Um, headless as Justin mentioned is highly secure. There's less of an attack vector because less of the, um, surface of the website is exposed. You don't have to worry about monitoring as much security between two platforms, um, especially if you can take Magento off the public internet. Um, there's one platform to theme, which is easier up front and also easier as global updates roll out. Um, that can turn into a headache if you're theming in two randomly different platforms that have different templating systems. Um, you can end up with weird discrepancies between the two sites that disrupt the customer experience kind of inadvertently. Um, another key point of doing headless is you don't really have to worry about, um, oh, does this thing I want to change live in one system versus the other? That being said, um, by using Magento in this way, we immediately write off the ability to use certain Magento systems. Um, you don't really have to worry about that. Um, you don't really have to worry about that. Um, you don't really have to worry about that. Um, you don't really have to worry about that. Um, you don't really have to worry about the ability to use certain Magento extensions that have a front-end component. So if there's a Magento extension that can drive a really elaborate check-out, um, we, we can't use it because we have to recreate that in Drupal. So it's an important consideration when you're thinking about this, is how much do you really depend on perhaps something that Magento can offer to you for free, because if you do headless in that case, um, you'll have to recreate that functionality in Drupal to, to some extent. Um, and also, um, even Even though Magento has a very mature REST API, the REST API for Magento was not specifically designed for this use case. As Justin mentioned, there are some customizations that we'll recommend. And I'll talk about that at a later slide. But if you do side by side, then you really are using Magento in the full capacity, like, exactly as it was intended. So we have a list of questions that we usually go through when trying to answer this question with a client's project. And I won't necessarily go through all of these. But I would highlight the most important ones. Number one is if the client has a very complex product type. I'm thinking, like, a very complicated build-a-basket type product. Or I think of a classic example, it would be like a pizza, where it's very, very configurable. It's probably going to be easiest to use some of the Magento extensions that exist in the community versus having to build all that functionality in Drupal and then to communicate it via a REST API. So that would be one use case where there's really this compelling reason to put some section of the website in Magento with it serving those pages. And hopefully you can organize your site in such a way that you can proxy certain paths off to Magento and certain paths off to Drupal. A common implementation in that case might be that all product pages are in Magento and the checkout is in Magento. But the blog, landing pages, various marketing materials live in Drupal, and we have a nice split that way. But if you don't have a complicated product, if your store just has simple products or products that are configurable to some extent, but not terribly complicated, like a t-shirt that has different colors and sizes, that can be done quite easily in Drupal through a model I described. Another situation where you might want to consider using side by side is, again, the checkout is highly customized. And this is for the same reason. There may be situations where using a Magento extension is going to be much easier than recreating all this in Drupal. And other than that, there's other questions we ask. A lot of it has to do with how content-driven the website needs to be. If the website isn't that content-driven, it almost makes you wonder why we're using Drupal in the first place. So there's a lot of questions that we need to ask to answer this question. Most of the time, for the vast majority of stores, the headless model works. And so it comes down to preference. As you'll see, we have a little bit of a decision matrix here. So it's complicated products. And highly custom checkout are really the main reasons to go with side by side in our estimation based on going through this. But Drupal will generally do best at anything content-related, personalization, editorial workflow. And so as much as you can bring these rich editorial features to the e-com experience for the marketing team by going headless and having a lot of your product information actually being Drupal, it creates a better experience for editors. So once we've made this decision, headless versus side by side, Justin alluded to the process of figuring out, so we have these two systems that have two different data stores. We need to figure out what the source of truth is definitively for the different points. And we have found through doing different integrations, not just with Magento, but with other e-com backends, that this is a time to sit down and figure out what the client's teams do. What is the marketing team edit? What is the fulfillment team edit? And that's usually the perfect sweet spot for how to separate the functionality. At the end of most projects, we can look back and say, see how well we did, basically, by the one measure, which is, do these two teams operate independently? Or do they need logins to both systems? If the fulfillment team can edit mostly everything in Magento, but they have to go to Drupal for one random thing, we feel like that has been, we've compromised a little bit of the usability of the system. So typical breakdown, like you see here, would be UPC, price, stock level, certain legal data. For example, a product that might contain hazardous materials. This could all live in Magento and be sourced from Magento. And then in Drupal, where we have the product, that would have product description. That would have product images, SEO keywords, promotional slides, that sort of thing. The type of content that would go through an editorial workflow, essentially. So I'll walk through a couple just tips that we've learned through doing these integrations and kind of remembered to do now moving forward. So first one, this is very important. And there has been a time on every integration we've done where, for whatever reason, the econ back end was down for a period of time. It could be that a third party provider, such as a payment gateway or a tax service, was having issues. And the store was throwing 500 errors. And one big advantage, for example, on a site like quicken.com, is that when this happens, because we have decoupled our front end, we can preserve the customer experience throughout the outage. So it's in a limited fashion. They can't check out. But there's not a huge disruption. Quicken.com doesn't go down. You can still browse the catalog. And so it's very important when building an integration like this to build into your architecture the ability to do this and to think about, and have the client you're working for, think about what they want the experience to be. A common use case is that we'll show all the product pages, but the add to cart form will disappear for a second until the outage is resolved. Maybe on the checkout page, we do a redirect or we have some messaging. So this needs to be something that the team can turn off if they need to. Or anytime there's basically a bottleneck. So it needs to be thought of and built into the system. Oftentimes in development, we're so focused on the happy path and we just kind of focus on this front end and we don't think about when things go wrong. Another thing we found, in certain cases, we needed to bypass Drupal's form API. Now most of the time, I would never say this, but we had a lot of displays in all these stores that we've done. They're very common where you have, let's say a grid of product thumbnails and each thumbnail has a little add to cart form on them. And what you end up with in those situations are something like 20 forms on a page that you're trying to cache. And in these situations, you can run into storage issues, loading down many forms, especially when someone's just browsing, they're not using all the forms. So we've actually found it better in some cases, select cases to change those to be kind of embedded forms that will make an Ajax call to an endpoint. And it will just help the system scale better and the site as a whole to be more cacheable by a CDN or a varnish layer. Make your product structure a plugin base. This applies mostly to headless. So when doing this split between a marketing kind of display product and then this e-commerce entity that has data like skew, price, you want to have the ability to create different types of products. So if you imagine a typical product page, the simplest product in the world like a duffel bag or a suitcase that comes just in one variety, the add to cart form is very simple, just a button. Then we can go into a configurable product. This has a parent product, but then it may have five different t-shirt sizes. So the add to cart form on that page becomes a little more complicated. It still has the button to add, but you need to have a dropdown with those five child skews. Likewise, the logic at checkout is slightly different. The simple product, we just send the skew to Magento and it's a very simple transaction. For the configurable product at checkout, we need to send a bundle that has the parent and the selected child. So we decided in order to accommodate these different types of products and they get more complicated and groups bundled, we thought a plugin base was perfect because we could plug and play basically any type of product and all we needed to do in our plugin was define the form on the add to cart page and then define what sort of API logic needs to happen at checkout. So it fit the plugin model perfectly. Very similarly, making checkout logic the same way. Most checkouts are exactly the same on most stores, but it's got similar components. So if we think of a typical checkout flow, there's a shipping form, there's a billing form, and there's a payment form, and that's it, maybe a confirmation, three steps. But it follows the same principle. If we look at each of those steps in isolation, there's a form and then there's a submit logic that makes an API call. So by building those checkout steps using a plugin based architecture, we're able to accommodate the use case where somebody needs a fourth step where we add text for a gift, gift wrapping something and adding a special message or maybe it's a t-shirt that has a customizable, something customizable printed on it. So by doing this plugin architecture, we're able to accommodate customizations for the checkout flow and Drupal. So another recommendation we have is to use a conductor. Anytime a payment is processed, especially on quickin.com, there are numerous events that happen right after in integrations with other systems. So an example would be we need to update the warehouse, ERP systems, there is a confirmation, that email that goes out, probably through a third party service. So all these things don't necessarily have to happen in Magento, and we recommend that they actually don't, and that you use some sort of middleware to process these things, because they're non-essential to the actual processing of payment. And by using a conductor, an outage in one of these systems will not jeopardize the payment itself. And so we also recommend in a conductor to use kind of a Q-based architecture, like RabbitMQ, so that if there is a failure in one of these external integrations, the instruction to, for example, email the customer, confirm email, is not necessarily lost, and it will continue to preserve that it has that instruction to do that. Justin mentioned needing to customize some of the Magento API calls. So out of the box, Magento needs separate API calls to add a promotion, to add an item to the cart, to look up a customer, to add a shipping address to the cart. These are all different endpoints. We found that sometimes to process certain steps, so to process like a billing address form, we ended up having to make two API calls. And that added latency to the process. So we highly recommend, if you're working with Magento, to customize and consolidate those API endpoints into one thing that can perform all the functions you need with the information you have. And you can usually almost always get away with one API call per checkout step, if you're doing a multi-step checkout like that, which is going to speed up your performance a whole lot. And my last slide is to thoughtfully plan a cash strategy that leverages edge caching. It's very important in these sites that are econ-based that as soon as a customer adds something to their cart, and the website becomes dynamic, i.e. probably in the top right corner, there's maybe a cart overlay that they can see, that you don't sacrifice the caching of your pages as a whole, and you think this out. One common way we've implemented this is using a local storage or a cookie to store a cart that can be invalidated by an Ajax call, and basically be turned off. And that's a very important thing to do, because as you can imagine, if all of a sudden the page becomes dynamic, the customer has something in their cart, and we are serving them cold pages, the whole site slows down just because they have something in their cart, and the user's like, what's going on? So it's very important to think about how everything can be cached using local storage, and then you leave it to small Ajax calls, and then probably the checkout flow that will bypass the cache. And so if you design it in that way, it'll be very CDN friendly and a very zippy experience. We have a white paper, and if you wanna check it out, it's thirdengrove.com, Drupal Magento. We talk about some of the things we talked about today, and other than that, we'd love to take some questions.