On this sponsored podcast episode, Ben and Ryan talk with Filippo Conforti, co-founder of Commerce Layer, an API-only ecommerce platform that focuses on the transaction engine. We talk about his early years building ecommerce at Italian luxury brands, the importance of front-ends (and micro-frontends) to ecom, and how milliseconds of page load speed can cost millions.
SPONSORED BY COMMERCE LAYER
Around the world, billions of people can sell their wares online, in part thanks to solutions that handle the complexities of securely and reliably managing transactions. Businesses, large and small, can sell directly to customers. But a lot of these ecommerce services provide a heavier surface than many need by managing product catalogs and requiring inflexible interfaces.
On this sponsored podcast episode, Ben and Ryan talk with Filippo Conforti, co-founder of Commerce Layer, an API-only ecommerce platform that focuses on the transaction engine. We talk about his early years building ecommerce at Italian luxury brands, the importance of front-ends (and micro-frontends) to ecom, and how milliseconds of page load speed can cost millions.
Conforti was the first Gucci employee building out their ecommerce, so he got to experience life in a fast-moving startup within a big brand. When he left five years later, the team had grown to around 100 people.
The ecommerce space is crowded—one of Commerce Layer’s recent clients evaluated around 40 other platforms—but Conforti thinks Commerce Layer stands out by making any web page a shoppable experience.
Conforti thinks composable commerce back ends that neglect the front end neutralize the benefits. Commerce Layer provides micro-frontends—standard web components that you can inject into any web page to create shoppable experiences.
Getting your ecommerce platform as close to your customer makes real monetary difference. A report from Deloitte finds that a 100ms response time increase on mobile translates to an 8% increase in the conversion rate.
Thanks to Mitch, today’s Lifeboat badge winner, for their answer to the question, How to get all weekends within a date range in C#?
[intro music plays]
Ben Popper Hello, everybody. Welcome back to the Stack Overflow Podcast, a place to talk all things software and technology. I am your host, Ben Popper, joined as I often am by my colleague and collaborator, Ryan Donovan. Hey, Ryan.
Ryan Donovan Hey. Good morning, Ben.
BP So today we have a sponsored episode from the fine folks at Commerce Layer, and we're going to be talking about a bunch of stuff that is interesting to developers, micro front ends, APIs, and how you can sort of inject commerce into whatever it is you're doing, whether you have an online shop or maybe you have a different kind of app, or maybe you're just building a swag store like we do at Stack Overflow which is just one little part of our business. So I would like to welcome our guest today, Filippo Conforti. Filippo, welcome to the show.
Filippo Conforti Thank you. Hey, Ben. Hey, Ryan. Thank you for having me.
BP So the first thing we always ask guests is just to let the audience know a little bit about who you are and how it is you got into the world of software and technology.
FC Sure. So I was born in Florence, I'm Italian, and I graduated in Florence in computer science in 2004, long ago. And I got passionate about e-commerce right after graduation. I created this small studio, the typical designer and developer studio here in Italy, and we were building web applications in Ruby on Rails. Ruby on Rails was just released.
BP So hot back then, yes. It had its time to shine.
FC Yeah. And so we used to create web applications with Ruby on Rails and especially e-commerce websites, so I started building e-commerce websites from scratch with Ruby on Rails and understanding all the mechanics of building e-commerce, like with payments, orders and things. So then in 2011, more than 10 years ago, I was hired by Gucci, the Italian luxury brand. They had built an e-commerce website in the United States with Ruby on Rails and they were looking for someone who could take charge of that platform and evolve that platform and I was one of the few in Italy who had some experience with Ruby on Rails and with e-commerce and so I was hired for that reason, essentially.
BP I have to stop you there. Was that a really fun job to have? I mean, to work for this world renowned luxury brand and to be headquartered in its hometown or in its home region?
FC It definitely was, because especially in the early days of e-commerce in Gucci, it was still the early days, I was lucky enough to work in a startup-like environment within a big brand so I had the best of both worlds, having the possibility to travel and visit the world for a brand like that, and at the same time, to work in a startup-like environment with a very small team. I was their first hire in Italy, and so when I left, fast forward to 2016, end of 2015 when I left, the team was about a hundred people. So it was really a fast growing team within the group so it was very fun. And then I spent five years in Gucci. I also met my co-founder, Massimo Scardellato, in 2012 at Gucci. We were responsible for building that and scaling that platform. So then the Ruby on Rails homegrown solution, the company decided to replatform it to a more standard solution for the time which was Hybris, so we had the possibility to work for this big replatforming project and we learned a lot about how difficult it can be. And so we came with this idea of doing things in a different way, and that's how the idea of Commerce Layer was born, to separate the business logic of your e-commerce platform from the presentation of your website.
RD It's interesting. So let's get into the e-commerce API world. I have a little bit of experience writing docs for some e-commerce companies, the dear departed Molten and back at GrubHub. I'm curious what is a specific problem that you all are trying to solve and what does the sort of landscape of e-commerce technology look like right now for developers?
FC So when Massimo and I decided to design this solution, the model of Commerce Layer, we decided to focus on the transactional engine of e-commerce. E-commerce can be very complex and there are many parts that can make an e-commerce experience. So what we do is, one of those parts, arguably it could be the most important part because we manage the orders, we manage the sales, so it is something that becomes the engine that allows you to actually get orders from your website or any experience. So Commerce Layer is an API-first platform. It was actually born as an API-only platform and we started building commerce APIs and WebBooks, and today we count more than 400 APIs and more than 100 WebBooks. So this is the core of what we do, which is decoupled not only from the presentation layer, but it's decoupled from all the other components of an e-commerce platform. For example, by focusing only on the transactional engine, we decided to leave all content outside of Commerce Layer, including the catalog content. When you work with an e-commerce platform, you typically find the product catalog in the e-commerce platform whether it is headless or monolithic. But we decided to focus on transactional engines, so this allows you to really connect and to transform any experience into a shoppable experience because you can really manage your content and your catalog with best in class tools like a CMS or a PM if you need a PM for your organization. We are the API that allows you to make that shoppable. So in the ecosystem there are many e-commerce platforms. One of our recent clients, Rafa, that we signed recently, they told us that they evaluated 40 different platforms which I wasn't even aware of.
BP Wow. Due diligence, yeah.
FC Yeah. And again, I wasn't even aware that there are 40 different solutions, so it's difficult to classify the different solutions, but I will try to do that. From my experience, there are those platforms like Shopify that are great to start and are very simple. You get the simplicity, but you need to adapt to what the platform gives you because you don’t get all that flexibility if you need an additional level of flexibility. So if you are a growing brand, if you have more specific requirements that always arise when you start growing, you need to look into those enterprise-grade platforms that become much more complex and expensive like Hybris. I have direct experience with Hybris, but also with Salesforce and Magenta. There's two types of options that have pros and cons. But again, you either have to settle for a simple solution, but inflexible, or on the other side for a flexible but complex solution. So we try to stay in the middle to provide functionality that is enterprise ready, but without sacrificing the simplicity of our solution.
BP Yeah, that makes a lot of sense. So walk me through either a hypothetical example or one with a client. They started small, the brand started growing, they wanted to scale up, but they also either didn't want to get entangled with a big enterprise thing or they weren't ready for that, or they needed to make that transition. What are the solutions and tools you provide and how do they work with whatever technology stack that customer is coming to you with?
FC There are different examples, I can give you some of those. Some clients come to us and they want to build a new stack from scratch. Whatever their existing solution is, they want to build a new stack, a composable stack. One of those example is Brioni, which is another luxury brand, and they created a solution with the help of an agency. They created a solution built with Commerce Layer content for Algolia in a Jamstack website. So it’s a very clean architecture, a Jamstack architecture, they had this possibility to start from scratch. In other cases, so I think of another example which is one of the fastest growing brands in the UK. When they migrated their commerce engine to Commerce Layer, they were already into the say composable journey, because they already had built a composable stack with a headless CMS, and they used Shopify to manage the transactional engine. Actually, they were using five Shopify instances to manage five different regions. And so they decided to migrate from Shopify to Commerce Layer, starting by doing that region by region so they did it incrementally and they replaced each Shopify instance with one Shopify market in Commerce Layer and then they expanded to 30 and more countries.
BP That's interesting that you can do it incrementally like that and test it out region by region. You can sort of see the differences and see what works. It's nice to be able to do that kind of A/B testing and not have to move everything at once.
RD Yeah, you can see the actual results.
FC Yeah, you can see the actual results and you can't stop your business while you are migrating and evolving your platform. Sometimes we say that with this approach you will never do a replatforming again, and I mean, you don't need to do the last replatforming of your life. You already have done the last replatforming because now you can progress incrementally. With our micro-front ends approach, you mentioned also that we provide APIs and we provide micro front-ends on top of our APIs. These micro-front ends can be divided into six groups. One is the pricing micro-front end, then the availability message of a product is another micro-front end, then the buy button, cart, checkout, and my account. These six micro-front ends are the functionality that allows you to either transform a website into an e-commerce website or do the migration step by step. So another example of some of our clients, let's say a customer who is on Salesforce Commerce Cloud. They're looking to migrate and to walk away from Salesforce Commerce Cloud, but they want to do that step by step. With our micro-front ends approach, you can take the existing website entirely from the client side. You can start replacing the price, the buy button, availability message with Commerce Layer. And when I say entirely from the client side, I really mean without touching the core code of the platform. You can do that with Google Tag Manager. You can do that really on the client side. And speaking of testing, someone is pushing this testing to the point that they are A/B testing the current checkout, the current transactional engine with Commerce Layer and they are measuring the results and they're making the choice based on real data. So you don't make a big project and then you evaluate in four or six months from now. You actually get the results right now. And when Commerce Layer performs better than your current solution, you're getting more orders right now, and you are more confident in doing the switch and moving the entire commerce engine to Commerce Layer.
RD Yeah. You talked about the micro-front ends a little bit. What exactly are they? You talked about doing API-first. Are they actually API served? Are they pieces that somebody can copy and paste in? How does it work?
FC First, there are two different types of micro-front ends, some of them are less micro than others. So I’ll give you two examples– the price, which is one of the micro-front ends that you provide, and those micro-front ends are web components, standard web components. We're using Stencil.js to build those web components so they are framework agnostic and you can inject those web components into any page to provide a price for a product. With the same approach we provide the availability message web component, and so you can inject that availability message element into the page and provide an availability message, and the add to cart is another example. Another group of micro-front ends that are less micro are the cart, the checkout, and my account. These applications are applications that we have built with React. We also provide a library of React components, and these are open source applications that we provide in a hosted version so if you want you can just use our hosted checkout like you do with Shopify and you're done, you have some level of customization that you can apply to the styling of the checkout and you're done. But otherwise you can decide to, for the checkout application, make more changes, or you can decide to take it as a reference and design a checkout experience and build your own using our same APIs. And also these applications have web components, let's say the cart web component, which is a component that injects a cart into a page, or maybe you can use the cart link, that is a link to a hosted cart page. So again, with these tools, with these micro-front ends, with these web components, it is very easy to transform any page into a shoppable page. One of the best demos that I like to do, we don't have a video, but you can just take an HTML page, store that HTML on your local machine. You can just drop our JS library and you can just tag that page with very simple HTML elements and you have a fully functional international e-commerce website built on a single HTML page in five minutes. That's very powerful.
BP Yeah, I was just out at the Next.js 13 announcement at their conference or whatever, and it's really fascinating to me the relationship between the client on the front end and the server and the way, especially in React, components are increasingly functions and a lot of what you're describing is the ability to say, “Maybe we'll give you a buy button and this piece of your puzzle, and you'll try a few of our pieces out here,” and essentially they are already built by you. They have an API that's serving a ton of functionality into it, but the person who's doing it on that front end is almost composing it, like you said, as if it was HTML. Well, I want to add your buy button and see how that compares to this one, or your recommendation for which item should be shown next after this.
FC Correct. The DOM becomes your API, so you work with the DOM. The fact that there is an API on the server side that powers that web component becomes a technical implementation. From a user perspective, and with a user I mean the developer, developers are our users, you really use the DOM as your API and you just compose your page with HTML elements. And we talk a lot about composable commerce and the composability of the stacks, but very often we forget one of the most important parts which is the front end. If you build the monolithic front end and if you only have a composable backend, you risk denaturalizing many of the benefits of composable commerce. So we really believe at Commerce Layer that this composability should be built to the front end layer with micro-front ends. This allows the flexibility that allows better scalability and better developer experience and easier developer experience, because another thing that I hear a lot is that composable and headless is complex. It can be, but maybe with the right approach, it is not that complex, especially to start and to progress incrementally.
BP You've been talking a lot about adding different functionality and the ability to do testing and to monitor data and then move to your services if the results prove themselves out. I know in commerce speed and responsiveness is key. You want somebody to be able to click a button, see the thing, and make that purchase without having to wait or you've lost them. Where does your company and technology interact with speed at all? I know for a lot of this it has to be about pushing it to the edge and having a point of presence locally or whatever that may be, but is that something you interact with or does the client have to go somewhere else when they're thinking about issues like that?
FC No, it's definitely something that we care a lot about and we are aware that speed is one of the most important drivers of going headless, composable and approaching this type of development because from a business perspective, there is a direct correlation between the performance of your website and the conversion rate of your website. So if you keep everything else the same, same experience, same design, same catalog, same everything, but if you improve the speed, it's really demonstrated that it brings an increase in conversion rate. We were reading a report by Deloitte and they reported that you get an 8% increase in conversion rate by every 100 milliseconds reduction in page load speed. It's just a benchmark, just an idea, but there is a solution. And the performance is not just on the website. The performance of the checkout is very, very important because orders are abandoned at checkout. You start the checkout process and then you abandon the order, for many reasons, again. I don't want to oversimplify the reason why people abandon their cart. But the performance, the site speed is definitely one of those and so we embraced the Jamstack approach. We believe that the coding is going to, and should belong more and more to the edge, to the client side also for a performance reason. This is very important for any type of web development, but when you talk about e-commerce there is a very direct impact on the sales of your website compared to a blog, for example.
RD I think anytime you get involved in e-commerce you get into questions of security and reliability. Not only the PCI requirements around credit cards, but you want to make sure that any time a transaction goes through, any other further requests won't put the same request to go through. How much of that do you guys have to deal with?
FC Well again, a lot. Firstly, as a developer you care about this aspect, but you don't want those aspects to be your problem. And so this is what we do. We want developers to sleep well in the night and so we manage all these parts for the developers. Speaking of the checkout for example, if you use our API, let's say that we manage 80% of that part, but if you're building a custom checkout application, you're responsible of that 10 to 20% of the experience and PCI compliance scope. Because to be completely out of scope, someone else has to do that. You need to use our hosted checkout application, which is an option. But yeah, it's very important. And speaking of again, the Jamstack and security, especially when you build a static website, when you have a headless approach with a simple website that is exposed to the client, the surface attack is much more reduced compared to the entire platform that is exposed to the client. So again, also from a security perspective it's really reduced. And for sure, the vendors, the components that provide the API are responsible for the security of those APIs. We at Commerce Layer are responsible for the security of our API, but also if you compose your stack with other tools, each tool and each company should be responsible for their own API and you should trust them. So it's very important to sell components and vendors that can guarantee that level of security.
RD So we've been talking about what you all do now, what commerce looks like now. What are you excited about for the future?
FC One thing that I'm really excited about as a developer is, I'm excited about that developer experience that is becoming more and more important from a business perspective. I'm a huge believer in the fact that a happy developer is a more productive developer and can create better solutions, better digital products for their business. And on the other side, we are seeing more and more that the decision makers, the developers, are taking a significant role in the decision making process, and the decision makers are trusting their developers more and more. This makes me very excited. And also from a transitional perspective, now that you can work from anywhere, you can work for any company in the world, you really want your developers to work with modern tools because otherwise they will look for other opportunities and they will leave your company. So it becomes really that developer experience is very important to retain developers and to acquire new talent. But again, what makes me excited is that this is becoming something that is more and more relevant to the decision makers and to the business users.
[music plays]
BP All right, everybody. It is that time of the show. We want to shout out somebody from the community who came on and helped to answer a question or asked a really interesting question and contributed to knowledge. Today we're shouting out Mitch, who was awarded a lifeboat badge for saving a question with a negative score. Now it's up to a positive score. Appreciate it, Mitch. Awarded two hours ago, “How to get all weekends within the date range in C.” I would like to get all the weekends as well. If you want the answer, it'll be in the show notes. I am Ben Popper. I'm the Director of Content here at Stack Overflow. You can always find me on Twitter, maybe, I don't know for how long. I'll shout out my Mastodon handle soon enough. You can always find me on Twitter @BenPopper. You can always email us with questions or suggestions, podcast@stackoverflow.com. And if you like what you hear, leave us a rating and a review. It really helps.
RD I'm Ryan Donovan. I edit the blog here at Stack Overflow. You can find it at stackoverflow.blog. And I am also currently on Twitter @RThorDonovan.
FC I'm Filippo Conforti. I'm the co-founder of Commerce Layer. You can find me on Twitter for now, and on LinkedIn. You can also reach me via email Filippo@CommerceLayer.io. You can sign up, our platform is free for developers. You can sign up for free by visiting commercelayer.io. You can create an account. We encourage you to try our API, to try our platform, to sign up to our Slack community and ask any questions.
BP Yeah, I checked out commercelayer.io/developers, and you've got great docs and data models and API references there, so it's neat. All right, everybody. Thanks for listening. We appreciate it and we will talk to you soon.
[outro music plays]