Why Frontend is the buzzword of the E-commerce revolution

Hello, everyone, welcome to yet another Buddy webinar. Today we will talk why front-end is the buzzword of the e-commerce revolution. That's why I have a person who is, kind of, responsible for the part of this revolution when it comes to the e-commerce, all the storefronts Filip Rakowski. Filip, tell us a few words about yourself.

Hello, everyone, welcome to yet another Buddy webinar. Today we will talk why front-end is the buzzword of the e-commerce revolution. That's why I have a person who is, kind of, responsible for the part of this revolution when it comes to the e-commerce, all the storefronts Filip Rakowski. Filip, tell us a few words about yourself.

My name is Maciek Palmowski. I work here at Buddy as WordPress ambassador. And I'm also, I hope, your favorite webinar host and the only one so you don't have too much charge. So before we get started, let's sum up what we'll learn today. So first of all, we will talk a bit about different ecommerce architectures, we will also try to learn how to decide which one to use, and we will l also talk about why front-end is the most important part of the whole equation here. Also, if you like what we are doing, don't forget to press the "Subscribe" button on YouTube, And if you have any questions, use the commands on YouTube, LinkedIn or Facebook, and just ask them. We'll try to respond to them at the end of of this webinar. Okay, Philip, so you mentioned that bit that you are a co founder of the Vue storefront. And this is kind of interesting. Could you tell me how it even happened that at some point you decide, hey, let's build a storefront for headless e-commerce. And it was few years ago. So I think there was the headless revolution already starting, or it was just like a bit before it.

Okay, so like going back to five years ago, more than five years ago. So I'm in Devonta, in a software house, we are working mostly with Magento at that time, and the headless revolution is not there yet, definitely, like no one knows what headless is. Some people know but they are geeks. But no one really knows how to do it in scale, how to do this in production, etc. So we are doing this fundamental thing, and what is happening is a shift from desktop-first commerce to mobile-first commerce. And the problem that we have with this mobile-first commerce is that when you have Magento or any other popular back-end system, you have exactly the same page with exactly the same content just differently distributed, on a mobile device and on the laptop device. And you could imagine like from laptops and from desktop computers, CPU power was growing over time, the network network bandwidth, it was also growing over time, like issues with connectivity issues with CPU bottlenecks, they were not that much of a problem, really, everything was rather stable. Then we entered the mobile era, where people started browsing things on their mobile phones, and just the web was not adjusting to this, especially these old legacy platforms like Magento, that was serving exactly the same website for the ones that have i7 CPU and you know, 4G, I think 4G was, I think, at that time Internet, and to the ones that have very small phones in your pocket with a very weak CPU, and probably they are right now in the forest. So we're kind of trying to find the solution to that problem. But that was not the only thing truly, because it was very hard to find Magento developers doing front-end development. It wasn't a pleasing technology to work with, trust me. But everyone, they were kind of starting to play with single page applications with AngularJS. When you were doing Magento, you were playing with PrototypeJS, when Magento2 was released, and people were already playing with React with Angular too with VueJS, you're playing with Knockout.js, which is a technology that all single-page frameworks can originate from, but it's extremely odd. I wouldn't be surprised if most of you don't even know what Knockout.js is. So it wasn't a very pleasing technology to work with. And you can clearly see that because there was no so many people willing to actually become a Magento, front-end developer, those were usually juniors that were just put into Magento projects and grown into Magento developers, but it wasn't anything that, you know, kind of at the top of your head when you think: "Okay, I'm gonna become a developer". So another thing was the problem of monoliths, we had a very big project at that time in Devonta. And when you have a single codebase, that, let's say 20 People contributes to, their front-end developers editing PHP files, you have back end developers editing JavaScript files, it's, it's a recipe for catastrophe sooner or later. And every project sooner or later, was turning into catastrophe, like the maintenance catastrophe. So there was a lot of different problems that were actually accumulating. And we saw this headless commerce idea, which was kind of solving all of them. So we gave it a try. But the thing is, we had no idea how to do this, right. We never launched a headless storefront. Noone did, in our company, we did some POCs. We're exploring this idea, it felt nice. So we decided, okay, let's create a boilerplate for e-commerce storefronts, because this is probably something that is really stopping the adoption, you have to do everything from scratch, there's not so much knowledge about this topic. So maybe let's create a boilerplate, put it on GitHub, so people can validate, maybe they can join, maybe they can collaborate on this and contribute. And then we'll all use this boilerplates. Actually, you have the storefront. And imagine what happened. Like, I think after a year, we had more than 80 partners all around the world using Vue storefront, we have like, I think 2000 people on our Slack at that time. So it was a huge success, really. It turned out that it's not only our problem, and the thing that we put on GitHub immediately became a big thing in the in the whole industry, especially Magento, because they were very used to open-source, like Magento community was basically originating from the open-source roots, Megento itself also was originating from the open-source roots. Right now Adobe seems to struggle, with finding a good business model that will keep that community,

will keep this open-source model. They're kind of trying to kill it. But the community is so strong that they're trying to keep it. So it's a very interesting case, actually, because the company itself is trying to kill the product that the community is trying to keep so much, that they're not allowing the big AW to do this. Yes, so we put that on GitHub. It was a really, really big success. We were accumulating in contributors, new projects, we kind of felt like superstars, you know, we did a tour on Meet Magento events. Were speaking there. were participating in the discussion panels. It was a really nice time. And then the COVID hit, and there was no longer conferences, no longer discussion panels on longer hackathons. And during COVID, we actually made a decision that okay, we want to create a separate company out of this. And if I remember right, it was myself and Patrick, our second co founder. So Patrick is more like a business oriented. I'm more tech oriented. We both had zero idea about running a company. So this is why we had our first co-founder, Bart, he's a very experienced enterpreneur. So we met Bart I think, the beginning of 2021, we met, we talked, we decided, okay, so we'll be fundraising, we'll be looking for venture capital, and probably will decide launch on March, when we split off from Devonta, and we'll start creating a company. It wasn't much. It took us, if I remember right, 11 months, to actually spinoff from Devonta, to become a separate company. And it's really like a huge problem for companies that are incubated inside other companies. Because when you want to spin off, you have to satisfy yourself, your investors, but also previous shareholders and previous shareholders don't really wants to feel that something is taken away from them. And in our case, you know, we're all learning this like, are we are the ex biggest shareholder of Devonta, they didn't have that much experience with startups, developed the founders, the atomic, they were also learning from this. So there was a lot of mistakes made throughout the way a lot of alignment had to happen, we have to, you know, explain why actually, you really have to give more shares for us. So the company in the long run is more investable and has bigger success and your shares, even though there's less of them, that will be worth more. Because you know, those people if they don't have this experience, and natural way of thinking is: "Okay, so we invested so much into this software, and right now you're telling me that we have to give away like 50-60% of it for free"? So, it was a tough process. And I think, you know, it could probably it would probably be tough for everyone, if you weren't thinking about speeding it up from the very beginning. I mean, maybe a separate P&L in the company, etc. But we did it. In November, we signed our papers with VCs, and when we were coming back from Warsaw, from actually signing it, we got an email from Y-Combinator that they want us to join another call. So we came back, we joined the call, and they announced us that we are right now part of Y-Combinator. So at the same day, we actually save money for our season investment, and got into YC. Pretty good day.

Oh, yes, I can imagine. Yeah, because when you talked about the problems, and things related to it, we should talk about the different architectures that are available in the e-commerce world. You mentioned about monolith and headless. Are, are they're the only ones or are there some more mixed models of architectures in the e-commerce world?

Yeah, I would say you know, the headless, or monolith. This, these are kind of like role-models, or like representative architectures. But the reality is, every system is a mess. And if it's not, the brand new is probably a mixture of those. So maybe I will try to explain the difference between those architectures where I think they fit well, where I think they don't, because there's a lot of misconceptions in the headless in general, in e-commerce industry. And there's a lot of buzzwords that people are using to actually call the new architectures, or the same architectures in new new ways, because they are focusing only on specific user-scenario, and you're giving it a new name. Because you know, people need this excitement. People need the buzzwords. But not only e-commerce industry, right? But we tend to laugh a lot of the JavaScript community because they're having this, those buzzwords, they're having those new frameworks and new framework that is doing exactly the same thing. But there is a lot of cool marketing around this. So people are super excited, they want to migrate everything. And you will think that, you know, serious people in the enterprise, well, they are different - they're not. They're doing exactly the same thing. This is this is how this industry works, right? So until I think 2017-18, when you were thinking about building an e-commerce Store, you are naturally choosing a monolithic platform. Monolithic platform is a platform that has everything in one codebase, front-end, back-end. Usually it's using some server-side technology like PHP, like Java, renders everything on the server, then sends HTML, with ready data, there's no like asynchronous updates on the front-end when you navigate to another page. Basically fetching a full page that has also services rendered. And we used to do it for a very long time, like, you know, Salesforce Demandware, Magento. All of those platforms, they were monolithic platforms, and there was like WooCommerce, as well, there was no other choice than just doing that. But then we had this mobile era, this shift to mobile devices. And exactly as I said, at the beginning, like those huge giants, those huge platforms, they were not adjusting fast enough into that. And they are still not adjusting like, most of the platforms, I know, right now, that used to be monolithic, they're still monolithic, they're having some headless alternatives, but they're still like monolith-first. So, what you can do to actually make your website mobile-friendly, without changing everything and rewriting from scratch. You can detach the front-end, because this is actually the layer that your user interacts with, they really don't care what is happening on the backend, there could be like a very heavy computing happening, but the reality is, you would just cache that, right? But the client will have to deal with all this JavaScript data, they will have to deal with fetching another page, usually very heavy, and you can tell, you can get rid of that. So, instead of replacing the whole platform, and actually, you know, choosing something else, and doing a very heavy investment, people decided: "Okay, so let's just replace the part that is actually causing those bottlenecks. Let's detach it". So that part was front-end. So in headless commerce, the closest, the easiest possible definition is that, headless happens when instead of having a single monolithic application, you're detaching the front-end, and communicating with the back-end from an API - that's headless. And this is exactly what people did. They started detaching the front-end, they started talking to the back-end through an API, which I think was a very good choice, because there is a much better split of responsibilities between different parts of the system. Before that, like everything was just in one place. They started doing this, they started using a single-page application frameworks like Vue.js, React, Angular to actually build those front-ends. And they were faster, they were significantly faster, especially when navigating inside the application.

At that time, we were starting with storefront and it was just headless nothing else. But the market was maturing, the headless itself became a very broad term. So obviously, we started to have some segmentation. And then composable happen. So what is composable? Composable is all about choosing so called best-of-breed vendors. Instead of choosing a single ecommerce vendor, imagine like, again, even headless work, you can have just Magento and a Magento is responsible for orders, for content management, for your catalog, product catalog, for discounts, and the list goes on, and on, and on. And, you know, when you have a small shop, it's not a problem. But when you have a big shop, when the scale is big, this is starting to become a problem. Because obviously, you have some trade-offs, there's no like one-size-fits-all. When you rethink everything from a single vendor like WooCommerce, like Magento, those things are not perfectly optimized for the workflows, they are not perfectly optimized for clients, etc. And this is when actually composable comes into play, because it allows you to replace different parts of your stack with a specialized vendors that are focusing only on one thing. For example, you have a vendor for a CMS, you have a vendor for orders, we have vendor for promotions, we're composing your perfect stack, that is meeting all requirements of your clients, of your internal decision makers, etc. And suddenly, instead of having full Magento in the back-end that talks through an API to the front-end, we are having 20 or 30 different systems talking to the front end talking to each other, etc. And it obviously brings a lot of challenges. Because those things, they have to be synchronized properly. The data also has to come in, in the front-end, not in 30 different requests that we have to glue, or there has to be somehow orchestrated in an API gateway or this sort of thing. This is why composable is more like an architecture for enterprise, because the initial costs are high, very high. The initial time of implementation also high, because of the complexity, but it really pays off in the long run because you have huge flexibility, we can replace all your vendor adjust everything. When you're earning a lot of money on your ecommerce, a small changes could bring a lot of improvements and could bring a lot of money actually. So this is when it matters usually, you know, when you have a much smaller shop, those changes, they, they will make a difference. They will, like, you know, increase conversion.

1% In a small shop is, let's say you have a turnover of $1,000 or 1%. If you earn millions, each percent counts a lot.

Yeah, so we can call you know, composable as, like "perfectionist's e-commerce". You're really choosing exactly what you need exactly the vendors and everything like it should be done. It has a cost, but it also has a turnover in the long term. And we tend to say that composable is actually you know, architecture that will stay with you, because it's primarily made for trends, for flexibility, for constantly improving, replacing vendors, experimenting with others without actually sacrificing so much time on this, etc. So it's really a great architecture, but at the same time, it's not for small merchants, it's just an overkill. So that would be like this representation of those three architectures. Of course, in reality, you have all the different flavors of that, even a monolith can be composable, than just the model itself acts as an orchestration layer. But it's not so flexible.

Yeah, because as you mentioned, composable, let's be honest, composable is nothing else that just, let's call it headless to the max, I mean, we are just dividing everything. And I mean, this is kind of the nature of headless the this constant possibility to change each part, each API, we don't have to worry about it. I had this great talk with Cassidy Williams here during our Buddy webinar. And she really gave a great description that monolith versus headless, headless versus monolith is like working, I mean, playing around with Legos versus knitting. If you want to change something in Lego, it's very simple, you just open the site you have, change few bricks, put it back together. It will work, probably you sometimes need to add some small adjustments, but most of the set remains intact. And when you try do some changes in the monolith. So then knitting example, you either just break everything to start over, or you start patching it in some reasonable way. And your users will see it will see that it doesn't fully fit. And yeah, and this this composable approach is like this 100 Lego system, when you see that you can have a bit better turn over with changing a bit, for example, the checkout process, you just change the third party tool responsible for the checkout and things like this. I mean, because I'm kind of in the WordPress space, in the WooCommerce space. I know how big of a problem is the checkout and the cart there. It's very often repeated as the one of the biggest problems with this, process is not clear enough. And it's not easy to change. So yeah, and and let's be honest, WooCommerce is quite okay as a e-commerce, that connected with a bit better checkout and cart process, would work even better. So yeah, again, typical example why going headless and composable could be a good approach. And yeah, so you already mentioned about the pros and cons of those architectures. But if you're a company and you're thinking: "Yeah, so which way should I go? Should I go headless, should I go monolith. I have some money. I just started the store. So which way should I go? Which will be the best?

Yeah, and that's actually a very tough question. So I'm part of Mach Alliance technology. Mach Alliance is basically like organization that is uniting the best headless commerce vendors, and the best headless commerce agencies. They're kind of trying to standardize all of this. They're kind of trying to unify things. And one of the things that we're working on right now is actually Mach Maturity Check, which is exactly what you're describing, like we have an agency, I mean, we have a client, and the client might wants to go to composable, so we're actually trying to sense if they are mature enough, that they're ready for this, and if this is even a good choice for them. But the truth is, like, when you're starting a business, what you really want to do is you want to have your shop being set up as soon as possible and start selling. Nothing else matters really, like you want to start selling as soon as possible. You really don't have, probably don't have knowledge, tools to even, you know, understand those little details that will actually make your conversion is a little bit better. So it's best to start with tools like WooCommerce, really just for your first shop, WooCommerce or Shopify, these sorts of things. Over time, when your business is growing, you might need to detach your front-end, if you know it will be limiting. Especially when you're using Shopify or WooCommerce, we have a lot of extensions that are putting code of Java's, additional JavaScript into your website, and you can't really control this. So this is where websites like WooCommerce websites, Shopify websites are becoming a little bit clunky. And they are starting to load longer, and longer, and longer. And the best way out is basically, again, to detach the front-end, and decide exactly what lands on your front. So this is how you can regain the control over it. And this is what we see a lot of customers is doing. For Shopify, for example, they also tend to move to headless, to get rid of the limitations of Shopify, for example, multiclass, it's not very well supported in there, the templating system could be a little bit limiting. And it's also kind of like a very specific, you have to be a Shopify Liquid developer to change it. So there is a lot of reasons for moving to headless at some point, but I wouldn't do this from scratch. Like, really, headless is a solution to a problem. So if you don't have this problem just don't go headless. The same way, composable is the solution to the problem. These are kind of like, natural evolutions, because, the reality is, when you're scaling your shop, you're encountering those problems. And you could think, okay, so I will encounter those problems, perhaps I should start with composable from the day one, but you shouldn't, because it's super hard to maintain, will cost you a lot, and you might get there in 10 years. So for 10 years, you will be maintaining the future architecture, and in 10 years, there will be new future architecture, it's called "premature optimization", and I wouldn't advise to do this. And you know, just headless and monolith, like the regular headless and composable headless, because composite was kind of like an extreme branch of that. I think those two will solve most of your problems. While monolith will probably solve all the problems of small merchants, headless will solve most of the problems of medium merchants, while composable could solve most of the problems of large merchants

Okay, I fully understand. Okay, so we have this, we have this store, a monolith store, and at some point we want to start migrating into the headless approach, how should we proceed with this? Because you're already mentioned that sometimes this headless approach is a bit because we want to "cover" what we have behind. So how such migration would look like and what can we gain thanks to such an approach.

So I saw basically two approaches, of course, like, we can mox them, at least a bit, but I saw two main approaches. One approach is when you're detaching your front-end, creating something completely new on Vue.js, React, whatever, or just use something premade, which I really encourage you to, like Vue storefront, because there's mostly groundwork when you're starting to migrate. So one approach is that you're doing this from scratch and creating all the pages, and you're going live. And usually the development goes in parallel with the old system. So we have the old system, you're still maintaining this, people are using this, but you're building another one. And at some point, you're just switching them or doing A/B tests with specific users. And another approach is that you're replacing this page by page and this is much more agile. And it's also much more complicated, because imagine that you have a homepage, a single page application, a product page and category pages of Magento application. And somehow you have to keep the session the cart everything together. So this is a little bit more challenging. But I saw a lot of projects doing that, from the customer perspective, and also,from the agility perspective, I think it's much better choice. Because you have much more control over this, you're not doing a large replacement, it's more like kind of like a strangler pattern. Strangler pattern, is the pattern in architecture design, which stands for, basically, building something on top of the old system and replacing it part by part, instead of doing it all at once. So we can do it this way, there's much more, there is much more complexity. But at the same time, you have much more flexibility, we can also A/B test for specific pages. So some customers could see the old one, some customers could see the new one, just because it's a bit more setup for large organizations, and for large shops, I would probably advise doing this, because you can also very quickly validate if this even makes sense. Or you can very quickly increase, you know, the conversion on the pages that are struggling with performance or user experience the most. So the ROI is much faster. And you know, when we are talking about replacing the front-end going headless, I think that's the fastest way to bring return of investment, when it comes to software. Because you can really be agile with doing that, for example, let's, let's imagine you're on the legacy platform, and you want to modernize it. But at the same time, you know, that's moving to something completely new, you know, going headless, etc, it will take a lot of time. And it takes a lot of time, like usually, time is more than estimation. So what you can do is actually you can say, okay, sorry, I'm keeping my old legacy platform, I'm putting headless on top. So my user, they already have this experience, my user experience is improved, my revenue is improved, because the conversion is improved because the server is faster, the experience is better, because your users, they really don't care what you have on the backend, like the backend is for you, the backend is to optimize your workflows to make you more efficient, maybe let go some people and just hanging less people. So the cost of ownership is generally smaller. But it's not gonna improve anything for your users really, like they don't care. They don't care if its WooCommerce, Magento, whatever, especially when you have a headless store. So I would say start with the front-end, this will bring you the biggest return of investment, and then over time, you can either change the platform completely, or maybe use Magento at the backend and slowly replace specific parts. So then maybe add the IO or Story Blog for CMS, maybe replace the checkout with some headless checkout, etc, etc. So there are different ways to do this. The worst way is to start everything from scratch, I wouldn't advise that like, the headless technology is all about separation of concerns, and it's giving you this great ability to migrate step by step instead of starting from scratch. So just you know, take advantage of this.

Yeah, I mean, I had the chance a few times to redesign some e-commerce's, and it's a horrible experience for a developer, there are so many things about you have to worry about. So yeah, doing this headless approach is really great. Also, I can imagine that you mentioned that we can upgrade the back end and change it. Or let's be honest, in many cases, don't touch it at all and leave it for next year to come because it's cheaper.

And that's true, especially now we have an economic downturn, it's super risky to make an investment. So I think what you should focus on, you should focus on the things that are actually giving you the best return on your investment. I mean, the fastest, and you can you know, quickly see the results, you can quickly validate if it makes sense, the backend platform migration is definitely not one of those things, because it's always painful in some platforms. Now, some vendors could tell you that it's not painful - it's always painful. Someone could say that the automatic migration, etc. but it is extremely basic, super basic. So migrating your backend, this has to be more thought out decision, and you have to think about this in the long term. And starting from the content basically gives you immediate results. And this is something that I am advocating for a lot. Because you know, I don't believe that when you have a problem, you should just throw everything out and start from scratch. It's very tempting, you know, a clean start, etc. But at the same time, a lot of parts of your system even though you're not a fan of them, they're old etc. they might be functioning well. You should focus on the real problem. Just fix it, optimize it, and then maybe look: "Okay, so we'll fix the front end, the customers are buying more, I have much bigger conversion, the source faster, etc. Now let's look if I still have some problems", like if I still have some problems that we have to fix, or maybe that fix everything. I don't need to make the second part of the investment at all, right?

Yeah. So I think that we are going closer to asking the question that we raised and the topic of today's webinar. So why the front-end is the most important, you already told a few parts of it. First of all, yeah, front-end as well, on the front end. So this is the thing that people see, and this is this is the part with which people will like communicate. So this is one thing. It also, I mean, the good front end can mask a lot of bad things on the backend, because as you already also mentioned, people don't care what is underneath. But I think that there are probably more more things, why the front end is the most important.

Yeah, I would say, you know, it's more about the whole approach. So we had this platform-centric approach for a very long time and platform centric approach is that when you're thinking about doing ecommerce or moving to any other ecommerce, like what you think about first is the ecommerce platform, like you're choosing Magento you're also kind of bought into the Magento ecosystem, or using SAP or using Salesforce, that's the first choice that you're making, like, "Okay, what backend platform I'm gonna use". And this is a platform-centric approach. But right now, what we really should think about are customers, like this is what is the most important thing, we have to satisfy our customers, we have to increase our conversions, we have to give them great design that they can interact with that is fast, accessible, etc, etc. and what part users and are interacting with? The front-end. So you should always start with the front, and you should always start with the piece that will delight your users, and then move to the part that will delight you, of course, maybe your most important than customer when you think about ecommerce platform. But you know, like people still think in this old way of thinking, where everything was baked into the e-commerce platform. And right now your ecommerce platform is just one of the many API's that you will plug into your front-end. So think about the front-end, think about the orchestration layer, and then just you know, plug-in other things. Backend now is a commodity.

Yeah, I can really imagine. And also, the thing that we could quite often hear about headless is that it is the silver bullet, that is the silver bullet that will solve all of our problems that the performance will like, skyrocket and the sky will be much more blue and the sun will always shine. So is it true?

Of course. Like, every new technology totally solves all the problems, right? And it's never given any new problems. So okay, like jokes aside, like what is headless, headless, just an architecture. What is software architecture is just a way of solving a specific problem. So headless is not to solve, yes, to solve a specific problem, usually when you have something new is solving the problems on the previous platform had, previous approach had. So all of these had problems with scalability, but not scalability, in a sense of performing on the high traffic, because we can perform at any traffic, you just need more machines. But more about scalability of development of flexibility, changing moving parts actually accelerating the business, because the business is using technology for a specific reason. And the business is changing a lot. Also, that whole landscape is changing a lot. There are new trends, etc. You really have to be flexible. When you want to win the e-commerce game, you really have to experiment or you have to choose new vendors, new approaches, you need that. This is where headless and composable can really help you. But it won't solve all of your problems, definitely. I will tell you this, it will create a lot of new problems as well. Because if you have your monolith and you're changing to something like headless or composable on paper, it could look great, but then it's completely new way of thinking you need completely new competencies. You need completely new workflows. We're talking with a completely new vendor that you have no relations with. There are so many places where you can make a mistake. You're transitioning from a place that was very known to you, to that is unknown to you. And the truth is a lot of projects moving to composable moving to headless, they're coming back to monolith after some time, because they bought this promise and just promise it won't run that much. But I think the biggest, I blame them most, Google because they, when they were launching GWS, when they were launching lighthouse, they had this obsession about performance, they made everyone performance-obsessed, and they also said that PWAs are a promise of much better performance. And they associated that with single-page applications. So everyone was blindly believing Google, they were moving from their old monoliths that were no longer cool to headless hoping, that if it will improve the performance out of the box. And guess what - most of them had worse performance. Why? Because they use the same people the same processes to develop something completely different for the first time with zero expertise. And the truth is, it's super easy to ruin performance on the single-page application. Because single-page applications are kinda enforcing you to use JavaScript for everything, then even the default stacks, they are JavaScript driven. So it's very easy to at some point, have just too much JavaScript. And it's causing some specific bottlenecks in the interactivity, in the loading, experience, etc. And almost everyone are struggling with this. Why, because it's a new paradigm, it has a lot of benefits. And I would say the best headless website is faster. The I mean, the best single-page application is faster than the best multi-page application, on average multi-page application is faster than our single-page application just because it's a new paradigm. And the same way as everything, you have to learn it, you have to learn what you should avoid, you have to learn what are the downsides of this technology and what you can do to fix them. Otherwise, it's not gonna deliver to any of the promises, it's just an approach is just a technology, not a silver bullet for everything. And again, like I was stating, at the beginning, when you have a small business, don't think about headless, because what matters to you the most is selling. And when you start having your problems with performance, maybe with the fact that your codebase grew too much, etc, then you should start looking for other alternatives.

Also, when you mentioned that when we are going headless, we start with working with new vendors and everything. I would add one more thing that in most cases, when we work with monolith, we have like one problem, because yeah, it's a monolith still. So it's only placed in, most cases, on one server, things like this. And the moment when we start going with, let's already go right to composable, we are starting working with a separate vendor for a cart for promotions, for everything. So at some point, we are not dealing with one place where problem exists, but with multiple places, and the more services we are adding to have our e-commerce work more efficient, the more possible points where something can break. Because they have to communicate with each other, they will just appear one after another. So and I can tell you that very often when when I talk with people about headless and they are mostly from this PHP space. So typically this is more monolith approach to development. There also is a kind of a trust issue. Because right now, our only problem is our server, the worst case, our server and the CDN. That's it. And the moment when we start connecting all those third party tools for everything. It's like as a distrust is a bit gone because we have to, at one point start stressing so many third party tools, so many people, so many tools and this is this is the thing about the whole paradigm shift about the fact that like headless can change everything and I can tell you that even we personally had especially at first a lot of problem understanding what problems with headless we'll solve. Because at first I saw how many problems it can generate at first. But the moment when we start thinking about how easily we can get rid of the problem and exchange it to either a solution or potentially a new problem, because this is also the thing that can happen. Yeah, this is, this moment was like, the most important for me that I started realizing that this gave us this, this whole flexibility, that we don't have to worry about sticking to some technology, because at any point, we can just do a change we don't have to worry about. So for example, we will still use WooCommerce in the in the background and don't have to hire front-ends with the knowledge of PHP, because we will do it with an API and for example Vue storefront, right, because we don't need PHP for that. Yeah, and tell me, if I would have a client that has a store for already quite a few years. How should I convince him to give headless or composable a try?

I wouldn't try to convince them at all, because the biggest problems in the industry that I see right now are not because people are trying to convince others to use headless without really, you know, understanding their problem. So, of course, like how you sell things, you sell things by making people realize that they have this problem, because in many cases, they don't. They just think: "Okay, this is my comfort zone, it cannot be better". So that's an important thing. But it has to be a real problem, not an imaginary one. So I wouldn't, I wouldn't convince them. I would start by asking some questions regarding you know, okay, so how often do you release? How long does it take to release? Did the time of release decrease over time? Like, how many bugs do you have? Do you feel confident with your codebase, and the tests that are out there, etc. Like, all of this is kind of giving you more or less a perception of like, if they already outgrown monolith, and they need the separation, because otherwise, this single monolith it can't scale into infinity, when it comes to development, and maybe they need the separation of concerns, maybe they need to be able to work parallely on two code bases, instead of working on one because it's slowing them down. And maybe they're making so much money, and their workflows are so unoptimized that they're losing a lot of money on it. And they immediately use composable. Because they really need to pick the best vendors, because the trade-offs of picking just everything from one vendor would cost them a lot, so much that it's much better to you know, to spend a little bit more money, a little bit more time on laying a proper foundation, and then just slipping safe and making sure that everything is perfectly optimized for our cases.

Okay, yeah. So in general, never focus on the technology focus on the potential problems, or the lack of them. Because if everything works, and they are happy with it, maybe

Exactly, exactly.

That... Please continue.

No, like what I wanted to say is that exactly to your point, like, all the buzzwords are the marketing teams are trying to create some kind of a FOMO in us developers, decision makers, etc, that there is something completely revolutionary that we're missing that will erase all of our problems, increase conversion rates, etc. I agree, this is how they are selling this. And it is creating FOMO in you. But the truth is, you really have to be double-cautious. You always have to ask yourself, why like, what exactly I'm getting out of this? Is it really worth it? And is this really being exactly what is promised? Or is this just a buzzword? Because everyone kept saying, you know, headless is a solution to performance issues. Yes, it is. in specific cases, when you have a shop that is mostly driven by marketplace extensions, it is. But in other cases, I wouldn't say that is a solution to completely different problems that has nothing to do with performance. I mean, you can have a terrible and great performance in single-page application and multi-page application. It all depends on your skills and skills of your software developers on how they actually approached this topic. I could talk about optimizing performance for hours really. But headless and composable, they are solutions to other problems to problems that are more like, you know, our problems in sight. The companies, problems with workflows, problems with different prices, we have some limitations of vendors that are not allowing us to do something. But it is not a solution to the problem with good performance. It could be, in some cases, but in general, it is not the main purpose of this technology. And I want this to be very clear.

Okay. I mean, I'm this is really amazing that you as a co-founder of storefront that could say that, yeah, my storefront will help your performance that you are going clear about this. Because yeah, it's important that headless can solve many problems. But again, not the silver bullet, how some people claim. And yeah, we have, I stated, we have one question at the moment. So let me show it. I would like to get a list of API services that can simplify e-commerce SaaS and many more product-based apps. Example: PayPal, Ship Rocket, Headless WordPress, what more should be known what is trending?

Yeah, I won't give you a list because there are like new technologies popping usually every day. But what I could to really encourage you to look at this Mach Alliance, I already mentioned. So if you go into their website, you will actually have a list of the best vendors in that space that their goal is exactly this. Accelerate the ecommerce make it simpler, make it more flexible. So just take a look at Mach Alliance, it's called M-A-C-H

Okay, thank you. And from what I see this is the only question we have. So Philip, I want to thank you very much. Thank you for sharing a lot of your knowledge about different architectures, about headless, and specifying when it's a good idea and when maybe we should wait or just skip it. And before we'll finish, I want to encourage you to go to our MeetUp Buddy CI/CD group, the this is the place where you can see our upcoming events. So I encourage you to sign up there. And also, if you like this webinar and our previous webinars, yeah, go to YouTube and press the subscribe button. We also have a Twitter, Facebook and LinkedIn account where you can also follow us. So thank you. Thank you, everyone for watching. Philip, thank you once again and have a great day. Bye everyone.

Bye. Thanks for having me.