Building Cross-Platform Federated Modules With React, React Native and Re.Pack

Thank you so much and hello everybody! This is the first time I'm speaking in this silent disco setup so it kind of feels interesting. And I got a bunch of announcements to make but we'll see if we have enough time during the Q&A. Alright, so today, as you can see, the topic is building cross-platform super apps with React, React Native, and Reapack. So before we start, a couple of words about me. That's a more accurate photo of myself because the purple one you've seen was like six months ago. I'm CDO and founder at ColdStack. I've been doing React Native for 10 years now. You can find me under Grubhub on pretty much everywhere. And I just put up this screenshot because I realized when I was making it, it's been over 10 years and it's pretty interesting that when it comes to writing React Native code, when I was writing this, I was wondering when this code will become legacy. And I just realized that I can remember the code I wrote is already legacy which is a pretty interesting realization like time flies so fast.

Anyway, today I want to talk to you about micro-frontends. You may have heard a term super apps but I want to talk about micro-frontends which is how you can leverage module federation to build truly cross-platform applications, in fact, turn them into platforms with third-party code included if that's your use case as well. And the topic was originally about super apps, but I just find micro-frontends more useful, more general purpose, a broader term that doesn't necessarily apply to super apps only. So let's have a look at what we have in the agenda today. First, I will do a little bit of an intro to Repack and React Native. So maybe just to get better understanding of the audience, how many of you are React Native developers? Okay, and so those of you who didn't raise your hand, I'm assuming you're React developers. Okay, I see some hands moving, that's fine, all right. So I'll try to make this introduction smooth and then we'll talk about Repack, what it is, high-level overview, and then we'll talk a bit about module federation and then obviously benefits and things that we didn't talk about during those 30 minutes. So let's go, let's start.

So traditionally, when it comes to dynamic content, we typically had limited options on the mobile. WebViews were the quick solution, right? Essentially embedding a browser in your application and this is great when you want to ship a lot of dynamic content without affecting your overall application size, but also this comes with a degraded user experience and obviously performance issues. Companies like Shopify, this is taken from their article, use WebViews in over hundreds of places, very important but not mission critical. Like the screens you can see on the slides, very dynamic, and they also spend a lot of engineering resources to make sure those issues do not affect the UX. Like here, they share on Twitter how they fix performance issues, how they made WebViews up to six times faster, and we could do all that or we could use module federation and this is exactly what are we going to talk about today. So what is module federation? To better understand that, let's go back in time and talk a bit about bundle splitting. I'm sure you've heard about this before. Bundle splitting is kind of a de facto standard these days. The idea is very simple. We split our code into chunks and we load them on demand as needed, and back then, this was quite revolutionary. Suddenly you didn't have to ship a single bundle, you could split your bundle into multiple chunks, and then whenever you would make a change, you would only update, say, the client chunk or maybe the vendor chunk.

And by the way, you guys cannot see this, but it's like half of you is trying to get a bit of fresh air. It's pretty interesting. I'm trying not to get distracted by that, but it's really interesting because it's all kind of flowing, synchronized, and this view behind is a bit intimidating as well. It's pretty interesting. Anyway, all right.

So that helped with caching and versioning because suddenly, like I said, you could split it all up. And then module federation, what it really does is it takes this one step further. Instead of splitting one application into chunks, you can suddenly have multiple independent applications work together. As in this case, host application, as long as it includes a module federation runtime, it can start including multiple smaller remote applications that you can add during the application lifecycle. You can update them, or you can even remove them. And the key difference from code splitting is that federated modules, or those remote applications, are totally separate from the host application.

Today, module federation, as we already know, evolved from bundle splitting and is now sort of starting to become a bundler-agnostic concept. In 2024, it became a whole specification, and there are bundlers outside of Webpack ecosystem that are starting to support it, including RSPack and Roldown as well. So now the question is, can we bring it to React Native? After all, React Native runs JavaScript. It has a module system, so theoretically, everything should be possible, right? The answer is, of course, yes, otherwise I wouldn't be standing here. And the answer to that is a Repack, which is an alternative bundler for React Native.

It has a module system, so theoretically, everything should be possible, right? The answer is, of course, yes, otherwise I wouldn't be standing here. And the answer to that is a Repack, which is an alternative bundler for React Native. You can think of it as a tiny compatibility layer on top of Webpack. Compatibility, yes. There you go. On top of Webpack or RSPack in this case, bringing what's already there to the mobile world.

And why we created Repack in the first place? Well, first of all, it's good to have options. Alternative bundlers provide more diversity and challenge us to ship faster and come up with more ideas as a collective. And Repack uses RSPack under the hood. And there are other projects where you can use Vite, for example, to build React Native apps as well. Second, we see huge value in being able to share infrastructure. When you start sharing code across React, React Native, you have suddenly five plus platforms. And it's quite useful to share same concepts, plugins, and transformations that you're dealing in different places. And of course, it has support for module federation out of the box.

So because we have it, we can just start using it. So you may be thinking, where is the catch? React Native, unlike other frameworks, has been working exclusively with Metro. And there must be a reason for that. What do we lose if we opt in for Repack? Where is the catch? Are we going to lose performance? Is it a drop in replacement? Or is there a vendor lock-in, perhaps? So on a high level, I wanted to break down the concept of bundling in React Native world to show you how Metro Bundler takes multiple source files and creates this bundle, IIFE bundle, which immediately invokes function expression.

What's inside the bundle is obviously React Native polyfills, so everything needed to make React Native code run. The Metro runtime, which is the __d, __r, and __hmr, so everything for module declaration and requires, as well as __hmr. And obviously the application code right there. And so, in theory, you can build React Native application with any bundler of your choice, as long as you provide a compatible runtime that satisfies the requirements of React Native that it expects from the bundle. And that's what Repack really does in this case. And of course, Repack is only as good as the underlying bundler.

For many years, we were playing the catch-up game with Metro, which was obviously highly optimized for React Native. So every time we would have this discussion, hey, you should use module federation, somebody would be concerned about performance or, you know, the list of challenges was quite impressive and long. Thankfully, with the release of Repack V5 a couple of months back, the gap has been dramatically closed. We were able to migrate from RSPack, which is RAS-based webpack-compatible bundler. And as you can see, we were able to get it down from 7 seconds to 1.75, which is around a five-times improvement.

Now we have all pieces in one place. We have high-performance module federation, __hmr, which means great developer experience. And we can obviously change the bundlers without locking. It is a pluggable layer that, theoretically, you can swap without. Let's explore how we can leverage this architecture to build cross-platform micro-frontends and what that really is in practice. Here is a little overview of a federated application architecture. This is sort of platform agnostic, same applies for web and mobile. If you have worked with module federation before, this is perhaps very, very familiar to you.

If you have worked with module federation before, this is perhaps very, very familiar to you. And I just see the timer started right now. Suddenly, eight minutes. I'm sure it's probably wrong. Whatever. Anyway, in this scenario, there are three teams shipping three apps in parallel. Different set of features, different set of requirements. What happens later is all these three separate applications get combined together with a container. And that is what constitutes typically a website in this case.

If we take a look at a typical mobile application, in this case Uber, we could imagine Rides and Eats being those federated modules. Typically, it's a standalone application, but then at some point, they would come together to form the Uber app. And if you remember, or if you were lucky enough, some geolocations had Uber Eats as a separate standalone application. So that really sort of proves that they must have had similar architecture under the hood to seamlessly switch across those separate and embedded experiences. So if we try to break this down into more technical perspective, we can think of each module as a separate, standalone React native application with React Navigations Navigator at the top. It's just standalone, so we can obviously turn it on, you can run it, you can display the default navigator.

However, when you present it as a route by another module, it starts acting as a nested navigator. So in practice, here is a sort of hypothetical implementation of each. As you can see, each federated module exports an entry point, which is a React native component to render. That can be anything, in our case, like I just showed you before, is going to be a navigator. And here on the slide, we have some nested screens that, theoretically, Uber application might be using, like restaurant list or restaurant details. Then to load those modules from within the host, all we have to do is just import them. Dynamic import is processed by repack and module federation plugin and replaced with an actual location of the module. And available modules, together with their location, can be obviously configured in the configuration.

And before I show it to you, it is worth noting that this configuration is pretty flexible and depends on your config and requirements. In this case, since repack uses RSPack under the hood, we're really not configuring repack. We're configuring RSPack with repack provided plugins to make it work with React Native to satisfy the requirements. It has few options, but the one that we want to really talk about today is remotes. That's where we have defined our modules. So as you can see, we have eats and rides, and these two come from CDN. They were already created, deployed independently, by separate teams. We don't really care where they come from.

However, we have one additional module that we're working on together with us, in parallel with the host application, rental. And we are loading this one from source, which means there is a RSPack server running somewhere on our machine. And you may be thinking, how do we even get those chunks to the CDN? And the good news for me is that this is out of scope for repack, but the bad news for you is that you need to implement some sort of infrastructure to get it working. And thankfully, there is an off-the-shelf provider called Zephyr Cloud that kind of does just that and a few more features. What it does is it actually takes care of all the versioning, hashing, and security.

So you can just push it like to NPM and forget about everything else. And it works with React and React Native, which is, I think, great. So like I said, that's how you sort of get it configured. That's where the eats and rides come from. Back to the modules. Each module exports a top-level React Navigations Navigator, so we import the navigators. And because Module Federation seamlessly integrates with React features for lazy loading, we can just wrap it with suspense, provide some fallbacks, and boom, we have a loading state for each of the screens. We can tweak it later, but in principle, it is that easy to provide that state.

Final step really depends on your setup, but since we are using React Navigation, we're just dropping each of those top-level navigators from federated modules as screens within the host application. So whenever we want to display one of those federated modules, we can just push the relevant module and it will be downloaded, loaded, and displayed. If you're interested to play around with this setup, you can scan the QR code. On our GitHub, we have exactly that setup up and running, so you can clone it, you can install dApps, and you're ready to go.

So far, we've been mostly talking about regular flow, but what's interesting is the flow for third-party developers, or maybe if you are a really large organization and you have so many teams that when you meet them in the kitchen, you're like, I haven't seen you before. In that case, this is also going to apply to you. Let's imagine we're really building an Uber application, and a very typical use case is that we're going to include rentals. But we're not going to provide the rentals, right? We will talk with one of those rental companies like Hertz, they will provide rentals from their API. Typically, what we do is we will talk with the third-party developer, we will ask Hertz about their API docs, about everything they have, and then we will go and implement everything. We will do error handling, we will do state management, we'll do UI integration, all sorts of things that are required, and then at the very end, we will make the actual integration which will be tightly coupled with our application.

But what if there was a different way to do this? Well, let's imagine a scenario where we do not implement it, but somebody else implements it for us, which is obviously the best case. So we provide an SDK that includes dev tools, API docs, standards, and everything that is provided by our environment, and then external developers implement actual features following our UI requirements, our standards, our security, our tooling, everything. What they have to create at the end of the day is just this mini application that is working standalone, meets requirements of their business, their business requirements, our requirements, it's standalone. It's a different departure, it's a significant departure from the previous approach because it is not coupled to our application. And what happens later is when they're ready, they're sending over to us through whatever is the system we've established, and that becomes part of our application automatically. And the good news is that this is exactly what Module Federation is about, and you can build it today in React Native with Reapak. So let's have a quick look how we can quickly implement things like SDK. This is based on the principle that React Context works across the boundaries of host and mini application. So on a high level first, we create an SDK package that we expose to external developers. SDK package is something like an interface declaration of what is provided in your environment, and one of the simplest ways to do this is to create React Context. Then the host application uses the context provider to inject the actual values, so a classical dependency injection. And then the mini app uses hooks or consumes the context, getting whatever is provided by the host at a given time as the actual value. So let's go over this step by step, looking at Payments Module for example. So like I said first, we create context. Elegant and simple abstraction, easy to get started. We can provide some error handling, just in case it is misconfigured, and potentially a hook so it's easier for people to work with it. Then we can create a SDK runtime provider, typically what I do myself is I create one and I just encapsulate everything inside so it's easier for me to follow. And this is the component that must be provided by the host to run all the mini apps. So it's kind of like a system environment if you want to run my mini app, you need to provide exactly this. And then host has to provide actual values for each property required by the SDK runtime provider, otherwise it is not going to be seen by the federated module.

So as you can see, the federated module, like it's navigator for example, is rendered inside the SDK runtime provider. And inside the federated module, very simple, we read the context value and we do whatever we want with that API. The benefits, quite a few. First of all, this architecture allows you to do fine-grained access control very easily. For example, you can scope and pass all calls through the SDK. You can decide whether certain APIs are available or not. Require prior user approval. In this case, for example, it's a very simple concept where you can just require permission to be present before continuing. And I'm sort of faking the actual iOS alert but can be anything really.

The architecture here is not prescriptive. You can decide how you want it to behave, how you want it to be, but it's a pretty universal concept. You can also provide easy sandbox for your testers or external developers. Host application, after all, is nothing but a React Native application that provides actual values for the SDK runtime provider. So we can create as many as you want and provide as many different values for those contexts, different contexts as you want. That way, you can create a production one, you can create development one, and maybe one for third parties that has mocked versions. Something very simple.

And another interesting idea is cross-platform user interface, which makes your federated module truly platform-agnostic. You can provide UI components like view text and button, and you can decide what kind of UI is rendered inside each of those federated modules. This can be components, can be styling, anything really, kind of depends on how you think about cross-platform UI. But this code will execute everywhere. So if you use federated modules across React Native and React, this code will pretty much run everywhere. The use cases that are not covered, all you will have to do on your own. It's not just that amazing, there are obviously a few things you have to do on your own.

The first one is the development portal. So if this talk is resonating with you, some of you are probably asking yourselves questions about how do we accept those external modules, do we use GitHub for that, do we host a solution with UI like Apple-style development portal? And the answer is, it depends obviously. I just want to show you, and a little warning, this will be a white slide. This is a very complex diagram that shows the decision-making process and all the steps that happen when reviewing a mini-app by a company called Momo from Vietnam. It's a local super app that is using React Native. They use this concept to integrate with third parties. They have a whole development portal for that with guides and submission process. So it's not prescriptive, typically those companies don't rather share their code with the community. And finally, we have the challenges related to JavaScript itself around third-party code. We hear this question quite a lot from companies. You know, the challenge is that when you start loading those different federated modules into a single shared JavaScript context, it is very likely that one of the chunks will have some malicious code and it is possible to reverse engineer or break your application, which is not desired.

In this case, I have this very simple example where we are tweaking prototype, honestly, and as you can see when you console log it, a different output will be provided, not an actual username. So this is just an example, but a more real-world example I can tell you is one of the companies that we've been prototyping this with and we shipped this concept has a hardware device that collects sensitive data, but they also allow smaller mini-apps to run together there. And the concern is how do we make sure none of the mini-apps can interfere with the sensitive data and that is healthcare. So as you can imagine, the concerns are really, really high. You can mitigate this by doing a lot of things, but one of the popular, easiest, and probably strongest approaches is to separate a couple of federated modules to different React Native environments, so you would have multiple Hermes Engine instances that would be executing React Native code separately from each other and you would control how they communicate with themselves. So for that, you can utilize a postMessage-like API, for example, which is how we often communicate.

Wrapping things up, some of the key takeaways from this talk. First of all, you don't need... Super apps are not webviews. We don't need to embed whole browsers in our mobile apps anymore to build super applications with React Native. Thanks to Module Federation, we can now start adapting React Native for super apps and thanks to JavaScript environment, we can unlock certain patterns that are very hard to do natively like dynamic code loading and stuff like that. And it's not just limited to super apps, it can actually make your codebase more modular, you can enable you to ship faster, you can sort of decouple your teams. If your teams are highly independent, this is often a interesting extension to your codebase. You can bring in third-party features with runtime SDK at any time, as you've seen it is fairly easy to adapt this SDK approach and suddenly your application becomes a platform and is a cross-platform application by default, running on both mobile web and possibly other platforms. And if you're thinking that this is something that takes a long time, typically that approach can be tested in production in a week.

And it's not just limited to super apps, it can actually make your codebase more modular, you can enable you to ship faster, you can sort of decouple your teams. If your teams are highly independent, this is often an interesting extension to your codebase. You can bring in third-party features with runtime SDK at any time, as you've seen it is fairly easy to adapt this SDK approach and suddenly your application becomes a platform and is a cross-platform application by default, running on both mobile web and possibly other platforms. And if you're thinking that this is something that takes a long time, typically that approach can be tested in production in a week. So if you are thinking about this approach, I'm happy to do a demo for you or you can just scan this QR code. For us, as creators of Repack and proponents of alternative bundlers in React Native, the more companies start using that, the better. And I think with Module Federation we can really make our applications faster and just ship faster with more interesting features. That's it, thank you.

Yes, so first of all before we get to the maybe one or two questions we have, congrats on over 10 years of working on this. I don't want to feel that old. I mean at least we're just the same as React Summit is. It's quite changed since the first conference. Let's find out. Okay, so I think we have time for maybe one or two questions. So don't forget the questions in the Slido. You can also upvote them. Do you want to let the speakers know which questions I need to ask them? Who had that many seconds? That's me. Okay, all right. I think we have quite a few questions around the kind of performance implications and dealing with overhead. So for example, is there a way to or sort of what's your approach of dealing with the trade-off of all of these different things to download? How do you kind of structure things so that you're not obstructing the user experience? Yeah, you have to be smart about how you split those things. A great example I can provide here is my favorite use case is because I like cars, one of the customers is a car application. So typically when you open, let's say, a BMW application, and I'm gonna use this example because it's in Flutter, so it's 100% of this application. But when you open it up, you see a loading screen, you see some common features. So these ones you typically preload with the application. So if you remember the config, some of the modules can come from remote, but some of the modules can be bundled in together, so you don't have to ship them to the remote. But then when you log in, when you configure or download some data from the API, this is the moment where you can start fetching those modules without obstructing user experience. For example, b...