Remix Conf Europe

Remix Conf Europe 2022

Scaling Up with Remix and Micro Frontends

Adrien Baron

Remix Flat Routes – An Evolution in Routing

Hi, I'm Michael Parter. You may know me online as Kiliman, which is short for Kilimanjaro. I've been a big fan of volcanoes for a long time. I'm excited to be speaking to you today at RemixConf Europe. My presentation will be on Remix Flat Routes, Evolution, and Routing. First I'll start by giving a brief introduction on the current routing convention as we know it today. Here's a typical routing structure. It consists of a pathless layout for public pages like the About page, a user section with its own layout which has a list view, a user detail view, as well as an edit page. Remix uses folders to determine the parent layout. It is expected that the parent layout will include an outlet to render its children. In this example, there is no user ID folder because we want the edit page to use the same user's layout as the other routes. Since the edit page is not nested, we use the dot or flat layout instead of a nested layout. When you create a nested layout, Remix requires you to create a folder for its children plus a file for the layout itself. Unfortunately, one of the drawbacks of this convention is that the folder in the layout file ends up separated in your editor since folders are typically displayed first. This can be annoying, especially on large applications with many routes. As you know, Next.js recently introduced their own take on nested layouts. Let's compare their convention with Remix. Here is the same routing structure as the previous example. Next uses parentheses for pathless layouts similar to Remix's double underscore prefix. The one thing you'll notice is that Next requires a folder for every segment of the route. The leaf route is a file named page. If a route segment adds a layout, you create a layout file. With Next, layouts and pages are separate things, whereas Remix doesn't differentiate. Again, looking back at our user edit route, Next looks for the closest layout, which is user slash layout. Another major difference with Remix is that Remix uses named exports for things like meta, links, headers, error boundary, et cetera, and Next uses separate files for each. This can result in a large number of files depending on your app's needs. It led one person on Twitter to tweet this screenshot. Granted, this is an extreme example. One of the benefits of a folder for each route, though, is that Next does let you co-locate supporting files in the route folder, things like CSS, components, images, et cetera. This is one of the main things Remix devs have been asking for. We'll discuss how Remix FlatRoutes supports this shortly. Now that we have that out of the way, let's discuss the new Remix FlatRoutes convention. It's currently a separate MPM package, but will be included in a future version of Remix as core functionality. So what are the goals of the Remix FlatRoutes? Make it easier to see the route your app is designed. Just pop open the routes folder and they're all right there. Since the file system typically sorts folders first, when you have dozens of routes, it's hard to see which folders have layouts and which don't today. Now all related routes are sorted together. Allow co-location of support files with routes. You'll see how you can keep your styles, components, and other supporting files with your routes. Remix refactored and redesigned friction. While code editors are pretty good at fixing up imports when you move files around and Remix does have the tilde import alias, it's just generally easier to refactor code base that doesn't have a bunch of nested folders. Remix will no longer require this. Additionally, when redesigning the user interface, it's simpler to adjust the names of the files rather than creating and deleting folders and moving routes around to change the way they nest. And finally, helps apps migrate to Remix. Existing apps typically don't have a nested routes folder structure like today's conventions. Moving to Remix is arduous because you have to deal with all of the imports. Also as we saw with Next's new nested layouts, flat routes make it easier to migrate from other frameworks to Remix. So Remix flat routes was first introduced as a gist by Ryan Florence back on April 7th of this year. He posted a link on the Remix disk board and I just happened to see it and I was intrigued because I too was looking to simplify my routing structure. Less than two weeks later, I made the first commit implementing the flat route spec. The trickiest part was trying to figure out how to determine the parent layout when there were no folders. Simply a dot separated file name. We'll discuss how that was implemented in a little while. An interesting point is that it wasn't until a month later that Next.js posted the first layouts RFC describing their new nested layouts convention, which is now available as an experimental feature in Next.js 13. As I mentioned before, Remix flat routes is currently implemented as a separate package. To add it to your app, simply npm install dash D Remix flat routes. Since routes are determined at build time, this is a dev dependency and it's not needed at runtime. One of the things about Remix is that although it's opinionated, it does have some escape hatches that let you add your own customizations. In this case, it's the routes configuration where you can add your own routes in addition to the default convention. Since Remix assumes the files in the routes folder use the default convention, you'll need to tell Remix to ignore all files in the routes folder. Finally call the flat routes function to scan the folder using the new flat routes convention. In the future, you'll be able to specify which convention you want to use directly through the Remix config file. Remix flat routes changes some of the file naming conventions that we're used to. For example, for pathless layouts, use a single underscore instead of a double underscore prefix. The params prefix remains the same, the dollar sign, but I'll show you how we can change that later. Instead of using folders for routes, the file name includes the entire route. So use the dot instead of slash to separate URL segments. And finally, to handle scenarios like our user edit route, the underscore suffix specifies the segment is not a layout because it has no outlet. I'll demonstrate this later. Remix flat route supports two configurations, flat files and flat folders. Flat files will typically be used for simpler apps as everything's in the file name and there are no folders. Here is the same example we used before, but using the flat files convention. Notice that there are no folders. The entire URL structure is visible at a glance without having to drill down into separate folders. We still have to identify the index route, in this case, user slash index. Notice how we named the file users dot index. Leading underscore here is simply to sort the index route before the other child routes. As I mentioned, we're using dots instead of folders to separate the paths. But without folders, how does Remix know what the parent layout is? To determine the parent layout, Remix flat routes finds the longest matching prefix and that determines the parent layout. Here we see that public prefix of public dot about matches the public TSX layout. Same with users. Remember in the previous example where we didn't want the edit route to nest under user ID? There we use dots in the file name to deal with it. But how do you deal with that when everything uses dots? Remix flat route allows you to use a trailing underscore on a parent route to specify that this is not a layout. As you can see in the edit route, the user ID should not be treated as a parent layout, hence the underscore. This ensures that users dot user ID prefix is not matched with that route and Remix will then look to the next segment for a matching layout, which is the users layout. Although flat file simplifies the routing convention considerably, it does so with some drawbacks. For example, there are no folders. We cannot co-locate supporting files with our routes. Even if we were to add rules to ignore these other files, it would require you to import them with the full path, not exactly simplifying things. Flat folders look just like flat files. The main difference is that instead of the routing being a simple file name, the folder itself is the route name. The route file, index TSX, is located inside the folder. This is similar to the next JS page file. Remix doesn't differentiate between routes and layouts. Again, layouts are simply routes without left. So index TSX or layout TSX mean the same thing. They're simply aliases and is mainly used to be more descriptive when looking at your routes. Remix supports multiple aliases for the route file. You can use either index, route, layout, or page, as well as add the underscore prefix. This helps sort route and layout files to the top of the file list when co-locating files. As we stated before, one of the main benefits of the flat folders convention is to support co-location. Here, we are co-locating support files like CSS, components, server files, images, etc. The route file will now let you import these assets as a relative import. I've been experimenting with splitting my route file into a route and a route server file. The main reason is I use Zod for validation and the package is kind of heavy. By only defining and using the Zod schema in the server file, I guarantee that Zod does not end up in the client bundle. So now that we've seen the benefits of flat routes, how do we migrate our existing app? The Remix flat routes package includes a migration tool. Simply run the command mpx migrate-flat-routes and specify the source and target folders. The folders must be different to prevent the tool from overwriting your original routes. You can specify whether you want flat files or flat folders. Here's a screenshot of the routes from the sample fakebooks app before and after migration. You can see that it lets you quickly see how your routes are structured without having to expand the folders. One way to verify that the migration went smoothly is to run the mpx remix routes command on the original routes as well as the migrated routes. Since remix-flat-routes creates the same route configuration that was generated by the default convention, the routes should be identical both in hierarchy and paths. The only differences are the file names and maybe some sorting. Over the past six months, as people have tried out remix-flat-routes, they've offered suggestions for improvements and other enhancements beyond the original specification written by Ryan. I've already started the PR process for getting remix-flat-routes into the core framework. Whether these enhancements end up in the core is still to be determined. And at the very least, I will continue to support these as add-ons that you'll be able to include in your configuration. One of the pain points of the remix routing convention, both the current and flat routes, is that the use of the dollar sign can be problematic when working with files in the shell. Since most shells treat the dollar sign as a variable prefix, this forces you to escape the file name when using commands. Considering this is RemixConf Europe, I suggest using the euro. Or if you have a typical US keyboard, perhaps the caret. Some developers want to be able to mount the remix app on a path other than the route. Perhaps they are adding remix to an existing website. Here you can configure remix to use a different path, such as my-remix-app. This will update the route path and you won't have to add a separate folder in the routes folder. Jacob Ebi, a Remix team member, recently created a sample app that had routes processed by different backend technologies, which is quite mind-blowing. He had routes from node, Cloudflare workers, as well as service workers, plus a common set of layouts. He used RemixFlatRoutes, but in order to support his needs, he had to manually combine the routes into a single namespace to ensure the parent routes were correctly defined. In RemixConfig, you can now not only specify a single path to your routes folder, but pass it an array of paths. FlatRoutes will build up the route structure across multiple route folders and merge them into a single namespace automatically, so you don't need to do that manually. And as you can see from the MPX remix routes output, that the routes were correctly generated. So in conclusion, I've been a Remix supporter since day one, when it was a paid product. It was well worth it and has definitely improved the way I build web apps today. I can't believe it was almost a year ago today that Michael Jackson first announced Remix version 1 to the world, making it available as open source. In that short time, there have been two Remix conferences, one back in May that I was fortunate enough to attend, where I was able to meet in person for the first time people like Michael, Ryan, and Ken, and many others that I've only known on Twitter or Discord. As well as this conference here today, where I'm grateful to be able to give a presentation and talk about something I've built and I'm very passionate about. And now with the recent news that Shopify has acquired Remix, we can all rest easy that this amazing framework will continue to prosper. I can't even begin to imagine the wild ride that Michael and Ryan have been on these past 12 months, and I'm excited to see what the next 12 months will bring. Thank you for taking the time to watch my presentation.


Michael Carter

Full Stack Components

Kent C. Dodds

React Advanced

React Advanced Conference 2021

Don't Solve Problems, Eliminate Them

React Summit Remote Edition

React Summit Remote Edition 2021

Building Better Websites with Remix

Michael Jackson

React Day Berlin

React Day Berlin 2022

Let’s Remix to Localize Content!

Arisa Fukuzaki

Remix Persistence With DynamoDB

Brian LeRoux

React Remixed

Hello everyone, welcome to my talk called React Remixed. If anything else, let me start to introduce myself. I am Daniel Alfonso, I'm the person on the left on the photo in case you didn't recognize me. The person on the right is here, he's my programming buddy. I'm a developer advocate at OLX group, I'm a Node 0 ambassador and a GED.io instructor and you can find me on Twitter and pretty much any social network at the handle DanielJCAlfonso. So let's jump in right into remixing and getting to know more about it. What is this talk about? Well, this talk is about webfetch APIs, it's about HTML forms, form data objects, URL and others. Okay, now you might be wondering, what does this have to do with remix? It does because when you learn remix, you accidentally learn the web. Now I know, I know, I know, I know, you might be a bit tired of seemingly a new JavaScript framework showing up every day or so, but the thing is, and like I said right on the previous slide, when you learn remix, you accidentally learn the web. This is because remix leverages the stuff that we've been doing in the web for around the past 20 years or so and it makes sure that whenever you learn it, you get knowledge that you can bring back and forth between the web and remix and this is super, super great. Now, I know you might be wondering, what is remix? And let's get right into it. Remix is a full stack web framework that will let you focus on the user interface and work back to web standards to deliver a fast, slick and resilient user experience. Remix can also be considered four things. In this case, a compiler, a server-side HTTP handler, a server framework and a browser framework. Let's get a bit into each one of them so we can learn a bit more. So on the compiler part, by using ASBuild, remix will generate three things. Server HTTP handler, a browser build and an asset manifest. So the browser build is used to and includes automatically code splitting by route, fingerprinted asset imports like CSS and images, pretty much anything that you will need to run your application in the browser. The asset manifest in this scenario, both the client and the server are using this asset manifest to pretty much know the entire dependency graph of your application. This is useful when you want to preload resources in the initial render of your application as well as prefetching them for client centralizations. This is how remix is able to delete the render and fetch waterfalls that are very, very common in web applications today. By using this build artifact, an application can be deployed to any hosting service as long as it runs JavaScript. Regarding the server-side HTTP handler, this is an handler that is given to these JavaScript servers that I mentioned about. Because while remix runs on the server, it is not actually a server per se. Regarding the server framework part of remix, if you're familiar with server-side model view controllers like, well, waterfowl or rails, remix is the controller and the view and it leaves the model up to the developer. And from the browser framework perspective, once a document is served to the browser, remix will pretty much be responsible for iterating that page with the browser build JavaScript models. So for instance, if a user clicks a link, instead of making a round trip to the server for the entire document and for all the assets, remix will simply fetch the data for your next page, update the UI. This has many performance benefits over making a full document request like these assets don't need to be redownloaded or pulled from the cache. They don't need to be parsed by the browser again, the assets I mean, and the data that it's fetched is much smaller than the entire document. So yeah, this is super, super great. And this is a very small introduction about what remix is. But yeah, still speaking about it, what is its philosophy? Well, remix embraces the server client model fully. You can make your server fast. What you cannot do is control your user network. Sometimes, well, we've all experienced this. It seems to be working very good for us. Then we check our code, our application in the user network, just because they don't have the same bandwidth or whatever that we do, the application is smaller. Takes more time to load. So remix helps you by decreasing the amount of stuff that you send over the network. So we don't need to ship all the skeleton UI because remix fetches and can even prefetch at times the data before the page is rendered. And this, well, will make it easier for us to send applications to our users. Like I said previously, remix works with the foundations of the web. In this scenario, browsers, HTTP and HTML. These are technologies that have been around for a long time. They're pretty great. And remix fully embraces them. By combining stuff like HTTP caching, remix focus on URL for assets, dynamic server rendering and HTML features like the link attribute with the real prefetch, you have all the tools that you need to make your application pretty great. And like I said, browsers and these all type of things that have been around for around 20 years, they are very, very good. And remix fully leverages it. Remix uses JavaScript to augment the user experience by emulating the browser behavior. While most recent frameworks only have APIs for read, for data, remix has both read and write. Why you might ask? By leveraging HTML forms. HTML forms have been around for a long time and they have been the staple for data mutation since the 90s. So remix will embrace this and fully augments that API. This will enable the data layer of a remix function to work with or without JavaScript on a page. So this means that JavaScript, when we're talking about remix, is what is called progressive enhancement. If you decide to add JavaScript to your application, it allows you to also remix to speed up your user experience in two ways. On a page transition, I mean. By not downloading and evaluating JavaScript and CSS assets and by only fetching data for the parts of the layout that changes. Finally, the last point of philosophy with remix is it doesn't over abstract the underlying technologies. And this is why it's said when remix accidentally run the web. Because if you get good at remix, you'll accidentally get good at web development in general. Remix makes it convenient to use, like I said, browser, HTTP, JavaScript, but these things are not hidden and they are not abstracted. Whatever you're using, it's the same thing you'd be using with the web. And yeah, this is pretty much a six-ish minute introduction to remix. At least for the theoretical part. Now let's get a bit more practical and understand the three top things that you should learn so that you can finish the talk and just dive in deep into remix. So the first one, nested routing. So nested routing is pretty much the general idea that you can couple segments of the URL to your component hierarchy in the UI. Now, I know this might not make much sense looking and just reading this description, but let's look at an example. Here we have two routes. A user profile, a user account. Both routes have something in common, which is the user, where we have the username. And they have two tabs here, one for the profile and one for the account. The concept of nested routing here is whenever we select a profile, our route will change to be user slash profile and we want to render this nested part, which is the nested profile page. But if we click on the account, we want our route to change to account and render nested account page. And this is how nested routing works, because whenever you select a part of the URL, of the UI, instead of re-rendering the rest or changing page, it will only render the nested part of the component. And this is super, super powerful and Remix leverages this fully. So for the next part, which is data fetching and mutations. Well, I know with client-side applications and whatso, we are very used to using use effects or React query or SWR, but Remix makes this so much easier and so much simple. So let's see how we can do data loading with Remix. So here we have a component called heroes. In this component, what we want to do is fetch some data, some hero data, and render it. So how would this work in Remix? First thing we have to do is export a loader function. A loader function is a function that will run whenever application loads. And this is how you can do data loading in your application. Whenever you load your app, you can trigger some data fetching. So what we have here is we have, we're returning JSON. This is a HTML, HTTP response. And this will return your data. Then so that inside of the component, we can have access to the data. We get our user loader data hook, which will give us access to the data. And then yeah, we just render it. And this is how you can do data loading with Remix. It seems very simple to do, and it makes it so much, so much easier to fetch data. And decoupling the complexity, I guess, it makes it much simpler to understand. For mutations, it's very simple. But instead of using loaders, we create actions. Now you might be wondering, how do we trigger an action? Well, I spoke about forms around three, four minutes ago, didn't I? Because that's how Remix does mutations. Pretty much we create our form, and we define what method our form is going to do, get our post. And then we have inside the inputs that we have to do. And whenever we submit it, this Remix will be able to look into the application and say, okay, is there any action here that needs to be fetched or needs to be triggered? So whenever we click submit, this action will get triggered. And inside of it, we do a couple of things. We can get access to the request, which is where we can get the form data that our form is filled with. So we don't need to keep track of state inside of our component, because whenever we press submit, the form data will be sent to our action, and we can destructure it here. Okay, so once we have our form data, we can trigger our data mutation. And yeah, that's pretty much it. So now let's look at the code sample that I have here, which is an application built on Remix that shows a bit of this concept so we can hook a bit more to that. Okay, so now enough of chitchat, and let's just see some code. And I have here a demo, which is pretty much a concept built on top of Tower of Babel, which is a comic from Justice League from a couple years ago, where, well, Batman just had a list of heroes, where you could see their real identities and weaknesses, just in case anyone from the Justice League or whatever went rogue. So here we have an application built on top of Remix, and we have a couple of things that we can do here. First things first, this is already leveraging nested routing, but I'll show you how. So here we have a simple component where we can check our heroes. In this scenario, we're checking Batman's profile. And here we can see the user that's logged in, in the scenario Batman's logged in, because yeah, we want to keep this set, no one else should use our application. And then we have our hero identity, our secret identity, and what the weaknesses are. For some reason, if Batman regrets it and he wants to remove that hero, you can delete it. You can also add some new heroes. So let's, for instance, just add Superman in here. Quark, Kent, that's his secret identity, and the weaknesses, Kryptonite. Okay, so now when we save this, our hero is here. And yeah, this is pretty much what the application is doing. If you want to delete it, you can delete it as well. So let's hop into some code. So here we have our heroes route, which is pretty much whenever we go to the heroes route, this is what's going to be rendered. So as you saw previously in my explanation, we are using a loader to do some data fetching. In this scenario, this loader is responsible for authenticating our user and for getting our heroes data to be shown on our menu that we have down there. Then inside of our route, we call a useLoaderData hook to get our data. And then with that data, we're going to render our heroes. Now this is where we get into nested routing. What enables nested routing is this fun thing here called an outlet. An outlet will pretty much look into our file folders and see, is there any folder created with a route heroes? And this scenario, it will find inside the routes that there's a folder called heroes. And it'll say, okay, so let's render it. The first thing it will look for, it's for an index. And in this scenario, our index says, access the bad computer. And this is why our first page says access the bad computer. So this is the nested part of heroes. So all the things here that we have, it's inside heroes. But whenever we render, thanks to the outlet, it takes nested routes. This is the index of our heroes page. Now if we click on it, we are going into the new route and going back to our code. New route, it's here. So heroes slash new. This is how we are able to check our route in Remix. Here we have a couple of things, but pretty much what we have is an action that's going to be triggered whenever this form here is submitted. So we have our form, we trigger our action. This action is doing a couple of things. Once again, it's getting the request. By thanks to the request, it's authenticating our user. It's getting the form data that it's filled by the form. And then a couple of validations, and it's creating our hero. And yeah, this is pretty much what this is doing. Oh, and it's also triggering a redirect. This redirect is pretty much a 302 response. Like I said, leverages the web. This is an HTTP response. So yeah, that's how it works. And this is pretty much what it's doing. Now you might be wondering, how am I going to render all the heroes? Because if you look into here, each hero should have a random ID. Let me just add one here so you can see. As you can see, the ID is not the same from Batman. So I'm not going to be creating a route for everything because, well, this wouldn't be scalable. So this is where we leverage dynamic routes. By adding a slug here, by adding the dollar sign and putting in the name, Remix will say, okay, everything that's inside heroes and is not specified here, it will get into this route. This route is doing a couple of things, but it's pretty much the general concept of as a loader. Once the data is fetched, it returns it. This data is picked up by user data, and then we have a form to trigger or delete in this form as a corresponding action. And yes, this is pretty much how our application works. Okay, so now to wrap up, let's look at a couple of things that Remix can make easy for us. Remix stacks are a bunch of alternatives that we can use to start building our application with Remix. We have Grunge stack, Indie stack, Wolf stack, and pretty much all of them depend on whatever you want to deploy, what database you want to use, et cetera, et cetera. It's pretty great. Give it a try and check it out. So to wrap up this talk, let's get into the million dollar question, which is Remix versus Next. Well, here we have a QR code that you can scan. This will redirect you to the Remix blog, where they have a study where comparing Remix with Next. And during this study, they came to the conclusion of a couple of things. First things first, Remix is as fast or faster at serving dynamic and static content. It even enables a faster user experience even on slow networks, because like I said, you can make your server fast, you cannot make your user networks fast, and Remix makes it easier for us to, well, enable a faster experience even on these slow networks, like it's written here. Also, it automatically handles errors, interruptions, and race conditions. And this is super, super cool. It saves you so much time not having to implement everything by yourself. And all the real times in Remix are instant and decoupled from data. So yeah, does this mean you have to stop using Next? Well, I guess it's up to you. Frameworks come and go. Remix is super great, and it's super exciting to see all the amazing news that have been coming around it. And I definitely see a very, very, very great and shining future for Remix, and I want to stick around to watch it for the next couple of years. So yeah, before anything else, let me start by thanking you all. Thanks RemixConf for having me. This is a super amazing experience to be here speaking to all of you and learning from all the amazing other speakers about our common love right now, which is Remix. I've been Daniel Afonso. This is a QR code that you can check if you want to find me on Twitter or send me a message. Yeah, thank you so much. I hope you have a rest of a nice day and amazing week. See you around. Bye-bye.


Daniel Afonso

Remixing How We Give

Sergio Xalambri

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

Your Personal Remix!

Facundo Giuliani

Demystifying Web Accessibility

Hi, everybody. Thanks for joining my talk. My name is Josephine. My pronouns are she, her, and in the next couple of minutes, I will be talking about web accessibility and ways in which you can get started with it. So let's dive right in. What is web accessibility? Web accessibility means that the tools, technologies, and websites that we build are designed and implemented in a way so that people with disabilities can use them and participate equally on the web. It's also a basic human right as defined by United Nations. And now, if that's not enough for you and you're still wondering whether web accessibility is something for you or the people you want to use your website, there was a report by the World Health Organization and they found that over 15% of the entire global population are experiencing some form of disability over the course of their life. And of course, global data is hard to measure and the experience of disability as well. But even if it's just a ballpark, in my opinion, that's a super powerful one. And I'm really hoping that if you're coming at this maybe from a business perspective, that the sheer number of people that are affected is going to convince you that this is relevant also for you. Also, we're all growing older. And so this is going to even get larger in the long run, right? All right. So here on this slide, there are a couple of the different user groups that maybe benefit from web accessibility. And so we see here different kinds of disabilities or impairments like physical, auditory, cognitive, neurological, speech or visual disability. But we also see people without disabilities. So people may be using a smaller device like a mobile phone, or maybe you're using your remote control to put in your favorite show on the TV. We also have temporary disabilities like maybe a broken arm or situational ones, maybe a new parent holding a baby. Or if you have a slower internet connection, and maybe the images are not loading, you're going to rely on web accessibility and get some alternative text, for example. So a lot of situations in which web accessibility is super beneficial. And in practice, that can look like many different things, right? So it can mean having enough color contrast to be able that everything is actually visible on the page, being open to different input methods, not only the mouse and the trackpad, but maybe also a keyboard or assistive technology, using semantic HTML to provide enough context for assistive technology like screen readers, but also for your browser, for things like explaining unfamiliar terms, being open to the fact that not everybody has the same ground knowledge and that we have to adhere to these different standards or backgrounds, right? But what does that mean? Where can we start? Now that I have convinced you, hopefully, that this is important for all of us, how could you get started? And I'm actually going to switch over to the browser for this. This is Storyblock, the company I work for. We're a headless CMS. But that's not the point. The point is that we're currently doing an accessibility audit. And one of the things I did on our own homepage, for example, this is actually quite big, so I'm going to make it a bit smaller, was, for example, to run one of these general tools. There are, for example, the X DevTools. I'm just going to open this up, scan the entire page, and it's going to find a lot of issues. So now 30 seems like a lot. It doesn't mean that there's everything broken on this page, but it's going to walk us through what exactly is wrong here, right? So we have an element must have sufficient color contrast. I already mentioned color contrast, and in a minute, we're going to see how you could test for that. ID attribute values must be unique. And like this, step by step, it's going to walk you through all the things that can be improved and that you will need to have a look at in order to improve accessibility on your page, right? And this is a really good, so if I open this up, it'll provide you with more information. You can share it. You can identify it in the code. So this is really helpful for first overall look. Of course, it's not going to find all the issues. You will have to test them also manually, but it's a good starting point for sure. So I'm going to close this app, and I'm going to open up the next tool, which is the web disability simulator. So this enables you to experience what maybe different user groups experience your page as, right? And now I'm going to select here total color blindness, for example, and it's going to show me what people with color blindness maybe experience our website as. I can also learn more or reset and pick something else like red green color blindness, for example. That's going to look completely different, but everything kind of still looks visible, right? It's a good starting point. Now, if I switch here over to sunshine, you see we're going to need a lot more contrast to be able to read what it says, for example, on the button here. And it's really difficult to say, I think here is something written, but I can't really tell. So this already shows you there's lots of different use cases for web accessibility, right? And it's just very, I mean, this is really rough, but it's a good starting point for sure. And now if you want to get into a bit more detail on the color contrast, I have another tool for us. It's the color contrast checker. There are many different ones out there. This is just the one that I like best. And this is going to help you. You can pick a background color. I'm just going to pick maybe this turquoise and you can pick a foreground color and white. And we see here, we're actually failing different levels. So these are different levels of accessibility that you could choose to comply with. And AA is usually the most common one that people try to comply with. And we to comply with AA, we need a color contrast of 4.5 to 1, meaning that the background and the foreground are different enough to have a good ratio there. And with the turquoise against the white, we're failing that, right? So this is something to look into. And now if we were to check here, just for comparison, we see this really dark bluish color against the white writing gives us a really good score and we're passing all the different levels. So this is kind of where you want to aim at, right? Something that you can also read with maybe bright sunshine or people with visual impairments. Now, there are also things that I mentioned earlier, being open to different input methods. And semantic HTML really helps with that because it brings inherent functionality. And many things that we will need to interact, for example, with a keyboard, with our page. And now if I use the tab key to go through my page, I can go up here. Now I'm going backwards. You see, I have a focus style around my button and that's going to help me know where I am if I'm using the keyboard. And you see, it looks a bit different on the button. Something is happening, but it's not entirely visible. And if I didn't, like I wouldn't know where I was right now. If I tap to the next button again, it like really quickly flashes up, but it's kind of hard to tell. I think it's white and then same here. And now it's kind of cut off. So this is also something I would want to look into, right? What do the focus styles look like? Do they have enough contrast? Are they visible? Are they big enough? Do I know at all times where I am if I'm not navigating with the mouse? And one thing that I also want to take care of is that the tab order, so the way in which I go through the interactive elements on my page is correct. And if I say correct, I mean, in this case, the language of this page is English. So I would read from top left to bottom right, and this is how the user flow would go. And I want to make sure the tab order is the same. And I have another tool that we can quickly use to visualize the tab order. It's called Tab Ally. And it's going to help us show in what order the interactive elements can be reached. Just takes a second. And now we see here, we're going from the top across our navigation, then we jump down to the buttons, to the video. This looks good. And this is kind of what we want to achieve, right? We're going from top to bottom and from right to left. The only thing here to check would be, well, can I actually see the focus where I am, right? And that was already it. That was a really quick, deep dive into web accessibility. And I said deep dive, it wasn't deep. It was a quick dive into web accessibility. I hope you're curious to learn more. If you're interested in any of the tools, feel free to check out this QR code. You should find the tools and the links to the extensions there. Or if you want to discuss anything web accessibility related or really anything else, feel free to connect with me on the socials or via email. I'm looking forward to meeting you. Enjoy the rest of the conference.


Josefine Schaefer

Remixing a Symfony

Hey everyone, welcome. My name is Emily Kaufman. I'm a software engineer based out of Pittsburgh, Pennsylvania. I actually gave this talk at the, I was a backup speaker at the first Remix Conference. So if you ended up watching that already, this might sound pretty familiar, but my talk today is going to be about the performance journey that Harvey, the company where I work, has undergone over the past few years and how that ultimately led us to Remix. All right, so Harvey is a grocery delivery service where all of our products come from local farms and producers. So it started out, I think about 10 years ago, as a community supported agriculture program. If you're familiar with that, it's CSA. Basically you pay the farm some amount of money per year and then every week or every other week you get a box of whatever they happen to have produced in that time. So it's a really great way to support local, support your local farms and producers. So what Harvey did is it provided a platform so you could actually customize what you were getting in your box. So up until about three years ago, two and a half years ago, that's all Harvey really did. We had a number of farms on the platform from all over and we had provided the way for the customers to come in and, you know, log in, view the contents of their box, make, you know, additions if they wanted to swap out stuff and then they would wait for their delivery. And then the pandemic hit. So you might remember at the beginning the world was starting to close down. A lot of people in the Pittsburgh area turned to Harvey as their main source of groceries to avoid having to go into a grocery store. And on the other side of that, all these producers that were used to going to farmers markets or going to, like, or setting up booths somewhere so that you could come and actually make purchases, like they didn't really have a place to go anymore. And so they were coming on to Harvey as a producer in order to stay in business. So as I'm sure you can imagine, we had this massive influx of both customers and producers and Harvey began to grow and evolve from this CSA program into a full grocery store. So of course, during any kind of large scale growth in a short amount of time like this, you're going to experience some growing pains and we absolutely did. So this is a Lighthouse test that I ran in late 2020. Yeah. It was just a simple content page in Harvey, which is a symphony application. And we got this performance score. So this was like the JavaScript bundle, the API request, the database lookups, even with the minimal UI to render on this basic content page, we had a baseline score in the 30s. So this wasn't correct. Something wasn't adding up. And so this along with some upset customers, some customer feedback helped to catalyze this renewed interest and commitment to performance at Harvey. So the catalog page, which is where you go to view all the products, had recently, I think a year prior to that, been converted from the symphony jQuery twig combination into part of a new React single page application. And this was hit the hardest. So the dump to React had addressed many UX concerns that we had. It modernized our tech stack, but it was still falling short in terms of performance. So the underlying architecture just couldn't handle the weight of all the new products. It was taking upwards of tens of seconds just to add something to your cart or remove something or do a swap. And so many members were just dropping off the site entirely. But we have to remember that we had gone from offering maybe 30 to 40 products a couple years ago to probably over 600 at this point. And so the page just wasn't scaling correctly. So when we think about fixes for this, our first iteration was kind of this crisis mode. Our engineering team got together and we said, what can we do in the short term to fix a few of these issues? So we spent a few hours sitting around the network panel and the performance tab and just walking through every step of page load and organizing what we saw into a few groups based on who would actually be working on them. So we had DevOps and networking. We had the back end, which would include the API and the database, and then we had the front end. And from there, we took what we found and we triaged this into quick and easy wins, involved fixes, and this could be part of a future redesign. For DevOps and networking, we didn't have to do too much here because it's mostly handled by services and tooling, but it was worth it to at least sit down and walk through and make sure there weren't any bottlenecks. For the back end API, we had quite a few issues around image loading on the site. This is a hero banner that we have on almost all of our pages, and for some reason, it was taking like seven seconds to load and seemed to be blocking first paint. So we did a bunch of work around image optimization and caching, and that took actual seconds off of our page load time. So I can't speak to everything that my back end coworkers did, but more involved fixes included like updating the endpoints and database lookups to make sure that we're only querying the minimum needed, trying to avoid unnecessary and computationally expensive operations. An example of this is like anything that would have to go through a third party provider, like if we were checking a user's credit card information for one, we might only be doing this on like one or two pages, so it shouldn't be in a top level like layout component because then it's going to be happening way more than it needs to. Overall, all of these updates came around just because we sat down as a team and we stared at the dev panel for a few hours and just identified issues. For the front end, aka my problem because I'm the only front end developer at Harvey, this is how long it takes to actually download the content, you know, how big the script is, testing slower connections and all that kind of thing. So we identified several low-hanging fruit that we knew would be relatively small development effort but would drastically increase the user's experience. So we started there. For one, the bundle was just so big. It was too big. There was so much code that a user had to download before even getting to interact with the page and we used Webpacks. We used Webpack's bundle analyzer plugin, if you're familiar with it, and this helped us identify many problem areas that we were able to tackle. One of these being our use of moment.js localization packages. So we're mostly in the Pittsburgh area. We have farms all over but mostly at least in the United States. So there were many localization packages that weren't really relevant to us at this time so we removed those with setting the goal that we would eventually switch to using something else other than moment. I went through every dependency in the package.json and just tried to figure out why it was there, if it was still needed, if it could be updated, and we were able to remove a good chunk from there. So I have this fun anxiety-inducing screenshot of the performance tab. This is our catalog page. So one of the biggest problems that we had in the front end, especially on the catalog page, was just the sheer number of elements that we had. So I said before, at one point maybe we had 40 product cards. Each had an image and a few buttons. You know, normal e-commerce stuff. And now we have almost 600. So even without all the optimizations we're making now, two years ago, this page was fully functional. It was working fine. Because remember, Harvey never was meant to be bigger than a small CSA program. So one of the first things we did here after seeing this was to add lazy loading to the page and it immediately stopped crashing, which makes sense. But you can see in this screenshot here, we're basically trying to load like 500 images at once. Okay. So I won't dive too deeply into everything we did on the front end. Because I only have 20 minutes. But I have a non-exhaustive list here. So better code splitting. This could even be more thoughtful code splitting. Just really taking the time to think about what needs to actually be loaded on every route. So with our single page application, we hadn't put a lot of time into considering which modules actually needed to be on each page. So one of the things this led to was we split our member and our admin code into two separate projects with their own builds. And then I made a components library where the two could share from it. So that was able to reduce our bundle size by a lot. We started using text compression. We added this to all of our JavaScript files. And I think our CSS using gzip and that had a positive effect. So we were able to get a lot of a positive effect. Minimize and defer third party scripts. Sometimes this can feel like a constant battle with marketing. This is stuff like Zendesk, Hotjar, Analytics. Anything that maybe marketing is using to track events on your website. And so we went through these and just made sure that all the ones that we were using were actually still needed. And tried to identify places that we could defer them where we could. Minimize expensive API calls. I kind of touched on this before. But a lot of this was just moving where we were making these calls, like out of a layout and into a component or into a route level. Just so that they weren't all being made on every page. So all these changes that I mentioned, they led to a substantial difference in terms of page load. And especially on mobile. And they helped somewhat with the page interactions after loading. Like adding, removing, swapping card items. But we knew that our current design just wasn't going to support the new business model. The bigger grocery store model that we were trying to achieve. And so we knew it was time for a redesign. One thing we did, this is our redesigned page here. Instead of loading every single product on the page, we loaded them by category. So we just weren't having as many elements on the page anymore. Fun note on this, though. Our categories are growing big enough now that we're starting to look into pagination or something like that. Because of the growth. We removed parts of the product card. And like the description, the producer information. And we moved these into a details page. So that we weren't trying to load all of those for every product in the catalog. We generated multiple image sizes for each of these. So we had like a thumbnail, which you can see kind of at the bottom of this image here. We had a details view, which is this bigger one. The card view. And they matched how they'd actually be displayed on the page. We dropped some functionality. Like the swap button. We used to have it so if you were in your shopping cart, you could swap out. Like say you didn't want broccoli, you could swap it out for carrots. But it just wasn't adding enough value for the customer for the performance issue that it was causing. So we decided to get rid of it. And that kind of led to this way of thinking. Like when you include a commitment to performance as an essential tenet of design. So when you're thinking about performance every time you're building a new feature, the design is going to become leaner. So I find myself doing this a lot. So we'll be like, oh, we should add this to the site. This would do this. It would be really cool. And then we realized there's going to be a performance impact of it. And it's like, is it really worth it to add this much time onto page load? Like is it worth it to take that hit? And a lot of times the answer is no. Okay. Let's see if this loads. So our redesign page is going to be on the left. And the existing page is on the right. The redesign page, you can see, is loading substantially faster than the existing page. But it's still not enough. Okay. I wanted to get rid of all the spinners. And despite the fact that our load time was so much better, our lighthouse score was still fairly low, which was surprising. So, all right. Into a remix. In early 2020, I had bought myself a remix license as a birthday present to myself. And I had been messing around with it on several hobby projects, just testing out what it could do and just in general having a good time. It was for myself. And I realized that the co-location of page load data requests with the component, with the layout, might help us break out of this spin again problem that we were having, as the remix team calls it. So, I don't have anything deployed publicly yet, as much as I want to. But I was able to get our new grocery pages up and running with remix. And I think the results speak for themselves. I ran this lighthouse report just to get an idea of if, you know, it was going to make any difference for us. And yeah, you can see. So, one of remix's selling points is that it minimizes the request waterfall. And that was the case for us. In some parts of the application, we were making multiple API requests on page load. And you just had that spinner going in the UI. Let's look at this video. Okay. I'll do it again. So fast. There we go. Okay. So, this video is slightly skewed because the existing application has more third party integrations, like a support widget and a few more features overall. But you can still see that second wave of the requests that were fired in the use effects in the component. So, that's on our existing page. If I pop over to remix, this is the same waterfall, but on the remix version. So, in the remix version, we have a longer document load time, but a minimal number of additional requests. And since we're only loading what's needed for that one page, this JavaScript that does load is a lot smaller. So, this is all without taking full advantage of some of the features like nested routing, which we're starting to, you know, work on now. But yeah, it was like an immediate improvement for us. It was really exciting. So, going forward, our plan is to continue to keep moving these existing pages that are currently in our member facing code into our remix application until we get to a point where we have enough that we can deploy it and, you know, have it be public. But using the framework has just become a natural progression of our performance journey at Harvey, and it's absolutely been worth the effort. And it helps that I really enjoy working in it. So, if we've learned anything over the past two years, it's that performance and building for scale are non-negotiable when we're releasing new features. It has to be baked into everything that we do and constantly checked for regression. So, our product list, our customer base, they're still growing at a rapid pace. And yeah, I feel confident that what we're doing now is going to support what the business looks like maybe like five to ten years down the road. So, it's an exciting time. All right. Thank you for listening. Again, my name is Emily Kaufman. If you have any questions, you can find me on Twitter, or you can read the blog post behind this presentation on my website. So, thank you.


Emily Kauffman

Fire-side chat on Remix

Chance Strickland

How Remix and Prisma Make Frontend Devs Fullstack

Sabin Adams

Remix Architecture Patterns

Andre Landgraf

React Advanced Conference 2022

Hello, everyone. Welcome to my talk called React Remix. So let me start by introducing myself. My name is Daniel Afonso. I'm a developer advocate at OLX Group. I'm an IoT ambassador, and you can find me on Twitter and any social network at the handle DanielJCAfonso. So what is this talk about? Well, this talk is actually about WebPH APIs, HTML forms, form data objects, URL adders. Now, you might be wondering, isn't the title of the talk React Remix? Yeah, because these are all things that Remix allows you to use. Now, I know that we all might be a bit tiring of new JavaScript frameworks always showing up, but bear with me because Remix makes something really good for you, which is when you learn Remix, you accidentally learn the web, because by using Remix, you'll get leverage to all the things that have been around for around the past 20 years, something like that, which are working very, very well, and we'll continue to use them. Now, you might wonder, where did Remix come from? Remix was created by Michael Jackson and Ryan Florence. It started as a closed project and it turned into an open source in the last past years. And yeah, it's super great. Now, what is Remix? Remix is a full stack web framework that lets you focus on the user interface while working back through web standards to deliver a fast, sleek, and resilient user experience. Now, with Remix comes its main philosophy, which are actually three or four things. Let's start with the first one, which is embrace the server client model. Well, you can not make your user network fast, but what you can do is you can make your server fast. Because of this, you can be allowed to reduce and decrease the amount of stuff you send over the network. And this is why Remix is super great, because it doesn't need to ship the skeleton UI, all of it, because Remix will fetch, and you can even prefetch at certain scenarios, this amount of data before your page being rendered all on the server side. Remix also works with the foundations of the web by using browsers, HTTP and HTML. These are technologies that have been around for a long time, like I said, 20 years. So they are pretty solid. Remix will embrace them fully. And by combining stuff like HTTP caching, Remix focus on URL for assets, dynamic server rendering, and HTML features like, for instance, the prefetch in the link, which can send link URL prefetch, you have all the tools that you need to make your application pretty great. So browser and HTML got really good in the past 20 years, so Remix just leverages it fully. Using JavaScript to augment the user experience by emulating browser behavior. So most recent frameworks only have read APIs for data. Remix has both read and write. So by leveraging a small thing called HTML forms, Remix will pretty much use what has been the basic for data mutation since the 90s. Remix uses the forms and embraces and augments that API. This will enable for you to have a data layer in your Remix application with or without JavaScript on your page. And this is the amazing, amazing part of Remix, which is you probably don't need JavaScript on your browser. By adding JavaScript, this will allow Remix to do a couple of things. For instance, not downloading and evaluating JavaScript and CSS assets, and only fetching data for the parts of the layout that change. So JavaScript in Remix, it's what's called progressive enhancement. Finally, part of the philosophy, Remix doesn't over abstract the underlying technologies. And this is why it's said that if you get good at Remix, you get good at the web. Because Remix APIs make it convenient to use the basics and the fundamentals of browsers, HTTP, and JavaScript in general. These technologies are not hidden from the developer. You can use them. So let's go to the three basic things that you just need to start in writing code with Remix. So first thing, very important, is nested routing. So nested routing is pretty much the general idea that you can couple segments of the URL to describe your component hierarchy in the UI. So let's look at this example. Here we have two routes, a user profile and the user account one. Both UIs are very similar. In both of them, we have the user described with the name of the user and two tabs, one for the profile and one for the account. How nested routing works is whenever you trigger either the profile or the account route, it will render only the part that's specific inside of it. So when you click on profile, the nested route responsible for the profile will be rendered inside of this part of the UI. And the same for the account. When you trigger the account, the nested account part will be rendered inside of this. And this is why nested routing is super powerful, because by only adding new sections of the URL, you can keep adding more and more and more nested parts of your application. So this is one of the main fundamentals for Remix. The second one, it's data fetching and mutations. Well, we might be using useEffect, React, Query, and SWR for a couple of years. The thing is, Remix makes this so, so, so much easier. So let's start with the first pillar for data loading. So here we have a component called heroes. What this component should do is get the list of heroes and render them inside of a div with the hero name and the hero ID. Now, probably what we would do here is we would do a useEffect or a React query fetching thing. The thing is, we don't need it. By using a loader, which is one of the pillars for Remix, this is a function that will be called on the server. You can use it to fetch your data. And then by returning JSON, which is pretty much a wrapper over the HTTP response, you can return your data. And the same for mutations. Like I said, Remix leverages forms. So by using a form method post, whenever you submit, this will trigger an action instead of a loader. And this action will run on the server. You access your form data that comes on the HTTP request. And you perform your mutation. And yeah, these are the pillars for Remix. Now just to wrap up in these quick minutes, seconds, Remix versus Next.js is a question that I've seen a lot of times. Well, in a study by Remix and Next team at Verso, they discovered that Remix is as fast and faster at serving static and dynamic content. It enables a faster user experience, automatically handles errors and race conditions, and build times are nearly instant. Does this mean you have to stop using Next? No, it doesn't. But I really suggest you give Remix a try. So thank you so much for watching my talk. I'm Daniela Fons, and see you next time. Bye.


React Summit

React Summit 2022

Remixing WordPress: Building a Headless Site with Remix, WPGraphQL, and Web Fundamentals

What's up, React Summit? My name's Jeff Eberhardt, and I'm a Senior Developer Advocate at WP Engine. The title of my talk today is Remixing WordPress, where we're going to spend about 20 minutes building a headless site with Remix, WP GraphQL, and a few other open source plugins. But before we get started, maybe we could talk broadly about what headless WordPress is. With the rise in JAMstack architectures, we see a ton of SaaS offerings in the headless CMS space. But if you're looking for an open source alternative, a lot of people don't know that WordPress can also become a headless CMS. And with WordPress being the most popular content management system, which is powering roughly 40% of the web at the time of this recording, there are chances that your content teams are already well-versed in the WordPress platform, so there can be a lot of reasons to consider this as an option. So let's take a second and talk about what traditional WordPress gives us. Traditional WordPress is your basic monolithic software platform. The visitor maybe interacts with a CDN by typing in a URL into their browser bar, but ultimately all of those requests are served by WordPress core. And any of the developer experience that needs to happen, whether that's theming or plugin development happens directly with that WordPress core software, as do the publisher interactions. So when people are creating content, they're doing that as a part of the WordPress monolith. Now when we look at headless WordPress in comparison, that offers the developer a lot of flexibility. The experience for the visitor is still the same. They type this URL into a browser bar, but instead of their request being handled by WordPress core, it is actually handled by an application that we ultimately determine what that looks like. And so in the example today, we're going to use Remix as this Node.js runtime, but that could be any potential front-end framework, whether you're a fan of Nuxt or Next or you want to use SvelteKit. That is entirely up to you as the developer, and all of your effort is going to be into developing that platform. And all of that interacts with WordPress through either the REST or GraphQL APIs that we're going to explore today that are a part of WordPress core or added via plugins. But the ultimate benefit is that the experience for the publisher or the content creator doesn't change and they get to use WordPress sort of as is to create and publish content while we as the developers get to take the benefits happening in the front-end framework space and bring those to our users. So let's get started. We don't have a ton of time, so I'm going to hop right into building out our headless site. So the first thing that we'll need to do is create a new WordPress site. And I'm going to do that using the local development tools. I'll click create new site, give my site a name, select the preferred customization option, create an admin username and password, and then I'll let local install those services for me on my local machine. If you have a WordPress site already, feel free to use that as well and install the plugins there. Once that's done installing, we can open up the WP admin panel, log in, and then we'll need to install a few plugins. First we'll want to install the WP GraphQL plugin, which essentially turns our WordPress app into a WP or a GraphQL API. You can install and activate that plugin. And then we will also be installing a plugin called Atlas Content Modeler, which is a headless focused content modeling plugin that will allow us to create complex content types and make those available over GraphQL immediately. Now with our plugins installed, we can work on creating our first content model. To do that, we'll use Atlas Content Modeler to create a content model around projects. Do that by specifying a singular and plural name, determining the API visibility of our content model, whether it's public or private, choosing an icon for the post editing screen and creating a description for our users to see. When we click the create button, that will automatically generate the model and begin the process of adding it to our GraphQL API. With our model created, we can begin the process of adding fields to our model. We'll start with a text field that stores the name of the project. We'll use that as the entry title, make it required, and add it to our model. After that, we can add a date model that will store the due date for the project, make that required as well, and add a description for that model that will be displayed to our users. From there, we will add an additional text field to store the assignee's name for the project and this will be the DevRel Associate who is assigned to a particular piece of content. Make that required as well. And then we will add one last rich text field that will be the project description. So now that we've created our project content model, let's add some data. We'll open up the post editing screen and fill out all of the fields that we specified as we created the model. And then when we're done, we can publish that piece of content to make it available for use in our application. Now that we've seeded our project with some additional data, let's explore the features of WPGraphQL in the Graphical IDE. The query composer feature of the Graphical IDE allows us to visually explore our GraphQL schema and select individual content types and their nodes and properties, all while composing a GraphQL query that we can run dynamically and to return actual data from our WordPress site. So now that we understand the resources available to us in WordPress to model data and to serve that data over GraphQL, let's talk about how we're going to integrate Remix into that equation. So I've got a pretty basic Remix app set up right here with a few dependencies installed that we're going to need to communicate with our WordPress server. So one of those is the GraphQL package. I've also installed Apollo Client and I've done some styling with Tailwind CSS. So where we can get started is in our index.js route. We can look here, we can see that we're importing two different components. We've got just a basic header and a basic project component that's going to list our projects out in cards on this page. So what I'll do over here is in my terminal, just click npm run dev to get this dev server running. And then I can come back over here and we'll just refresh on localhost 3000 and see that this test data array where I've got some projects that we'll eventually swap out with data from our WordPress site is rendering right there for us. So the next thing that we'll want to do is configure Apollo Client to query our GraphQL endpoint from our WordPress site. To do that, we'll begin by creating an Apollo.js file in the lib folder. And then we'll add some import statements to import those needed resources from that package. And then what we'll do is create a default export that is going to be our client. And we'll set that equal to a new Apollo Client. Now we'll pass in some configuration parameters. And one of the ways we can get our GraphQL endpoint is to hop back into our WordPress site, open up the WP GraphQL settings page and copy and paste that into our project. And we'll also create a new in-memory cache that we can use to help speed up our application. And once we're done, we'll save those things out. So now that we've configured Apollo Client, I'm going to create a new file to contain my data fetching code. And really this part is entirely up to you about how you want to structure or where you want this code to live. So I'm going to create a file called WordPress service. In there I'm going to import the client that we configured in the last step. And then also the GQL object from Apollo Client. So then we'll create an export and export a function called get projects. And then from here, what we'll do is hop back into our WordPress WP GraphQL instance, copy the query that we were using, and then we'll create a new query, open up a new template literal with GQL and paste that query in there. Then what we'll do is create a new variable called response and we will essentially use the client to query and pass in that query to that configuration object. Then once we get that response back from Apollo Client, we will dig down into the object that we get back so that we return the individual project nodes. It's always helpful if you're unsure of how to traverse a particular object, you can always hop back into WP GraphQL and visually look at what the data looks like that you're going to get back from that API call. Okay, so now that we've got this function stepped out to make our GraphQL query, let's pause for a second and just take stock of where we're at. It's worth mentioning that although I've created this WordPress service file with these export functions, how you handle this organizing this data fetching code is really entirely up to you. I know lots of React developers in particular are fans of co-location, so having the code that does their data fetching also inside of their components, there are ways that you can achieve that as well by having some of this code happen in the individual route files. So this is just a choice that I've made because I like this organizational pattern, but that doesn't mean that you couldn't make another choice and Remix is unopinionated about this as well. As we transition into looking into how we use this function to load data into our route components, Remix is actually opinionated and we'll talk about some of those differences. Next we'll take a look at this index.jsx file in our routes folder. The Remix framework uses a file-based routing system, which is kind of similar to what you might get in Next.js or Nuxt if you're coming from the view world. So there's a decent amount of overlap in how this framework handles routing. And we'll look at some other more complex examples in just a little bit. But so if we open up our index.jsx file, we can see that we're importing some components in here and then we're exporting this index component that returns all of these jsx elements that are going to render our application. But right now we have all of our data hard-coded in this projects variable. And so the next step that we're going to want to tackle is loading our data dynamically from WordPress. So to achieve that, we'll just throw a couple more import statements up here. And I'm just going to copy those from off screen real quick. We're going to import two different things. So we're going to import our get projects function from this WordPress service file. And then we're going to also import this use loader data hook from Remix itself. So once we've done that, then we'll come down here and we're actually going to create another export. So this is going to be an async function named loader. And that is a Remix convention. And what's going to happen is when Remix goes to render your components, it's going to call whatever is inside of this loader function on the server. And it's going to go out to your service, whatever that may be, in our case, WordPress and GraphQL to get some data. And then we will be able to access the data that this loader function returns using the use loader data hook. So for us, all we need to do in this example is add a return statement, and then we're going to await the result of get projects. And so again, that's one of those reasons that I personally like to develop in this way. So I like having a service file with all of my different data calls out there so that my route components can be very clean. Alternatively, you could certainly do some of this inside of this loader function. That's totally up to you and how you want to handle it. And to be honest with you, I'm not sure Remix really cares either way. But so we've got this loader function, we're doing some amount of work in there, and that's up to us to determine what it is that we want to do. And then what we'll do down here is instead of hard coding this array, we can come and we can just use the use loader data hook. So we'll set projects equal to the result of this use loader data function. And so if we save that out and refresh our page over here, we can see that boom, that worked just as we expected. When this index route gets called, we go to render that component. This loader function calls get projects on the server. We return that data and then use that data via this hook to populate these project components down here. So fantastic. We've got our index page working the way that we want. But I think it might be time to pause for just a second and discuss this opinionated choice that the Remix framework makes. I've worked with a number of different Next.js projects and other React projects where some of the data loading that we're doing happens entirely on the client. And so if we're used to using the Apollo like use query hook, for example, and having those components make those calls out to our GraphQL server on the client, this is a bit of a paradigm shift if you will, right? Because each one of these loader functions is only getting called on the server. And I think the Remix team made that choice for a really good reason. And they've enumerated those reasons in a lot of videos, so I won't belabor them and I encourage you to go check out some of the Remix singles to get a good idea of those. But in some ways, it does help us as developers simplify the type of code that we're writing, right? If we look at a framework like Next.js, for example, where maybe we're doing static site generation and then some things are getting loaded on the client, it has a tendency to get a little bit messy, right? Because we have all these different abstractions for these different use cases. I think Remix sort of simplifies that. It says this is the one way that we're going to load data into components. And so it makes that a little bit easier. It also makes it a little bit easier to handle credentials, right? If I were making authenticated calls to a database, since all of this data fetching in the loader function is happening on the server, I don't have to worry about leaking my credentials into the client. So there are a couple of pluses to this that I definitely recommend you explore if you're new to Remix and kind of compare and contrast with whatever your framework of choice is at the time. So now that we've got our index page looking the way that we want, each one of these is actually a link to an individual project. But right now, if we click on it, we get a 404 error. So what we'll do in the next few minutes is just dig one layer deeper and look at how we would handle this dynamic routing example with the Remix framework and WordPress. Okay. So for our project to handle this dynamic route URL, we're going to need to make some changes to our routes folder. We can see that the URL that we're sending the application to is project slash the slug of the particular project. So inside of our routes folder, we will create a new folder called projects to match that part of the URL segment. And then inside of that projects folder, we're going to create a new file called $slug.jsx. And this is going to be the component that we export. So I'm just going to come over here real quick and copy this from off screen and paste that in just so we can take a look at it. And we'll go ahead and save that out. And then we'll sort of just talk through a couple of different things here. And we can see already in the terminal that we've got some work that we need to do. So let's hop back. I'm going to save this one more time. We'll hop back into our WordPress service and then get going from there. So we can see that our component is using this get project by slug function. So we'll hop back in there and we'll go ahead and we'll stub that out. And so this isn't going to return anything at the moment. Get project by slug. And then this is going to take the slug as a parameter. And so now that we've got this stubbed out, let's hop back into our WordPress instance. And this is where we'll use the graphical IDE to create our GraphQL query. So again, using the graphical IDE in the query composer, we can use those tools to help us visually create and format a new query to get our post by the slug. And if we open up the individual sort of project node inside of the query composer, we can use that and specify the type of ID that we want to look up the post by. So in this case, we'll use slug and we'll grab an ID from our WordPress site and pass that in. And then what we'll do is also add in all of the additional fields that we had on our previous query to make sure that all of the data is the same. We can just click those to add them to the query. And then once we're done, we can again, preview the result of that query by just running it in the IDE. And so once we have our GraphQL formatted the way we want and making sure that it's returning the data that we want, we can copy it and paste it back into our WordPress service file. We'll make a few changes inside of this GQL template literal to parameterize this query so that we can pass in the ID. Then after that, we'll actually make the query with our client object and pass that formatted query into it, as well as a variables property that takes an object where each property in that variables object, like ID, for example, corresponds to one of the variables that we parameterized in the tag template literal. Then we'll also just sort of traverse our response from GraphQL and return that to our loader function. And as always, if you're kind of confused and you need help figuring out what your data looks like, you can always use the GraphQL IDE to explore that. So it's worth talking really quickly about the loader function as it's implemented in the slug.jsx file. A lot of this should look very familiar to what we did in our index file, with the exception of this params object that is getting passed into the loader. This is how we access those dynamic URL components. So $slug becomes params.slug, and then we just pass it into our get project by slug function that we pull in from our WordPress service. And if we come over here and we refresh our page, you can see that everything is working as we expect. And now we have both an index page and dynamic URL segments that are looking up individual posts. Thank you so much for coming to my talk on Remix and Headless WordPress. If you're interested in learning more about the open source Headless CMS alternative and some of your favorite front end frameworks, be sure to follow me on Twitter or check out some of the content at developers.wpengine.com. Thanks. Thanks.


Jeff Everhart

Localization for Real-World Use-Cases: Key Learnings from Onboarding Global Brands

If at any point you find my talk boring, you might want to just pull up your phone here and take a photo of that QR code. Book yourself a demo, get a look at Sanity, get an understanding. Otherwise, you can have a listen to me over the next few minutes. So, good day everyone in the room and a big hello, internet, to everybody on the live stream. My name is Simeon Griggs. I'm a solution engineer at sanity.io. And I come here today with two goals in mind. Two. One, I'm going to talk to you about localization. And I want to bring, because I know it's been a long day already, I'm going to bring the energy of a thousand exploding suns to localization because I know it's a topic that just excites people to no end. But two, I do have an ulterior motive. I am a narcissist and I am obsessed with conference speaker photos. And I'm really hoping that there's some photographers in the room. I just want to make sure that I leave with a bit of, you know, a bit of that thought leadership sort of style. So, I'm hoping somebody captured that or maybe there's something a bit better. Well, it looks like I'm doing an open mic night holding my mic today. I'm going to talk to you about localization in the real world. I am from Sanity. Sanity is a content, it's not a content management system. It's a platform for structured content. It means that you can customize your CMS experience to be anything you want to if you want to make a validation rule on a document that you need to solve the day's Wordle in order to publish it. You can do that. You don't need to, but you can. And we say that content is data. What does that mean? Well, let's unpack that by saying what the opposite is. Who listens to podcasts at 1.5 speed? Because I figure there's going to be enough of you that you're going to be able to hold up if I keep talking like this for the whole time. So you built a website like this. I've got websites like this. And back in the day when I used to sling WordPress websites, who used to build WordPress websites for a living? Yes, my people. And back in the day, you would have looked at this and you would have said, what is the content model of this page? And you would have said, Simeon, the content model for that, sir, is a page. And you would have made a file called template-course.php and you would have made that as a page and the lessons would have been child pages of that page. But that's content as presentation. Sanity focuses on content as data. And if you're still doing WordPress, I don't know, they're all blocks or something now, but it's not right. So let's look at this website again. This is made up of disparate pieces of content that are connected, but we don't have to focus on the presentation of it as a website. It just happens to be in a website. This is content. This is course data, presenter data, label data, lesson data, and most importantly of all for today's topic, this is language data. And language data is really important because that can be internationalized differently based on that content itself. So let's consider our presenter model. I've got a name, a title, and a photo. Now only two of those things are going to change if I need to internationalize this document. My name is always going to be the same. My photo is going to be the same. So if I have multiple language versions in that document, I'm going to make multiple language versions of that field. And so if I'm looking at a lesson, well, all of these are text. So it would make sense to have all of these be localized versions in this document. We might as well just make localized versions of that document. And this is the sort of flexibility that Sanity gives you, is that you get to internationalize things how it makes sense to the content, not how it makes sense to us. We don't tell you how to do language internationalization because to us, everything's data. Language is a data. This is how you set up languages in Sanity because everything's JavaScript. So it makes sense to a developer, right? You just map over fields or map over documents and create language-specific versions of those. And then this one config file can spread to your Sanity schema, to your plugins, off to translations APIs and services, off to your Next.js or Remix routes, and it all just comes from this single source of truth that you check into GitHub, you deploy into the studio. And that's localization in the real world. So as a solution engineer, a lot of my job is presenting Sanity to customers that we have. But the great thing about how flexible Sanity is as a content platform is that our customers tell us how they're doing things. And so a lot of the rest of the talk here is showing how our customers are showing how they have done internationalization in our software. The problem is I can't tell you any of their names. So I have to like just talk in weasel words, kind of. So this internet-connected speaker company that uses Sanity, they do key value pairs. So if you've done localization in Sanity, you've probably done this sort of thing already. This is looking at a Google Translate plugin that we have so you can type content in one language and have that automatically be translated into multiple other languages. And you can set up key value pairs. So usually you would store that in JSON. You can give your content teams a content-editable version of that. There's a particular German fitness brand that we also work with. They extend the model. They've got markets and languages. Some markets have multiple languages. Some markets have a single language. No two markets might have the same language, but they can still provide the same experience in here. So not every market is creating the same content, but markets are creating content in multiple languages and you can do all of that in Sanity. And you can set that up how you like. And this is an administrative view. But they're able also to have that inform their user roles and permissions. So now a Canadian author who logs in only sees their content, even though it's all administered from the one data set. Is everyone feeling exhausted with the way that I'm talking? It's probably too much. So this multinational conglomerate does the same thing, but they're in like 75 markets in one data set, 75 different market-specific websites with multiple languages, all from one data set, all from one Sanity project, plus global content. People are able to reach into another data set and reach into another market and pull content in and be able to translate their own version of that. So here's like the global version with the markets as well. And this is that thing about reaching out that I talked about. And then there's a particular Swedish music streaming company that happens to use Sanity that you probably can't guess who it is. They use 22 languages, custom markets. Markets aren't in code. Their content editors are able to create markets. If they want to say this line of text can only be seen in countries where this particular plan is available, they can do that from one document. And here it is. So there's a lot to unpack here. Let's go through it very quickly and I'm almost done. I swear, this thing's flashing at me, but I'm almost done. They offer all of their market-specific content in one document. And so here we've got some Norwegian content, some United States content. If we have a look at that from the United States, we only see that content. This is because we store content as data. That's because it's an array of objects, that text. If we have a look at the Norwegian version, we're filtering that out. And we're not overfetching, overfetching, sounded like a Kiwi there, overfetching and then filtering it back out. We are doing this at the point of query because we have our own query language as well. You should come and ask us about that. So number one, content is data. I am embarrassed to try this, but I'm going to do it anyway. Let's do a call and response. I say content, you say is data. Content. Content. It worked! Internationalized content by its domain. Don't let us tell you how to internationalize your content. We can show you best practices, but you're able to do it how it makes sense to your organization, which is kind of this point. Localize how you should work, how you need. I think I wrote that one. I'm responsible for it. Anyway, so if you want to have a look at that demo, if you still have your photos out, cameras out, have a look at the demo or come and see us at the booth afterwards. One more thing. Sorry, I thought I was done, but I added these slides very recently. We just launched the brand new version of Sanity Studio, version 3. Can your CMS do this? Now the whole CMS is just a component that you can load into any React application. So at the conclusion of all these lightning talks in the next break, run. Don't walk to the Sanity booth and we'll show you Sanity Studio inside of a remix application that you can put it wherever you like. It's never been so flexible. There's never been a better time to be a Sanity developer. There's never been a better time to set up a, I was going to say headless CMS, but I'm not allowed to say that, a platform for structured content. Thank you. I'm going to go ahead and close this out.


Simeon Griggs

Avoiding CSRF with Remix 

Hi, and welcome to my session on avoiding CSRF with Remix. This is a lightning talk, so we're going to go through this in a pretty whirlwind fashion. So let's start off by talking about what CSRF is. So like most security exploits, it's got an acronym, and it stands for Cross-Site Request Forgery. And in this scenario, basically the attacker tricks the user into accessing the URL, and then this URL will perform an action using their existing session. So a simple example, or perhaps the worst example, is an image with a URL and that URL performs an action. So before you say, no, I want to write code like this, I've seen this in apps that I've audited, and obviously the first thing the user is doing wrong here is they're using GET to perform some sort of action. But equally, this kind of exploit can be achieved even if it's using POST, and we do that by having an iframe with a hidden height and width, and that embeds a separate URL, and in that URL we have the form that POSTs to that endpoint, and we have an onload function that submits it the second the form is loaded. So let's talk about Remix a bit. Remix gets you thinking about actions in terms of the building blocks of the web, which is the HTML form element. And if you've been building apps with JavaScript, you've probably been using like Fetch or Axios, and in these scenarios, CoreOS protects you, unless of course you're using access, allow origin, star, and you're allowing credentials to come through, and in that case, you're in the same boat. So because we're submitting forms again via straight up multi-part form data, we need to think about cross-site request forgery. So let's have a look at a simple Remix form example. We've got a primitive form here with a text field and a submit button. We've got some sort of loader to check the user has got authenticated session, because cross-site request forgery does require the user to be logged in. You know, you're performing an action using their existing session that they didn't intend to do. And so we're not going to get the details here, but yeah, the loader is making sure the user's got a session. We've then got an action in our component that does some sort of write to the database or similar, something that could perform some sort of action that can't be reversed. So how do you avoid cross-site request forgery with Remix in this scenario? Well, the first thing you should do is set the same site attribute on your cookies. So you can set that to lax, which will mean the browser will only send the cookies if it's a GET request coming from another domain, or you can set it to strict, which means it won't send any cookies for any requests that originate from another domain. So you might need to check whether you're using some sort of authentication flow that redirects to other sites as to which is the most appropriate for your site. But unfortunately, according to OWASP, this isn't enough and we shouldn't replace having a token. And the main reason for that is that only 93% of browsers support the same site attribute at this stage. We're almost there. Your app might have higher depending on your user's browser mix. So the token-based approach is commonly called synchronize a token pattern, and it's basically a four-step process. The first thing is you have to generate a unique token per session, per form. You have to transmit that with the form. You have to send it back when the user submits the form, and then you have to securely validate it on the server side. So we start by generating some secure random keys. We generate a hash salt, and this is something that you shouldn't store in your database. It should be on disk or an environment variable so that if your database is compromised, even then the hash salt's not leaked. You should also have a private key. And both of these you can generate using the random bytes package from the crypto. So the first step is to generate a unique random seed per session. And so we do this by checking if the seed already exists in the session. If it does, we use that. If it doesn't, we generate a new seed using, again, the random bytes function, and we store that in the session. Then we need to generate a unique token per session and identifier, and in this scenario, the identifier would be something unique for that form or operation. And this prevents the same token being valid for two different operations and prevents token reuse. So to do this, we will take that hash salt, we'll take our private key, we also take the CRS seed, we combine the three together and we create a HMAC, digest that, which is basically a hash, gives us a nice unique token. We have to transmit that token with the loader. So the first thing we do is we generate the token and we return it in our loader data. And that means we can then get that back in our form by using the route data. So we get our CRS SRF token from there, and we transmit that in the form in a hidden field. We then need to validate the code. So if we write a nice little utility function for validating the CRSF token, it will regenerate the token based on the unique identifier and session, and then it will compare the two using timing safe equals against the version that was submitted with the form. And we use timing safe equals here to avoid timing attacks. So how do we use this utility function? In our action, we can just call validate CRSF token using the value from the submitted form. And if the two don't match, then we throw an error. So that's a whirlwind tour of CRS SRF validation for Remix. If you've got any questions, please contact me via the GitHub Discord server for this conference or you can message me on Twitter. Thank you.


Lee Rowlands

Node Congress

Node Congress 2022

Server-side Auth with Remix, Prisma, and the Web Platform

#remix