💻 Getting Personal with Ecommerce, React, & the Static Web

and his team. Today, it's getting personal. We're going to talk about e -commerce, React, and the static web. So who am I? I'm Colby Fayock. I'm the one hugging BB8 and Kylo Ren over there. I work with the dev community as a developer advocate at Appletools. You can find me anywhere on the web by just googling my name. Let's look back at the past. We're back about a year and a half ago. It both feels like it was ten years ago and just last week. We were all able to safely go out to restaurants. We could meet up with friends and family. We could even grab a bite to eat alone. I don't think any of us expected that 2020 would be the year that we'd meet a pandemic. I know I expected 2020 to be the best year ever. But that's realistically what happened. Stores and restaurants started shutting down because they couldn't support the decline in business. I lost my favorite Chinese restaurant in Virginia. I was really hoping to hit it up one last time before I moved up to Pennsylvania. Luckily, some restaurants were able to sustain themselves. Between apps like Uber Eats and Instacart, we've been able to attempt to have normal lives but at home. Restaurants have also attempted to offer curbside pickup themselves, but this can be really hard for business owners, especially if they're not used to fulfilling orders this way. Because we have options out there like DoorDash and Uber Eats, these restaurants could quickly start accepting orders online without dealing with all the infrastructure needed. Unfortunately, these services tend to be a little And while restaurants still tend to cut deep into the restaurant's profits, this makes it really challenging to them. But this most certainly helps some of those restaurants just stay afloat. And the reason some of these restaurants had the opportunity to save their business is because of e-commerce. Small brick-and-mortar mom-and-pop shops might have over 50 years of business experience. But when you're in lockdown, a lot of those in-person advantages start to fade away. So let's talk about e-commerce. The concept of e-commerce probably isn't new to anybody, but it's simply the act of buying and selling on the Internet. Whether you're buying a t-shirt for your favorite TV show, or you're buying some food from a local restaurant, or even filling a prescription, e-commerce gives us a way to buy things without ever leaving our home. And it's not slowing down. We saw a huge amount of growth in 2020 because of, well, the obvious, but more and more people are getting comfortable buying online. And in the middle of a pandemic, more and more people need to buy online. And on top of that, more services are just simply making it even easier to buy. As developers, we're the backbone of that growth. Every online store has a single developer or a huge team of developers that built that experience. We're the ones who give people the ability to buy things online. That makes it compelling to have a general understanding of how it works. But before we get into the development part of those things, let's take a step back and actually talk about e-commerce a bit more broadly. While the concept of e-commerce is still a thing, the concept of an online store might not exactly be new, and you might be pretty familiar with how it works already, but let's break down what some of the core characteristics are of an online store, what some of the different pages are that actually make it possible to buy something. To start, we have the product listing page, or PLP for short. These pages come in a wide variety, from a page that includes all the products under a single category, or like apparel, or it could be a clearance page, which would have a list of all the products that are currently marked down on clearance. The point is, though, that ultimately, the page is a list of products that someone can browse through. Next is the product details page, or PDP for short. It's the page that shows a single product. Typically, that includes the different variations of the product, like different colors or different sizes, but this page will give the most comprehensive look at a single product. It's also where someone typically will purchase the product from. Some sites have a nice little quick add-on feature where you can buy it from the product listing page, but you'll always be able to find the buy button or the add to cart button on the PDP. Next, we have the cart page. After you find the product that you want, you add that product to your cart, just like a real-life shopping cart. You have each of your products that go into that cart, which you'll take yourself with to pay and then check out. Which leads us finally to the checkout pages. Sometimes there's a single page that represents the entire checkout process, but more often you'll find a multi-page process, which will provide a better experience if someone's actually trying to work through that. Here, you'll add your shipping information, your billing information, and you'll confirm your payment. If successful, you'll have purchased that product and you're usually given a receipt. As I was walking you through those pages, we essentially stepped down through an e-commerce funnel, which you might be able to kind of figure out why it's called that, but as someone is moving through a listing page to a details page, all the way through that checkout process, they're moving through a journey of steps in your online store. That journey looks like a funnel when it's represented by data. Starting from the top, which may or may not include that listing page, is where people typically enter your site. That could be done by browsing through a listing page, or it could be directly to a product page. Maybe they found that in a Google search, or maybe they found it linked online. Whatever the case, that first page will be the top of that funnel. Through every step of the way, more and more people drop out of that funnel. Maybe they had second thoughts, or maybe once they added that item to the cart, they realized that they already have way too much in that cart. It's just a little too much more to add. Either way, most people aren't going to actually hit the checkout page, and even those who do, only a small percentage of them will proceed to that purchase, which as people funnel out, that's where you get that funnel shape. But ultimately, these are the critical pieces of a typical e -commerce store. We want to be able to optimize this process, so that people visiting our stores have a good experience, and then each of them come with their own unique challenges. Now, those different pieces probably are starting to feel familiar. If we purchase anything online, we typically hit a majority of those parts, but I'd like to talk about what each of those pages look like from a developer perspective. What are some of the challenges with the different pages? If we look at our product page, beyond the typical layout, like the branding and the navigation, we have some critical components to this page. The image, the title, the price and variations, the cart, and the button to add it to the cart. When we're just trying to serve this page, it can't just be static HTML with the entire thing. Some of those pages need to be highly dynamic in an online store. Parts like the image and the title, they shouldn't really change that often. They're probably okay being static and waiting for an HTML file to update again. Even with the variation selection, we probably know all those variations ahead of time, so that can probably be a static list of options too. But the price, the availability of that item and its variations, and even the ability to actually purchase it, they all need to be accurate when somebody is actually trying to buy that item. If the price is wrong, your customers might complain that they're getting overcharged. If someone buys that item and it's sold out, you're stuck not having enough items to send out to the people, meaning canceled orders and unhappy customers. Moving back to the product listing page, we have similar dynamic components, where we can start to see that we're less reliant on things like stock or things that become critical to be real-time accurate. We have our images for our products, and we have our title, which those can still be served statically. The most dynamic piece here is the price, where because we're not showing this on the product listing page, it's probably less critical to be dynamic down to the second, like it is on the details page. We may even be able to serve this with the rest of the static content, as long as it will be quickly rebuilt whenever that page and content actually updates. It may be, you might have even seen this price variation before on a listing page between a details page, and it might be because that site is caching the listing page heavier than the actual product page. Now, that's a completely different story when we start getting into the cart and the checkout pages. Cart state is interesting with e-commerce, because there are a few different solutions with some trade-offs. At this point, we're talking about what items someone is going to buy and how much they're actually going to cost. These need to be completely accurate. Like before, we can serve the product and the name actually statically, but the only issue is in the cart isn't actually static in nature. What products are being shown are personalized to the person that are actually buying those products. So, really, this entire thing needs to be dynamically generated. We'll get into some solutions later, but most of the time, you see traditional server-side solutions, where that's completely fine being loaded every single time. But when you're serving the underlying page statically with the JAMstack, you'll need some way to store that information and be able to look it up when the page loads. The same goes for the checkout process itself. At this point, we're at the bottom of that funnel. This is where someone is actually going to add their billing information and selecting the shipping option, which, of course, is highly personalized. When someone enters their shipping address, those prices and options are dynamically loaded. Similar to the cart, all this needs to be shown dependent on the person visiting the site. And ultimately, when someone's ready to hit that big red buy button, you'll need to be sure that you're charging the right price and that you're not overselling. The good thing is we have a lot of options for how we can solve this. Some solutions are a little bit more traditional, but we also have some modern techniques that can help give our customers a great experience. Serverful solutions are probably more traditional. The browser makes a request to the server. That server renders the page and returns the HTML to the browser, where the customer can shop. With a serverful solution, our dynamic content really isn't a problem. Each page request hits the server, so that page can be custom-tailored to the details of the visitor's state, whether that's reaching out to the database to grab the person's logged-in state or grabbing the real-time price and availability of an item. But there's another option, where we can serve our website completely static. Instead of that server taking the time to render the actual page, we serve those static files straight from storage. That includes the HTML, the CSS, the JavaScript, and really any files that we want to show to our customers. When it's served statically, we don't need to do any work on the server. We deliver that website directly to the visitor. But in order to make those pages dynamic, we can reach out to APIs from within the browser or even at build time. Sticking with the static-first approach, when you're compiling your website, you can pull in any data that is dynamic to build, but then can be still served statically. Then once you're loading inside of the browser, you can load anything that needs to be personalized for the visitor. Now, you might be wondering if there's a name to this kind of approach, and you might have heard me also mention earlier the JAMstack term. So what is the JAMstack? Well, the idea of serving static sites as dynamic websites has been coined as the JAMstack. What does that actually mean? At the core, JAMstack sites are static HTML websites. This isn't a new idea, but it's a modern approach. JAMstack sites are typically used JavaScript in the browser to make any requests to your APIs that would provide dynamic data. Or they can use those APIs at compile time and serve that dynamic content without any extra client-side requests. One example that we can imagine is building your own React app. This would serve as our JavaScript layer, where we could use something like the Stripe API, or really any other payment service or CMS to grab that dynamic data that we can pull in to grab that content. We would compile that down to a static site using Next.js, which, along with a lot of other features, is a static site generator. So what would this actually look like when we're applying it to our e-commerce store? Well, showing some images and text on a page doesn't need to be dynamic. Leveraging the tooling we have, we can statically generate the page's HTML and CSS, along with any of the JavaScript, and just dump that into object storage. We can even display a bunch of products in a grid. Like we talked about before, this also doesn't need to be dynamic. There's nothing necessarily special about how this page needs to be put together. And to be clear, I don't know if SpaceCadet, the store that I've been showing here, is actually static. I think it's actually on Shopify, but beyond the typical content management solutions that trigger a new deploy on update, this doesn't really need to be real-time dynamic. But moving back to our product page, the vast majority of this page can still be static. Our images and the meta information can be served directly from static hosting. We can let that refresh when a new deploy actually changes something. To provide the dynamic aspects, we can take advantage of client -side requests. We can pull that price directly from our e-com platform, like Stripe, so that it's always up-to-date. For our cart, we can store that state in local storage, or we can use a serverless function to hit a database with that information. The stock is probably the trickiest of all this. Imagine a website like Amazon, where you may literally have a million people trying to buy the same product at the same time. And on top of that, that product might have limited stock. You need to be able to support very quick read and writes to avoid overselling. Content management systems aren't really equipped for that type of thing. So you want an e-com service with inventory management built in, or a performant database solution. That way, you can avoid unhappy customers. But as we sort of dissect this page, we can see how realistically we could serve the underlying page completely static, which alone will give us a bunch of wins, which, while still maintaining the dynamic nature of an online store. Now, those dynamic pieces are probably bigger challenges you'll face specifically with e-commerce. But I mentioned that by serving our pages static, we get a bunch of other benefits. So what exactly are those benefits? Once we have those core pages in storage, we can serve them from a CDN, just like Cloudflare's. Using a CDN allows those pages to get served from locations all over the world. They'll at least be relatively close to the visitor. Which means they're going to get served super fast, which is a really great thing because people want their pizza fast. Like here, Little Caesars uses Gatsby for their website and ordering experience. But beyond hungry customers, page speed is important because it directly correlates to conversion rate. If you're not familiar, conversion rate is the percentage of your traffic that actually buys something. There are a ton of studies on this, but eBay for instance found that a half a percent increase in their conversion rate with a 100 millisecond load time improvement. That might not sound like a lot, but eBay is worth over $10 billion. So just as an example, 0.5% of 1 billion is 5 million. So that adds up really quickly. And bonus, serving static files on a CDN most likely means less downtime. The fact that the page files are static and on top of that, cached at the edge, those pages are going to infinitely scale. You don't need to really worry about how your websites will scale, aside from the APIs. There's less of a chance that you're going to completely get taken down by a Reddit hug of death or by an instant surge of traffic for a high volume, which can mean loss of money if people can't buy your products. It's also going to be cheap. While this might not matter as much for big corporations, for small business owners and individuals, every cent counts. The fact that there are so many services with free tiers, you can literally get up and running with a store for free and then scale that cost of processing payments as you grow. So now I've convinced you why this is a good idea, right? So where do we actually start? While trying to narrow down e-comm to three things feels a little bit of a simplification, there are really a couple of core components of an online store. You have your products that you want to sell, you have the ability to take orders and payments for those orders, and you ultimately need to fulfill those orders. These three all work together to provide the goal of being able to sell things online and get them to the person who purchased them. First off, in order to have a store, you need to sell something. What products do you actually want to sell in your store? Your products are the first thing your customers will see when they visit your store. Where are you going to store the information about those products? A CMS or even just a static JSON file? How are you going to actually show those products? Maybe you only have a few products on one page, or maybe you have an entire catalog with search features. While most of the heavy lifting of an online store happens in the background, you first need to have an idea about what products you're trying to sell and how much they cost. That way, you can give your customers some options for what they can actually buy. Second, when selling something, you need to take people's money. How are you going to take the orders and the payments for those products? Once your customers find what they want, they'll need to pay for it. Are you going to interface with a payment processor directly? Are you going to create a bunch of forms to take that information? Or are you going to use a service that handles all the checkout details? Taking payments and dealing with addresses is very complicated, and even more so when you start to deal with international customers. These are sensitive parts of your online store that need to be handled with care. Building this all out yourself is definitely doable, but it's not something you want to take lightly. Regardless, you need to figure out how to securely take payments for your store and relate those payments to an order. And third, after someone picked out what they actually wanted, and you took their money, how are you going to actually deliver your product to your customers? Is this a digital product that you can email or just let somebody download? If so, how will that work? There's a bunch of integrations you can use. It's not perfect, but for instance, I use a mix of Stripe API and an email service for my eBooks. Not every platform makes it super easy, though, to have a customizable end-to-end flow. If it's a physical product, do you need the shipping information? Who's going to pack that up and ship it? Some eCom platforms might handle this for you, but a lot won't. Once you take someone's payment, you're on the hook to get them what they paid for. You need to be sure that that fulfillment process is working smoothly. While all these critical pieces are for building an online store, we're really going to focus on the first two pieces. There's a lot of software and technology that can even handle the fulfillment. There are even options for embedding that software in your online store and emails to personalize that experience. As developers, more often than not, we're concerned about how we get the products up on a page and how we can let people buy those products. We're going to focus on that. With that said, we need to figure out what our stack is going to look like. What are we going to actually build our store on top of? As we talked a little bit earlier, there are a ton of serverful solutions. You could spin up your own with completely custom infrastructure. That's exactly the type of system that I worked at with Geek, which was on a good old Perl code base. But in modern times, a lot more powerful e-com platforms have risen up. Shopify, for instance, is a super powerful solution. It comes with an all-inclusive feature set. This lets you do a lot of stuff with just Shopify, like complete product management, page creation, and checkout. But if you're a new business or you're building a project for a portfolio, this is going to come with a pretty hefty price tag. And this isn't only Shopify, to be clear. Most vendors, like Shopify, have a similar price point. Another familiar solution is WordPress. You can use tools like WooCommerce, which are really popular in the WordPress ecosystem. With it, you can easily sell products on your website. But with WooCommerce or any serverful solution, you'll have to likely maintain those servers, which frequently have costs involved. Again, similar to Shopify, these are great, powerful solutions. But I just convinced you that we want to build this out statically, right? And we're not really looking to spend a bunch of money to spin up our first store. Which brings me back to static apps. One of the cool things about the dev and Jamstack communities is there's a ton of vendors who offer really great free tiers for devs just like us who want to get started. This applies to whether you're spinning up your own sticker store or building your portfolio. There are e-com services that can handle things like payments. They take a percentage of that transaction rather than a monthly cost. That means you'll only have to pay money if you actually make money. To start, we need to manage our products somewhere. This is where we can take advantage of headless CMSs, where we would pull those products in at compile time and load that static metadata that we were talking about before. In my case, I use WordPress for my SpaceJelly.dev website. I know WordPress probably isn't the most popular solution in the modern, bleeding edge world, but it's working really well in my case and is a common platform if you're building this for someone else, like a client. There are also a ton of other options available. Another cool thing about the Jamstack community is there's a ton of services available, making it pretty likely that you should be able to find one that meets your needs. You'll also be able to manage both taking payments, but also be able to have people add products to a cart. One example is Snipcart, which is a drop-in solution that lets you easily add a shopping cart to pretty much any type of website. Once you add in the Snipcart script from their CDN, you literally just have to add some class names and data attributes with your product data. And this doesn't really only apply to static websites. You can really drop in their script in any kind of page. But once you do, you pretty much immediately have a shopping cart on your website backed by their platform. This includes the entire checkout process, too. This is a really great solution if you don't want to have to spend a lot of time with the shopping cart logic. It can be a bear, and this makes it really easy. I actually use it for my SpaceJelly.dev site. It also includes some things like inventory management and payment processing. You can avoid having to deal with manually keeping track of your stock. Snipcart and other EECOM platforms will handle that for you. You also have a lot of other options, like if you want to dig a little bit deeper and work on a custom solution, you can use your favorite framework like Next.js or Gatsby, and once you created your app, you now have full access to React. With it, you can create your own shopping cart, since at that point, you have the flexibility of React. You can have full control over how somebody goes from adding the cart to getting to that cart page. You also have the full capabilities of React's baked-in APIs. You can manage your own shopping cart state with React's use state hook. You can make that state global with the context API. That way, you can provide the exact experience that you want for your customers. Or if you want the custom experience but you don't really want to have to manage that tricky cart state, you can even use a pre-built library like useShoppingCart, which will give you a cart state system out of the box with a React hook. That will immediately allow you to get productive with the cart state in your app. With either of those solutions, though, you can store that state in local storage. That way, when someone reloads the page or leaves and comes back to the page, they can still see all those products in their shopping cart. You can even persist that cart state in a database, but that doesn't necessarily become critical until you want to persist between sessions, or if you want to support shared cart between different devices. But either way, once you have your cart state, you can use something like Stripe Checkout where you can push customers into the checkout solution. While Stripe Checkout won't handle all aspects of an online store, similar to Snipcart, Stripe will handle the checkout process, which is one of the bigger pain points of taking people's money. The cool thing about this static approach, though, is and taking advantage of APIs for all the aspects of dynamic pieces, is we can still use services like Shopify even if we wanted to. While you'll still be paying that price tag of using Shopify, if you're already on Shopify or you need all the services that Shopify provides, it makes for a great opportunity to leverage both worlds, the benefits of static sites and your Shopify store. But whatever service you choose, you'll ultimately need to deploy it somewhere, which is probably the easiest part of the entire thing. Once you have that compiled version, you can serve it wherever you want. At that point, it's object storage. So whether you want to use Cloudflare's new pages service or one of the other cloud providers, you have a lot of options. So what's stopping you from spinning up a new store? The cool thing about e-commerce is it's a fundamental part of our everyday lives. Millions of people around the world are shopping online. Having the tools in our hands make it easy for us as developers to spin up new online stores. If you want to learn how to build that Next.js and Stripe Checkout solution, you can check out my course on egghead.io. We'll walk through building a shop with Stripe Checkout. We'll use React Hooks and the Context API to create a global cart. I'll include my link in the talk notes, but you can go to colbyfeok.com slash e-com, or you can just find the course on egghead.io. And that's it. If you want to learn more or chat about the talk, you can find me anywhere at Colby Feok. Also, tweet out a link with some of the stuff you've seen here today. Thanks, everybody. We're betting on the technology for the future, not the technology for the past. So having a broad network, having global companies now running at full enterprise scale gives us great comfort. It's dead clear that no one is innovating in this space as fast as Cloudflare is. With the help of Cloudflare, we were able to add an extra layer of network security controlled by our Alliance, including WAF, DDoS. Cloudflare uses CDN and so allows us to keep costs under control and caching and improve speed. Cloudflare has been an amazing partner in the privacy front. They've been willing to be extremely transparent about the data that they are collecting and why they're using it, and they've also been willing to throw those logs away. I think one of our favorite features of Cloudflare has been the worker technology. Our origins can go down and things will continue to operate perfectly. I think having that kind of a safety net provided by Cloudflare goes a long ways. We were able to leverage Cloudflare to save about $250,000 within about a day. The cost savings across the board is measurable, it's dramatic, and it's something that actually dwarfs the yearly cost of our service with Cloudflare. It's really amazing to partner with a vendor who's not just providing a great enterprise service, but also helping to move forward the security on the Internet. One of the things we didn't expect to happen is that the majority of traffic coming into our infrastructure would get faster response times, which is incredible. Like, Zendesk just got 50% faster for all of these customers around the world because we migrated to Cloudflare. We chose Cloudflare over other existing technology vendors so we could provide a single standard for our global footprint, ensuring world-class capabilities in bot management and web application firewall to protect our large, public-facing digital presence. We ended up building our own fleet of HAProxy servers such that we could easily lose one and then it wouldn't have a massive effect. But it was very hard to manage because we kept adding more and more machines as we grew. With Cloudflare we were able to just scrap all of that because Cloudflare now sits in front and does all the work for us. Cloudflare helped us to improve the customer satisfaction. It removed the friction with our customer engagement. It's very low maintenance and very cost effective and very easy to deploy and it improves the customer experiences big time. Cloudflare is amazing. Cloudflare is such a relief. Cloudflare is very easy to use. It's fast. Cloudflare today plays the first level of defense for us. Cloudflare has given us peace of mind. They've got our backs. Cloudflare has been fantastic. I would definitely recommend Cloudflare. Cloudflare is providing an incredible service to the world right now. Cloudflare has helped save lives through Project Fairshot. We will forever be grateful for your participation in getting the vaccine to those who need it most in an elegant, efficient, and ethical manner. Thank you. Microsoft Mechanics www.microsoft.com www .microsoft.com www.microsoft.com www .microsoft.com www.microsoft.com www .microsoft.com www.microsoft.com www .microsoft.com www.microsoft.com www .mymicrosoft.com You