Remix Conf Europe

Remix Conf Europe 2022

The New Frontier: E-Commerce at the Edge 

Hi there. My name is Michael and today I want to talk to you about the new frontier, e-commerce at the edge. I've been building e-commerce applications for well over 15 years from old school PHP 5.4 to now Node.js, TypeScript and more modern tooling. And that's what I want to talk about today. I want to tell you about the future of e-commerce. And that consists of two major trends that I want to cover today. One being headless, the second being the edge. Let's cover what I mean by these. First of all, headless. Here's a Google trend chart for headless commerce. As you can see, more and more people are searching it. There's a lot of interest there. But what does it mean? Let's Google it and find out. Well, when we Google it, we'll see the first page is just ads. If we scroll down, try and find out what it actually means, we will get one after the other content marketing blog posts. What can we tell from this? It's a buzzword. That's what we can tell. And if we try and read these and find out what it means, we're going to get lost in jargon and keywords. Let's skip that. And I'm going to show you a diagram to make it simple. We want to build a web-based e-commerce application, an online store. What do we need? We need a server. Okay. We need a database to store our product, customer, and order data. We need some business logic. This is what's going to take that data, put it into some templates, apply some business logic, and produce the website and all of its functionality. We probably have some cloud services, some caching layer maybe, some third-party APIs to call out to. But at the end of all that, we're going to serve to our customer some HTML. That product data from the database has been put in a template, and the server is returning HTML. This is what's known as a monolithic architecture, a traditional architecture for a web app. This has been around for a very long time and will be around for a very long time. And this is good. But we're not talking about that now. We're talking about headless. Headless is different. How do we get from monolithic to headless? Well, it's simple. We just got to remove the head, like that. Now what's happening? So we're no longer serving HTML from the server. Instead we're serving JSON through a JSON API. That could be a REST API or a GraphQL API. The client is responsible for taking that data and turning it into HTML. Typically that would be a JavaScript-based framework, would take the JSON and put it into a template. This is nothing new. We've been doing it for a long time. We used to call it things like AJAX. Now it's being referred to as headless. But that's all you need to know. I'm sure you've done it. If you've been building single-page apps, you've been using this already probably. Nothing new. But that's what we mean when we're talking about headless. Headless commerce is this applied to an e-commerce application. Let's look at some examples. So headless really caught on big in the content management space, first of all. You've probably heard of some of these services and projects. WordPress is an interesting one. This is like the original old-school monolithic CMS system, the granddaddy. But it's in here because you can use it as a headless CMS. It has a REST API and it has a GraphQL API. So you can use it just like this. In the commerce space, there's lots of software as a service and open-source products as well that you can use to build in this way. Again, you have pure headless offerings like Commerce Tools and Venger. And then you've got companies like Shopify, which are traditional monolithic system, but have recently bet really big on headless. And this is fantastic. You've probably heard of the Hydrogen Project. And you've probably also heard that they acquired Remix as well. So this shows that a real big player, and Shopify is one of the real big players in the e-commerce space, they're betting big on headless. And this is a very good sign. And this is a sign that this is a trend that is really here to stay and it's going to drive the future of e-commerce. So we've learned what headless is, but why are people interested in it? Why is it so big? Why is it the future? Let's look at some of the benefits. So first off, we see that it's pretty easy now that we've separated the client from the server. We can now serve multiple clients through the same API, a mobile app, maybe an in-store point of sale system, and who knows, even an internet connected fridge where you can order your groceries through the same API. And now that we've decoupled the UI, it means that we're no longer bound to the templating systems imposed on us by a monolithic system, be that the templates of Magento that you see here, or the WordPress style templating system that's used in WooCommerce, or liquid templates used by Shopify. A decoupled UI means that we can use absolutely any technology that we want to build our front ends. And this is a key point because in e-commerce, it's not uncommon that the server, the platform itself, is very long lived. It's a big investment and it's going to last five years, 10 years, even more. By decoupling the UI, it means we're no longer constrained by whatever technology the backend platform is built on. We can build the front end with whatever we like. Remix, for example. And that brings us to tooling. Let's take an example, Magento. This is a very big open source commerce platform. The last major version came out some years ago, maybe seven or so years ago. And at the time, they had to choose what are they going to build their UI layer on. So the tools that were available at the time looked something like this. And they chose some of these, like Knockout, RequireJS. And that was a fine choice back then. Now, if you were to start a new project and someone said, choose whatever tool you want, you may not choose these. I personally wouldn't choose those. I would choose something maybe more like the ones on this side. And the key point here is that with a headless architecture, you are free to do that. You're not constrained by tooling choices that had to be made a decade ago. You can use what makes sense now. And that's a huge thing in terms of not only developer productivity, developer happiness, but also in the results you can get in terms of the experiences you can create for your customers. And this also highlights a strength, a massive strength of the JavaScript node ecosystem. This incredible innovation, this pace of innovation, some people call it JavaScript fatigue. But on the positive side, we have an amazing array of tools that we can use. And there's continuous innovation. And the innovation is not only in frameworks and build tools, but it's also in the actual platforms that we can run our code on. That brings me to the next point that I want to cover, the edge. So what is the edge? Well, to explain this strange new concept, I have a special guest, the edge. I'm sorry, I had to get a dad joke in somewhere. This is the edge, the guitarist from YouTube. He's going to help explain what the edge is. So what is it? Okay, he says an edge server is a server located at the edge of a network. What do we mean by the edge of a network? Well, in the center of this network, we have a cloud region, EU central one. That's where we're hosting our e-commerce application. We have users all around who want to use it. And notice that they're not accessing the cloud directly. They're going through an intermediate server that's close to them. These servers are what we refer to as the edge or edge servers. Let's make this more concrete. Here's our node application running in Central Europe. This is running our remix app, of course, and we're using a headless commerce backend. And we have a potential customer down here in Sydney. He enters the URL of our website into his browser. His browser is going to send a packet all the way to our server in Central Europe. And that is 16,000 kilometers away. Just the network latency for that packet to go across is going to be over 260 milliseconds. Once it arrives on the server, we're going to be rendering HTML. This is a key point. We're talking about e-commerce. We're going to be doing server rendering, okay? SEO is king. So we're definitely going to be server rendering. So there's some work done there. Once the HTML has been rendered, we've got to send it back all the way back to Sydney. Again, 16,000 kilometers latency. So just before the first byte arrives, our customer is going to be waiting for like a second, two seconds. Who knows? How is this going to look like from his point of view? Okay, he's entered the URL. The packet's traveling 16,000 kilometers. The HTML is rendering. Okay the first byte has come back. We've got some HTML. That's good. Now the HTML is fetching some JavaScript, maybe some assets. It's making some more fetches for data that it couldn't server render, such as session-specific data. Ah, okay. The shopping cart just loaded. Some more requests going in the background. Lots of latency on every single request. Finally the image appears. The website's loaded. Not a great experience. How can we improve this? Something that we've been doing for a very long time is using CDNs, content delivery networks. This is actually a form of edge computing. This stores static assets like images, JavaScript files, CSS files on a edge server, for example, right there in Sydney, so that when those assets are required in the future, they're fetched locally instead of 500 milliseconds latency, there's 10 milliseconds latency. That solves part of the problem. But we still have to go all the way to the origin server to actually get the HTML file to know what resources we then need to subsequently load. How can we solve this? Well what if we could do the rendering not only in our origin server in Central Europe, what if we could render right there at the edge? As if we'd taken our node server and scattered it around the world. That would be cool. That's what we can do now. So as well as our static CDN, we can also actually render our page right there on the edge with something like Remix edge SSR, server-side rendering. So one really, really cool thing about Remix is that it can run on any JavaScript runtime. So we all know Node.js, but there are other JavaScript runtimes. There is Deno, there is Cloudflare Workers, there are probably others, and there are probably more to come. Remix is very smart. It abstracted that part away into adapters so it can run on any JavaScript platform. In this case, we could be running on a Cloudflare Worker, for example, Cloudflare Pages, and Remix can do the rendering right there. So the HTML is generated there in Sydney, 10 milliseconds away. There's still a problem, though. To get the product data to put into our page, we still have to make a call back to our headless server in Central Europe. We're still going to incur latency. But edge computing can help with that, too, because we can cache our API responses at the edge. So that product has already been requested in the past. The response has been cached right there in Sydney. So now let's look at it. When he wants to visit our website, he makes a request. The edge server can start rendering the page with Remix. When it needs data, it grabs it from the edge in an API cache. It returns it to the customer, and every resource that is needed by that web page to fully render it is right there in a CDN also. So everything that he needs is right there in Sydney instead of 500 or 1,000 milliseconds latency, there's 10 milliseconds or 50 milliseconds. Much better. So this is why I call it the new frontier. It's really a revolution in the way that we can serve applications and increase performance, increase global availability, and decrease the load that we actually have to serve on our origin servers. So this new frontier, as I said, consists of headless architecture and edge computing. Now what does this look like in practice? I've got a demo for you. Let me introduce you to Venger. Venger is an open source project that I've been working on for the past four years. It's an e-commerce framework, so it allows developers to build custom e-commerce applications. It's built on Node.js using TypeScript, and it's headless. It exposes its functionality via GraphQL APIs. Not only that, it's highly extensible. You can pretty much build anything on it. It supports multiple languages, multiple currencies, and it's got a growing and active community. It's used by lots of companies from Fortune 500s to unicorn startups, Y Combinator-backed startups, national supermarket chains, and everything in between. If you want to try it out, you can get started in one command, npx at Venger slash create my shop. It supports SQLite, so you don't even need to have a database running locally. You can literally be up and running in five minutes. Try it out after this talk or after this conference day. This is what I want to show you today. It's an online shop backed by Venger. It's built, of course, with Remix running on Cloudflare Pages, which is an edge computing platform. And the API is cached by Stellate, which is an API caching service which uses the Fastly edge network to cache API responses. So we've got everything in the mix that I've talked about. So this should be good. Let's take a look. So here's the website. It's available at remix-storefront.venger.io. I'll just take you on a really quick tour. Here's the landing page. We can drill down, look at these categories, camera, photo. Take a look at this. And as you can see, it's running pretty fast. We can filter, add to cart. We can take a look at the cart, modify it. All of this is happening against a real API. We can search. So that's what it's like to use. I'm sure you can agree it's pretty fast. But just how fast? Can we have an objective measure of it? Well, let's take a look at PageSpeed Insights. And we will take this product detail page and drop it in there. Now it's going to run its analysis. And what we're hoping to see, of course, is lots of green circles with big numbers approaching 100, hopefully. Let's see what it gives us. First of all, we're going to see the mobile results. Okay, lots of green circles and almost 100 in all of those. If we go over to the desktop version, okay, this is looking really nice. We have basically 100 in everything almost. Accessibility needs a little tweak. And these numbers right here are ridiculously good. So it's fast. It's objectively very fast. Let's see if we can get a measure of the benefits that edge computing is bringing in this situation. Our origin server in this case is in Europe. I'm in Austria. So we're not really seeing the full capabilities of the edge. But let's see if we can view this website from different locations around the world. Here's a page that I found that lets us do this. So it's going to make a request to this website from Singapore, Brazil, Virginia, California, Ireland, Australia. And let's see what the results are. So they all come in. Look at these. 6 milliseconds. 14 milliseconds from Brazil. Virginia, 1 millisecond. Australia 14 milliseconds. California 2 milliseconds. This is I can't think of a better illustration of this entire concept of headless and edge than this. The results speak for themselves. I'm going to shut up now. That's the end of the demo. Let's head back to the slides. So to recap, we've talked about the future of e-commerce being headless, edge computing built on Venger using Remix. Thank you for your attention.


Michael Bromley

Vue.js Live Conference

Vue.js London Live 2021

Vue Storefront + Vendure = Fullstack Open Source Ecommerce

Hi VGNs London. Let's talk about full stack open source e-commerce, shall we? My name is Jakub and I am a technology leader at Vue Storefront. I am also a core team member of Storefront UI, which is a UI library for e-commerce, and I'm also a core maintainer of Vue Storefront and Venger integration. Apart from work, I'm also a technical diver and currently doing a cave dive course, and I'm also a mountain hiker, and in the second picture there is me on the top of Volcano Teide de Tenerife, which was actually our Vue Storefront location this year. And yes, we are hiking. Now let me tell you a short story. In August this year I set myself a long-term and ambitious goal. I told myself next year I would like to join Filip Rakowski, who is Vue Storefront CTO, in one of the greatest Vue.js conferences and give a speech. So right now in two months I'm here giving a speech instead of next year, so everything is possible guys. Just make this first step. Have you ever wondered what it's like to build an e-commerce store from scratch? Handling all these orders, products, categories takes time, and time is the resource that you may not have as someone who wants to be a market leader. And what if I told you that there are all these solutions on the market that you can just pick and play in minutes or hours instead of waiting for the developers to develop the solution from scratch, which would basically take weeks or months? And what if I told you that these tools are free, open source, and backed by the huge community of contributors that are doing their best to make the project as good as possible? So I want to present to you something what I'm calling a dream stack for open source e-commerce, which is Vue Storefront and Venger. Vue Storefront is a lightning-fast front-end platform for headless commerce. But what exactly is headless commerce? If you have been playing some computer games in the recent years, you might probably know this character. This is a character from the game Team Fortress 2 and his name is Headless Horseless Horseman. And why am I bringing this example as a comparison to headless commerce? So Headless Horseless Horseman was a very powerful character and so is headless commerce. But in more details, what is headless commerce? So headless commerce basically means that you are separating your front-end or the UI part of your e-commerce store from the back-end. And it allows even mature businesses to have flexibility and maneuverability of a startup. So it basically means that, for example, Vue Storefront can connect to many different e-commerce platforms, headless CMSs, payment gateways, search engines, and many, many more third-party services. And what about technology stack? So basically Vue Storefront is built using three main tools. NaxxJS, which is a framework for Vue.js. We are using also TypeScript and GraphQL, but Vue Storefront works with REST API as well. Some basic concepts of Vue Storefront. Vue Storefront uses concept of composables, which are used to map certain functionality of your e-commerce or map certain domain of your e-commerce. So in this case, we will be taking a look at product domain. Each composable will contain from four main functions or four main elements. The first one will be a variable, in this case products. This products variable will contain a value of your product domain. Next, we'll have a search method or the load method that will be used to fetch the data from your e-commerce platform to Vue Storefront. Composables might have several methods, like for example, use product or use address. Might have add address, remove address, update address, get address. So it might have more than one method, but it must have at least one method which will be used to fetch the data. Next, we have an error object, which will be used to each property of this error object will be mapped to the certain methods that this composable has. So in this particular case of the use product composable, error object will contain only one property, which will be named search. And it will contain an error that might occur in a situation where you are fetching the data from your e-commerce platform. Last but not least, we have the loading property, which will be used to indicate whether we are still waiting for the data to be fetched from your e-commerce platform. This was some basic concepts. Now into customizability. Let's take another look at the use product composable. We have a search method that is used to fetch this certain product by ID. This will result in a object that will contain our product data. However, what if we would like to have a different object or a different structure or different properties? For this particular case, we could use a concept of custom queries. These custom queries will be used to override the default query that we are sending to the e-commerce platform. And how does it work in more details? In middleware.config.js, which is basically the main configuration file for Vue Storefront, we could define in an object of custom queries, we could define these custom queries, which are basically, for example, GraphQL, queries. Apart from custom queries, we can also customize Vue Storefront or our shop built using Vue Storefront by using extensions. So instead of just customizing the certain query, we can extend the API methods that are used to fetch the data or modify the data. We can extend the app itself and also the lifecycle hooks of the whole application. So as Adam Jarr and Greg Pollack used to say, let's review. So Vue Storefront is built using modern technology stack. Vue Storefront can connect to various external services and provides full e-commerce functionality. It's highly customizable, as I explained previously. Yeah, and going next into Venger. So Venger is also related to headless commerce, but in this case, it is a framework for, let's say, the backend stuff, backend part of your e-commerce. If you'd like to get more into what is Venger and how it connects to Vue Storefront, we have recently recorded an interview with Michael Bromley, who is a founder of Venger. And yeah, you can listen more about what is Vue Storefront, what is Venger, how they connect together, and what are the plans for the future releases. So Venger supports many functionalities out of the box. So we have inventory management, we have commerce, like checkouts, promotions. We have multiple languages, currencies, taxes, and sales channels. Venger is also scalable, so cloud-ready and auto-scalable. We have some media management, so image cropping, cloud storage support. And we have some team support for role-based permissions and admin UI. So technology stack. Venger is built using NestJS, which is a framework for Node.js and Express. It is also built using TypeScript, and it's built using GraphQL, and it also comes with the Elasticsearch support and the database of your choice. Some basic concept of Venger. So how Venger really works. So we have two GraphQL APIs. We have the admin API and the shop API. Shop API is used mainly for your shop operations, like fetching the data about products, collections, users, and customers. And admin API will be used for more advanced stuff, like managing roles, managing products, and so on and so on. So if you are requesting the data from GraphQL API, it will go to Venger server, which will start a queue. And this queue will create a worker, which will then access the database and return the data to Venger server. And this Venger server will return data to your GraphQL API. So we have an admin dashboard that is built using Venger. And we have a custom query. So we have an admin dashboard that is available for you, where you can add products, add collections, modify users, and so on and so on. And we also have the GraphQL API, which allows you to fetch the data to your storefront. In terms of customizability, Venger supports similar pattern as your storefront, because in terms of Venger, instead of custom queries, we have custom fields, which allows us to extend the default structure of the domains or the entities in our database. So in this case, we have a product, which we want to extend so that it will contain a new property, which will be named info URL. And it will be type of string. So next, what we can do is we can fire a or create a mutation in our GraphQL, where we will update the product with a new property info URL. So thanks to that, we don't have to create a new entity, we are just extending the default one. We can also customize the order flow, which allows us to not use the default one. But let's say we want to have a step between the adding items and arranging payment. So the default one is adding items, we will move to arranging payment. Adding items means that we are visiting the store and just, for example, adding products to our cart. And the arranging payment, which will mean that we are arranging some payment data and proceeding to checkout. So let's say that before arranging payment, we would like to have a step where we will be validating the customer. How we can do that? First of all, what we will do in the transition, we will create a new process. This process will contain a, it will be an object that will have some properties that in the big picture, what they will do is they will allow us to create a new flow. So we will add the validating customer and we will also modify the existing adding items, which will allow us to move to the step from adding items instead of going to arranging payment. And then in the validating customer, we will say that from this step, we can move backward to adding items or forward to arranging payment. And then we can just register this new process in venture config. As simple as that. Venture also supports plugins, which allows you to extend the default functionality. So we have core plugins, which is the admin UI that you have seen previously, the elasticsearch support, the email support, and also the asset server, which are provided by default. Next, we have the enterprise plugins that will be coming soon. And this is advanced search, gift card, wishlist, and so on and so on. And we also have the community plugins, which allows for Stripe, Braintree, so payment gateways, reviews, social auth with Auth0, for example. So let's review once again. Venture is built using modern technology stack. It can connect to various external services using plugins, provides full e-commerce functionality, and is highly customizable. So you might be thinking, there is some similar pattern here, and you are completely right. So both tools are built using modern frameworks like Next.js and Nest.js. They are customizable by default using custom queries and custom fields. They provide full e-commerce functionality, and they are configured to integrate with external tools and services, so payment gateways, headless CMSs, and so on. And they are open source and backed with a huge community of contributors. So I would say that this Fustralfan and Venture actually sounds and looks like full stack open source e-commerce dream. And let me show to you how it works. So basically, what we are doing here is we are creating an online store from scratch with Venture. So we are setting up a project, defining some database, a language, mailing provider, and we are also creating a new store with Fustralfont and setting a template to Venture. Next, what we are doing is installing dependencies as always and setting some environment variables in order for the store to work as expected. So here, GraphQL API and the method for authentication, and we also have to add this method to the Venture config. So two simple steps that allows us to run our store. So let's wait a second for that. Okay, we have a Venture store running, and we have a Vue store also running. So we can scroll down to listing, add some products, define some configuration, modify the quantity of the products, add some customer data to our checkout, set up some shipping data, as well as shipping method, some billing, in this case is the same, payment, and make an order. So let's go ahead and run our store. So we have a new store, we have a new customer, in this case is the same, payment, and make an order, and that's it. So in less than one and a half minute, you have a online store set up and ready to accept some orders and to play around. So if you like what you see, make sure to give a star to both Fustralfont and Venture projects, because they are open source and this is how they, let's say, live, thanks to these stars. So make sure to give a star to them. And also if you'd like to contribute, make sure to visit Slack channel of Venture or Discord channel of Fustralfont. And that will be it. Thank you very much for your attention and make sure to contact me on GitHub using the Paroshen handle or on Twitter Andrzejewski handle. See you.


Jakub Andrzejewski

React Finland

React Finland 2021

Contentful and headless

Nidhi Kumari

JSNation Live

JSNation Live 2021

Headless vs Traditional eCommerce Platforms: Introducing Commerce Layer

Hello everyone, my name is Fabrizio and I'm the partnership manager of Commerce Layer. What is Commerce Layer? Commerce Layer is an AdWords Commerce platform and an order management system. And thanks to its AdWords nature, the idea is that you can pretty much add global shopping capabilities to any sort of user experience you have in mind. So it could be a website, it could be a mobile app, a chatbot, it could be a video, actually you name it. And all of these in a very, very simple and effective way. So as our product is an AdWords Commerce platform, of course the core of Commerce Layer is its API. So we offer a quite extensive range of endpoints to manage all the different aspects of the commerce experience. So prices, shopping, cart, inventory, orders, and so on. So unfortunately I cannot go through all the lists of the endpoints, but you can find them in our documentation. And I think it's important to stress the fact that Commerce Layer is an AdWords platform. And this is very true if you compare it to the traditional monolithic solution. So I guess you already heard this term, a monolithic platform, but what does it mean? Actually, it means having a single platform managing all the features of your e-commerce application. So think about the platform that actually manage everything. So it manages the CMS, the product information management, maybe the order management system, everything in just one single box. These unfortunately come with some challenges and we try to summarize them in five main points. The first one is that such platforms are actually less flexible. Why? You have to think that you have just one single box where everything is implemented. So this means that you can't change any module of your application or your commerce application without actually replacing everything. So this is quite a big problem. So if new needs emerge in your business that might require, I don't know, maybe a new model or a new application, let's say your platform won't allow that without a full re-platforming. So you can imagine this is quite a big problem. The other problem related to these traditional applications is that most of the time the result is that the website build on top of those there are just as slow. Why that? That's because given the architecture of those applications, it's very difficult to leverage the power of new concepts like dedicated CDNs, for instance. And as you can imagine, a slow website can be a big problem, especially if you consider, I don't know, things such the new Google algorithm for ranking the core web vitals, just to make an example. So being fast is definitely a competitive advantage when you're selling online. There are also security issues. If you have just one application and everything is inside that box, you have a single point of failure. So if that application fails, everything fails. This is a big problem. Other problem is that considering that these traditional applications are, let's say, have been designed quite some time ago, most of the time they were built for desktop. So they don't have a really, let's say, mobile first approach, for instance. And the last problem is that they are expensive. There is quite a lot in these boxes. Sometimes you don't need some of the stuff that is in these boxes, but you are anyway going to pay for all of them. So what is the solution? Well, the solution is actually to work on architectures that are modular. And this actually means splitting the monolith. So these, for instance, can be, let's say, an example of a modular architecture based on commerce layer. So commerce layer would be the transactional engine, managing prices, stock information, checkout APIs, and customer account APIs. And around commerce layer, you will start integrating all the different services that are needed to deliver the commerce experience. So an Atlas CMS, for instance, a static site generator. This is very true if you are going the gemstack direction. A deployment platform to optimize and maximize the performances. And then link commerce layer to specific services for the needs that you might have. So tax calculation services, payment gateway, shipping carriers, and also the legacy system like the CRM and ERP. And what are the benefits of this approach? Well, as you can imagine, everything now is extremely flexible. You can swap in and out modules very easily without doing a full re-platforming. It's much easier because now you can scale just one specific module and avoid, let's say, very expensive upgrades of your central platform. So you can just selectively scale modules of your architecture. It's more secure because now you don't have a single point of failure anymore. And it's omnichannel by design because all of these modules actually has an API interface. So you can connect pretty much everything, whatever touchpoint you think about to this sort of architecture. And last but definitely not least is future proof. Being future proof actually relies on the fact that you can change whatever module depending on your needs without, let's say, doing a full re-platforming. Thank you very much for your attention. And in case you have any questions, you can drop me a line at my email or just book a demo of our platform at commercelayer.io. Thank you very much.


Fabrizio Picca

#e-commerce