React on the Edge

Hi there. Welcome to React on the Edge, building React applications for resource-restricted Edge devices. My name is Amir Sami. I'm a staff software engineer at S&C Electric Company. Just so we're better acquainted, I'll just tell you about myself real quick. In my free time, I like to bake delicious baked goods like this pie. I like to program. It's not just a profession. It's a hobby of mine as well.

Now, I work for a company called S&C Electric Company and S&C Electric is a global provider of equipment and services for electric power systems. We were founded in 1911 in Chicago, where we design and manufacture switching and protection products. Today, our diverse global workforce develops innovative solutions for a more intelligent and resilient electrical grid. Building on this legacy of technological innovation and customer service, S&C empowers the transformation of the grid for an outage-free, sustainable electrical energy future.

So I'm sure we've all heard of React because we're at React Summit. And when you think of React and React applications, you think of creating them for web devices, right? For a browser. So a desktop device or a mobile device with React Native, for example. But what about things that go outside of the web browser, outside of these types of devices? What about the Edge? You're probably wondering, what the heck do I mean by the Edge? The Edge can mean a bunch of different things. But in the context of this talk, I'm defining Edge as a multitude of different devices such as a kiosk or sort of like a point of sale system that has its own built-in screen.

But in the context of this talk, I'm defining Edge as a multitude of different devices such as a kiosk or sort of like a point of sale system that has its own built-in screen. It could also be a more embedded device, like a Wi-Fi router. I'm sure you've all had a Wi-Fi router and had to configure some settings in it. And the way you do that is you navigate to a web URL, which is served by the Wi-Fi router. And then you are configuring the Wi-Fi router settings that way. Other HMI or human machine interface devices that have some sort of display that you're interacting with.

And lastly, just for fun, a rocket. And by this, I mean specifically this SpaceX Dragon capsule, if you remember from a few years ago. They hosted or they created a web application that the astronauts, which is really cool to say, that the astronauts were using to interact with their Dragon capsule. So all of these together, you can create React applications and deploy them to any sort of Edge device like the ones I just defined.

Now there are two separate subcategories within this that I'm breaking these up into for the sake of this talk as well. So there's devices that have their own screen, so it's kind of a closed system. And that's what I would put like a kiosk or a point of sale system or the Dragon capsule, the UI for the astronauts. And then there's devices that don't have an interface, but rather are sending a web application to a client device to consume, like a laptop or desktop device or a mobile device as well. So how do we build React applications for these sorts of devices, these sorts of platforms?

But it's really cool to see web technologies running in something crazy like a Dragon capsule that goes to space. So we can create React applications for these sorts of devices.

Now there are two separate subcategories within this that I'm breaking these up into for the sake of this talk as well. So there's devices that have their own screen, so it's kind of a closed system. And that's what I would put like a kiosk or a point of sale system or the Dragon capsule, the UI for the astronauts. And then there's devices that don't have an interface, but rather are sending a web application to a client device to consume, like a laptop or desktop device or a mobile device as well. So how do we build React applications for these sorts of devices, these sorts of platforms?

There's four different things that I want to talk about specifically to help you deploy applications for these sorts of platforms. And the first one being PWAs or progressive web apps. So like I just mentioned, devices like a Wi-Fi router, traditionally to send a web page to your device, your client device, just like any other web server would, which is exactly what we're used to for developing web applications.

But there's a handful of problems with building web applications or React applications for edge devices this way. The first being is that there is a chance for slower unstable network connections. In the case of a Wi-Fi router, it's not necessarily true because it's a Wi-Fi router that is supposed to be pretty stable. But if you think of other edge devices that are broadcasting a wireless signal, for example, or just serving a web server, web application, the connection might not be stable because it might be over Bluetooth or Wi-Fi from a board that has underpowered chips. It could be over something such as a serial connection or an ethernet connection as well that might not be as stable as well as just being slow.

It could be over something such as a serial connection or an ethernet connection as well that might not be as stable as well as just being slow.

Next is resource limited. So if you've ever worked with these sorts of edge devices and teams that are working more closely with the hardware side, you'll know that there are a lot of resource restrictions on these devices. And so if you try to build a traditional web application or React application, let's say it's maybe like 500 kilobytes large or 300 kilobytes large, they'll come to you and say like, oh, you know, we don't have the space physically on the device to store your application, let alone the server that serves your application to the client side. So there are a lot of resource restrictions that come with deploying applications to these edge devices.

Then there's unnecessary storage of application assets that goes in hand with the resource restrictions. So if you want to have images or videos or docs or PDFs or whatever, any sort of static asset, you run into the issue with that just the storage resource restriction on the device. Then there's heavy network traffic for first paint. So if you're structuring it like a traditional web application in combination with the slow or unstable network connection, if you have multiple network requests going back and forth through to retrieve multiple resources, your application could either lag or could just, you know, potentially break if the connection becomes really, really unstable. So that's another issue.

And lastly is if again, if you've worked with this sort of platform or deploying applications to these sorts of embedded platforms, you'll know that any sort of upgrade, whether it's to the UI or to the firmware, requires a firmware upgrade because the web application is stored and hosted and served from the embedded device. And I don't know about you, but I don't know when the last time was that I upgraded the firmware on my Wi-Fi router, for example, or even my motherboard on my PC. And, you know, that causes a lot of issues, you know, in the current situation where there's a lot of CVEs coming out like we've seen in the past year, addressing those or fixing those can require a really large lift from your user. And that's just an issue that comes with hosting the application on the embedded device.

So how do we address all these issues, all these problems I just stated? Well, we can leverage PWAs or progressive web apps. So in theory, it's pretty simple. All you really do is you deploy your web application to a cloud service like you traditionally would. You provide some instructions to your user on how to save the application as a progressive web app onto their respective device, and then it becomes cached on that device. And then they go ahead and they start a connection to your firmware, your edge device, and through the PWA, just establishes a connection and starts to populate the UI or the interface with the data from your edge device. And it's just as simple as that. At the end of the day, by doing this, the edge device becomes really simple because it's just a thin API that serves data as opposed to a full web server that serves a web application. It improves the SCP, the first Contentful Paint, for the application because it's cached on your client's device. There's no resource restrictions because everything's on your client device that has more RAM and more storage. It's easier to update the application UI because you just make your change and you deploy it to your cloud service. And the PWA, you'll set up a Service Worker that will look for updates from that cloud service, that cloud server, and it will pull those latest changes once a regular network connection is established. And lastly, it frees up resources on the edge device, which is amazing because your firmware team will really love it because it'll give them more space for logs or just other critical applications on the firmware, the edge device. So that's PWAs. And I won't go into the details of developing PWA because it really varies depending on the framework that you're using. But I would say most of the, if not all of the large frameworks or popular frameworks that are out there support PWAs with some really simple configuration. Even Vite does, for example, and that's just like a Vite plugin that you then configure.

So on to bundling. So we all know that there's tons of bundlers out there in the ecosystem such as ESBuild or RSPack or Vite, Webpack, Rollup, as well as Rolldown, which very recently came out, and Bunn, among many others. These are just a handful of the ones that I wanted to list on this slide. And picking the correct bundler for your use case really varies. So there isn't a specific bundler that I can make a recommendation for, for developing and deploying React applications to edge devices. But I wanted to point out one thing, that it's really important to pick the correct bundler. So I did a quick comparison between Webpack and Rollup in terms of bundling an application with very similar configuration. And I was able to achieve about a 17% difference between the two. In this case, it was an improvement or decrease in the bundle size when using Rollup. So using the right bundler can make a really, really big difference for you. And that's why I highly encourage you to select the correct one for your use case.

Next is assets. So if your application has assets, which most likely it does, it's really important to pick the correct file format for your assets. So for images, for example, it's really important to use either like a WebP as your image file format over JPEG. And why it's important is because you can achieve about a 25 to 35%, 34% file size optimization just by switching to WebP as your file format. And there's tons of conversion tools out there if you want to use those, or you can use ffmpeg as well to do that conversion. And you'll save a large amount of space in terms of your application size. In addition to images, you can configure your bundler to inline your static assets. Now, obviously there's cons with this, but I think it's really cool and also really important to note is that you can disable inline dynamic imports and force your bundler, in this case this is like a simple beat config, to inline all your static assets. So that way when your page just loads your assets there and there's no round trip network request to your edge device. And again, this has some cons where your bundle size will increase because there's no splitting of your application in different chunks. So just take that with a grain of salt and see if that works for your use case.

Now, Preact. So again, this is React Summit. I'm assuming everyone's heard of React, but what about Preact? Preact is kind of like a cousin of React, if you want to think about it like that. And for those of you who don't know what Preact is real quickly, Preact is a three kilobyte alternative to React. This is straight from their own docs. It's a drop-in replacement for React. And I put that in quotes, you'll understand why in just a moment. And it's standalone.

It's not, it doesn't replace all the React APIs, unfortunately, but there is a way around that. And the way around that is Preact compat, which is a separate library which resolves the compatibility issues with React APIs and makes it support almost all of the React APIs. Now the React APIs it doesn't support. So it doesn't support React server components. It doesn't support the use hook or the use action state hook or the use effect event hook or the activity component. So basically any of the really new APIs or components or hooks that React is shipping, Preact won't ship, unfortunately. But if you're building an application for edge devices, I think you can go without those for the bundle size optimizations that Preact provides you by switching to Preact. And what that looks like here is with React, with React DOM is about 93 kilobytes versus Preact with Preact compat is 9.6 kilobytes. So, you know, there's a drastic decrease in bundle size just by switching to Preact. And you get most of the functionality that you're looking for. There's also tons of libraries out there that do support Preact or have a Preact variant. Even something like React Query has a variant for Preact, which I think is amazing. And, you know, if you're using React Query, it makes it really easy for you to switch over as well. So, again, about a 90% decrease in bundle size. And it still allows you to use a majority of the React libraries and tools that are out there. And if you're building an application for edge devices, then I highly recommend you switching to this as it will free up a lot of space on your edge device.

And lastly is compression. So, you may or may not know, but most bundlers out there will automatically enable Gzip for your compression for your assets, your output from your bundler. And Gzip is an amazing compression algorithm. So, it's like the standard compression algorithm for web applications. It was created in 1992 and supported by all browsers. And it achieves about a 50 to 70% compression for web assets. But you may not know this. There's a different or a newer compression algorithm that's out there and it's called Brotli. And this is their logo. I don't really understand their logo, but this is their logo. So, Brotli was created in 2015 and is supported by all browsers. And most importantly is it achieves about a 20 to 30% better compression than Gzip. And the way it does this is that it has a static dictionary for web applications specifically. That's about 13,000 words in length.

And that's how it's able to achieve this improvement over Gzip. It's because it's built purposely for web applications. And so, you can switch to Brotli and all browsers will understand the Brotli compression file format and it will decompress it on the client side.

So, you can further shrink your bundles just by switching to Brotli. So, those are some real quick tips and tricks on how you can build React applications for Edge devices. Again, it's highly dependent on the configuration of your Edge device and how you're deploying to it. And each team is very different.

But at the end of the day, the bundle size really matters. And that's about it. So, thank you so much. Please do stay in touch. Connect with me on LinkedIn, my website. If you have any questions or want to talk more about developing React applications for Edge devices, send me an email and I'll try to respond as quickly as I can. All right. Thank you. Bye-bye.