Federated Microfrontends at Scale

Spanish audio is available in the player settings
Rate this content

The talk will be a story of how Personio went from rendering through a Monolithical PHP architecture, to a microfrontend oriented Next JS app, powered by Module Federation and the NX monorepo toolchain.

31 min
02 Jun, 2023

Video Summary and Transcription

This Talk discusses the transition from a PHP monolith to a federated micro-frontend setup at Personio. They implemented orchestration and federation using Next.js as a module host and router. The use of federated modules and the integration library allowed for a single runtime while building and deploying independently. The Talk also highlights the importance of early adopters and the challenges of building an internal open source system.

Available in Español

1. Introduction to Micro-Frontends

Short description:

Let's talk about micro-frontends, the federated kind. Personio's frontend architecture has gone through three different moments: PHP monolith, micro-frontends depending on the monolith, and federated micro-frontend setup. The change was needed because the monolith became a mythical beast, and the company grew faster than its architectural concepts. So, Personia switched to micro-frontends, with separate apps in separate repositories, assets stored in AWS S3, and a standalone React application rendered on the user's browsers.

Hey, folks, let's talk about micro-frontends, the federated kind. I was already introduced, but, you know, my name's Daniel. I've been doing frontend stuff for around 10 years and I currently work as a lead engineer at Personio. You can find me there just in case what I say is interesting. And I'm here today to tell you a little story. It's a story about change, it's a story about evolution, but it's mostly about how we are running 60-plus micro-frontends owned by dozens of teams and keeping our sanity while doing it, most of the time.

So, yeah. The story begins, of course, with change and the thing that's changing in this case is Personio's frontend architecture, which in its eight years of existence has gone through three different moments. So, the first one was PHP monolith, very simple stuff, monolith got requests, handled requests, gave stuff to client. Then, Personio's labor of micro-frontends, still very much depending on the monolith for data and as a rendering vehicle, and finally, what we call federated micro-frontend setup which is the main point of today's talk. Don't worry about the size of the graphs, we'll see them bigger later. And let's start first with the, well, before that, when we talk about change, I find that the most important things to say about change is why the change was needed, right? Because that also many times informs why we ended up where we got ended up at. So start with the first moment, how Personia came to existence and why we had to go away from it. Like I said, most people would call this legacy. I call it vintage, because it's appreciated over time, you know, it's a thing that makes money. I don't like the word legacy, it's still loaded. But it's a monolith PHP Laravel application, it does absolutely everything, and the people who built Personia started the project, it got popular, kept adding features on top of it, and we kept adding features on top of it. And you know, you look back a couple of years later, and your project, which started out pretty well, suddenly looks like this. It's a mythical beast, very powerful, but also very janky. And that's what happened to Personia, you know, the company grew faster than its architectural concepts could. In the front-end specifically, it looked like this. We had jQuery coexisting with Laravel and React, and deploying anything took one and a half hours or two hours, if you were lucky, and so something had to change.

So it changed through distribution. Now, if you were around in the front-end scene in 2019, the busiest of buzzwords was micro-front-ends. That's what Personia did. They built micro-front-ends, and our flavor of micro-front-ends looked something like this. We had separate apps in separate repositories under a single framework that was React. At build time, these applications would ship assets to file storage in AWS S3 bucket, and they would also sync their latest build with an internal service called Artifact Service. This thing kept a map of application to assets, kind of like this. Then, when the monolith got a request, it would ask the Artifact Service, hey, what assets should I render here, pass them over to the client, then those would be downloaded, JavaScript would do its thing, and a standalone React application would be rendered and mounted on the user's browsers.

2. Orchestration and Federation

Short description:

So, we transitioned from a monolith to separate microfrontends, which initially solved some issues but created inefficiencies. To address this, we introduced orchestration, which involved rendering through something different than the monolith. We implemented federation, where modules are exposed and consumed by a central controller at runtime, allowing for separate module releases. The frontend orchestrator serves as a lean controller and acts as a router to map URLs to modules.

So, to give you a visual of how this looked, this is Persona's dashboard, and we went from this, the monolith doing absolutely everything, to something like this, where we had two separate applications, two separate microfrontends, they were standalone, they didn't share anything. And this was really good. We solved part of the issues, which was people couldn't work independently, we had a mess, everything mixed together, and deploying was painful. But it was also not so great, you know? Sharing things like state, common dependencies, everything was very hard, it required a lot of coordination, and after a while we decided it was really not worthwhile, the effort, to share the stuff, so every application had everything in it, and it was very inefficient. Also, we were deprecating the monolith, so the rendering vehicle was going to go away, which is probably the main reason why we had to build something different, right?

That is the third moment, which I call orchestration. And this third moment had two objectives. One of them was to render through something different than the monolith, because remember it was going away, and the other one was to keep the good bits while improving on the limitations, so the good bits included the team's independence, and how they could build and release separately. The limitations was what I mentioned before, it was very inefficient, hard to share stuff, and so on. And it looked like this. This is a very not-so-detailed version of it, we'll go into detail in a second. But we have an NX monorepo, and then we have our microfrontends being exposed as federated modules, consumed by an application we call the frontend orchestrator, and that application renders stuff and sends it over to the client.

Let's talk about the first aspect of this, which is federation. In political terms, this thing is about provinces, you know, the most partly independent with a central government. In our world, in JavaScript, it is very similar. You have partially serve-governing or partially stand-alone things that can be consumed by a central controller. So we have two main aspects, right? We have the modules, which are exposed by a system, any system, and anything can be a module. And these are consumed by a host. And also modules can be hosts themselves. Now, if you look at this, you might ask yourself, well, what makes it different from a regular NPM install? You know, I also consume modules when I import a module from NPM, and it's a very small thing, but it is also very big. Which is that the consumption of the modules happens at runtime. So the host doesn't need to know what the module is when it's being built, it only needs to know where it lives. And then it'll fetch it and consume it at runtime. And this allows us to do something that's very powerful, which is separate module releases from a release or a rebuild of the main host. When we're talking about micro frontends and wanting to keep independency, well, this is a must.

Okay, so that's very fun. You know, you have hosts, you have modules. Modules can be hosts, but you still need something central to consume them, which is why we need a central but lean controller. The word lean has a bit of accent on it because, well, we really want the frontend orchestrator, which is how we call our central controller, to be really dumb. You know, we wanted to do two things. One of those two things is it needs to be a router so it can map URLs to modules.

3. Federated Module Host and Router

Short description:

We use Next.js as a federated module host and router, but our setup doesn't rely on any specific Next.js features. To accomplish this, we created standards through Monorepo and NX Monorepo, generating a frontend folder for business logic and an integration library. This library automatically generates a component that can be consumed by any microfrontend in the Monorepo or the frontend orchestrator as a federated module.

And the other one is it needs to be able to consume federated modules, so it needs to be a host. All right? Basically, these two things. It's a federated module host and router. And we use Next.js for that. And the reason why Next is so tiny and in a corner, it's not that Next is not great. Next is great and we love it. But it's because our setup doesn't depend on any specific next features, right? Any framework or in-house build system that can consume federated modules and act as a router would have worked the same way.

So, we have federated modules. We have the thing that's gonna consume them. But remember, we also had existing micro-frontends that now need to become federated modules, need to be exposed so the new thing can consume them, fetch them, render them, do all the good things we wanna do with them. And the way we came up with to accomplish this is through the creation of standards, through some standardization. And this we do through Monorepo, and NX Monorepo, in fact. You might have seen their booth outside. They're pretty cool. Kind of recommend.

And it's all about generating code. Now, whenever a new microfrontend is created or when a microfrontend is being migrated, an existing one is being migrated into the Monorepo, we generate these two things. A frontend folder. Very boring, it's just all of the frontend business logic lives there. We don't care about that, not today. And an integration library. And this is where the fun bits happen. Because this automatically generates a component that can be consumed by any other microfrontend in the Monorepo or by the frontend orchestrator, you know, the main host, as a federated module. This is where it all happens. And it's rather simple. It looks like this. You have some props so that the federated module knows where its remote exposed modules live. Then we expose memwise component that, you know, this federated module component you see there, that's some internal stuff we built and I can't quite show you what it how it looks like, but we can talk about what it does later. It's a bit too much detail for the 20 minutes that I get. But you know, come find me if you're interested in what it does.

4. Integration Library and Single Runtime

Short description:

But short story is it knows where to fetch the federated module and how to render it. Nx is great because making generators is very easy, and adapting them is also very easy. It has saved us a whole bunch of work with just how simple it makes generating code. The Nx affected commands allow people to build inside a monorepo with 60 plus applications and still only run a pipeline for their changes. NX Effective gives us co-located independence, the benefit of being in the same codebase but still independent. The usage of federated modules and all the tooling inside the monorepo allows us to have a single runtime, even though we are building and deploying independently. It lets us share state and code seamlessly with other microfrontends. Thanks to Federated modules and the glue we have, we can load stuff only once. Now, our entry point is much simpler, with everything else moved over to the orchestrator's app component.

But short story is it knows where to fetch the federated module and how to render it. And so, you know, Nx is great because making generators is very easy, and adapting them is also very easy. And it has saved us a whole bunch of work with just how simple it makes generating code. But also because remember, we wanted to keep the independence of teams, the Nx affected commands are awesome for our case.

It is what allows people to build inside a monorepo with 60 plus applications and still only run a pipeline for their changes. So it's kind of like this, you know, with a setup where you have a library A that's consumed by application A and C, but not application B, changes made to the library A will result in a pipeline only for application A and C. So only application A and C will run their tests, will be rebuilt and will be redeployed. So yay for NX Effective. There's also some pipeline trickery in there to make these things dynamic, but that's out of scope.

So, you know, NX Effective gives us what I call co-located independence, gives you the benefit of being in the same codebase, like in the same repository, but still independent that every application is its own thing and works at its own pace and is owned by its own team. Cool, so let's bring these three pieces together and let's look at the initial graph in a little bit more detail. We have the NX monorepo, right, this thing has shared libraries, it has tooling, a lot of tooling, and it has the integration glue that connects Microfrontends to the orchestrator. Then we have the frontend applications themselves, which in turn have their frontend business logic and expose an integration library, which is then consumed by the frontend orchestrator as a federated module and rendered to the client, right? Very simple design-wise, let's look at it. It's very, it doesn't have a lot of pieces, right? But like with most simple things, the devil really is in the details.

So remember the integration library? That seems small, but the usage of federated modules and all the tooling that we have inside the monorepo to make this federated module seamlessly integrate with other microfrontends or with the frontend orchestrator allows us to have a single runtime, even though we are building and deploying independently. And a single runtime, especially when you come from not having a single runtime like we did, you know, every application has its own runtime, is a fun time. It's great. It lets you do two very important things. A single instance of providers that will then share state and share, well, whatever you put into the provider, really, with other microfrontends, and it lets you very seamlessly share code, both for internal libraries and common dependencies, right? Thanks to Ferrited modules and all the glue we have, we can load stuff only once. So, to give you a very crude example, all our design system components, even though they were reused by most microfrontends, before they were loaded every single time a microfrontend was on the screen, sometimes multiple times per page because everyone uses the typography component. Now that is loaded a single time, whenever a page is loaded and then it is shared through module federation with any other microfrontend that requires it.

So, this is what like an entry point looked like. You see all of this boilerplate-y looking things, all of this providers, query client providers, sentry providers, all of this global stuff. It's even missing from the picture a lot of setup like setting up our internationalization library, setting up some request thing we have internally. Now it looks like this. You expose your app, your entry point, and that's it, because everything else moved over to the orchestrator's app component, remember we used Next. This is shared across every single page inside the Next application. That's the beauty of having a single runtime, it lets you do stuff like this. We had two goals, initially, how did we do with this thing we came up with? Let's compare. I moved backwards.

5. Non-Technical Lessons and Use Case

Short description:

No, I didn't. This was just to remember the goals. Render to something different than the monolith, and improve the limitations while keeping the good bits. Teams still build and deploy independently of one another many times per day, and without conflicts. The new frontend orchestrator is a lean router and module host. We can now share dependencies and common code easily in a single runtime. It wasn't an initial goal, but the pages served through the frontend orchestrator have seen a 30% improvement in web vitals. When designing and building a project like this, have a real use case in mind immediately to avoid potential issues.

No, I didn't. This was just to remember the goals. Render to something different than the monolith, and improve the limitations while keeping the good bits.

We had monolith and micro front-ends on the left, and on the right. First one is team independence. Are teams still as independent as they were when the applications lived in separate repositories? The answer is yes. Thanks to Nx and some of what we did with our pipelines to make them dynamic, teams still build and deploy independently of one another many times per day, and without conflicts.

Do we have a central controller? Yes, we do. In both cases, there is no difference there. But is it lean? Is it fast? Does it do not a lot of things? In the case of the monolith, it did absolutely everything. It held the data, it rendered, it fetched stuff. It did everything. In the new frontend orchestrator, it does nothing. It's a router that's also a module host and that's it.

Can we share dependencies and common code easily? Now we can. Because we are in a single runtime. This one, we didn't really set out to improve this, but we've noticed that the pages that are now being served through the frontend orchestrator have seen a 30% improvement in their web vitals. Which when you think about it, since they don't have to remount everything, it makes sense because we're sharing dependencies as well. Like I said, it wasn't an initial goal, but you'd love to see it.

Now, for some non-technical lessons learned of being in the team that both designed and built this project. You should really have a real use case. If you're doing something like this, have a real use case in mind immediately. I mean, we had a real use case, but have built with the idea that you'll be pushing something to production as fast as possible. Like, choose a page that's not very visited and just put it out there. It might not work great, doesn't matter. Put it out there. We didn't have that. We ended up trying it out for the first time in production with the dashboard, the most visited page. And Personium, some might say it was brave, but it was also reckless, and also cost us a lot of headaches. So, you know, don't do it.

6. Challenges with Internal Open Source System

Short description:

The hardest part of building new software systems is people, and I'm not talking about individuals, right? I'm talking about organizations. We wanted this new system to work like an internal open source system, but it didn't work. We had no critical infrastructure system that supported this approach. So, we now have a team that owns the system, and it works better.

Push to production as fast as possible in a small place. The hardest part of building new software systems is people, and I'm not talking about individuals, right? I'm talking about organizations, so something that I didn't mention before is that we wanted this two new pieces to work kind of like as an internal open source system, you know? Like, we would be the group of maintainers. People would collaborate. We would, you know, contribute, collaborate with them. It would be great, you know? It would be glorious. That didn't work. We had no critical infrastructure system that worked like this, and it turns out that the reverse con way where you first build a system and then expect your company's organizational structures to adapt to the existing system, doesn't work. So, you know, this might sound great, but now we have a team that owns the things, and there's crystal clear ideas of who you need to contact if something breaks or who is in charge of developing it, and it works better, you know? Organization Personia wasn't ready for an idea like this, and we wasted a lot of time trying to make it work.

7. Importance of Early Adopters and Conclusion

Short description:

Early adopters are crucial for building something new. They provide valuable feedback and insights. If you're in a similar position, consider the architectural pattern of federated microfrontends. Shout out to the original team and thank you for attending the talk.

And finally, when you're building something new, your early adopters are the best adopters. They'll love you, they'll hate you, but most importantly, they'll let you know what works and what definitely doesn't, right? So find early adopters and treasure them. They're the best.

Now, some of you might be in similar positions, and might be thinking, eh, that sounds interesting, maybe I should try that. You know, the answer's always, it's pretty simple, it's a maybe, you know, it depends. Our situation was rather special. We had multiple teams that needed to release on demand, and they needed to make this releases available to clients immediately. We already had experience with microfrontends, so we knew how to run a federated, no not federated, distributed frontend system. We were deprecating our existing delivery mechanism, so we were forced to build something new. And we had some in-house experience building a similar system. I believe in what we built, but if some of those things weren't there, we might have fixed it in place, instead of building something different. If your position looks anything like ours, it doesn't have to look exactly like ours, but anything like ours, then maybe considering this idea, this architectural pattern of federated microfrontends might be worth looking into for you.

That's the end of the story, but before we go to the Q&A, I want to give a shout out to the faces on this slide. They were the original team that worked with me on this. Very cool people. Yeah, just wanted to put their faces out there. And thank you for coming. Thank you for listening. Great talk. Thank you so much.


Alternative to NX and TurboRepo

Short description:

We could use an alternative. What we need from NX is generating code easily and affected command. I haven't really looked into TurboRepo, but if TurboRepo can do something like this that will allow monorepo applications to still feel independent and work independently, then it would also work.

We have a lot of questions. We will not be able to get to all the questions, so if you have specific questions that you see in Sli.do, please do upvote them, and we can get to those first. All right. So, first question. Does your setup rely on NX-specific functionality, or could you use an alternative like TurboRepo? We could use an alternative. What we need from NX is generating code easily and affected command, you know. I haven't really looked into TurboRepo, but if TurboRepo can do something like this that will allow monorepo applications to still feel independent and work independently, then it would also work. Great, yeah. I haven't tried it either, so it's, you know, go try.

Versioning and Technological Diversity

Short description:

Our strategy for versioning MicroFrontEnds is to have a single root package JSON, ensuring a single version of dependencies across the monorepo. We have strict versioning in our federated modules to ensure everyone gets the same version. We serve a single remote entry file without hashing, but we are introducing a hash for the version. Although we use React for homogeneity, teams can make decisions on specific libraries and frameworks. Currently, we don't support server-side rendering with Federated Modules, but it may evolve in the future.

What about versioning your MicroFrontEnd? What if common modules differ in between those versions? How would you handle this in your final host application? Right. Right now, our strategy to solve that is to not allow it. So that's another bit that NX does for you. It has a single root package JSON. So you only have a single version of dependencies across the whole monorepo. It makes updating sometimes painful, but it solves some of the issues in this case.

Another thing that we have is that we have strict versioning in our federated modules, which means that when a dependency comes in and it's served to a MicroFrontEnd as a federated module, we know that everyone will get the same version. For our own internal versioning things, we, at the moment, don't really have that. New releases are always the latest release. We serve a single remote entry file without hashing, but we are introducing a hash for the version. Remember the artefact service that I mentioned? We have a new version of that, that will keep the reference to which one is the latest entry file, and we'll serve that to the orchestrator when it's requested.

Yeah, that makes sense. I'll kind of highlight one question that was asked here that wasn't at the top, which is, you have a monorepo, and that allows you to make single point decisions, like you just mentioned, pinning versions. But do you have any technological diversity in the stack? Are people using maybe different libraries, frameworks, architectural patterns, or is it somewhat homogenous? Not quite homogenous, but it is close. We only use React. That's already a huge advantage, because that lets us simplify the tooling that creates authoritative modules, we just had to deal with one framework. And we provide some things out of the box that are what we expect people to use, like React Query, for example. That is our state server management mechanism. But still, teams can make decisions on specifics of what they use. So, for example, if a microfrontend really needs some state management for it, apart from server state, they can bring in Redux or Jotai or whatever they want. So, it is homogenous on the big pieces, not so much on the smaller ones.

Nice. So, there's a question here that's been upvoted tons. We tried the same solution, but we got stuck at SSR. How are you guys working with SSR and Federated Modules? Yeah, that's a good one. We're not. We don't have the need to do that right now. And I know that is an important point. Federated Modules are not really well set up yet for server-side rendering, or at least they weren't the last time we checked. Things might have evolved in the meantime, and they will definitely evolve eventually to support for that.

Handling Real-time Data and Module Federation

Short description:

Our application relies on real-time HR data, so we don't SSR much. We use a shared cache to deduplicate requests and improve async efficiency. Roll-out breaking changes in federated modules are handled with a tool that allows easy rollbacks. We implemented our own module federation solution, which is similar to existing ones. We require 100% code coverage for shared libraries to minimize issues caused by one team's changes affecting another.

Our application depends very much on data being up-to-date in real time, because it's HR data. It's very important that things are up-to-date. So we don't really SSR things a lot. Yeah. I actually noticed that you're using React Query, is that correct? Yes. Or something like that. So you have probably a shared cache, so is that how you sort of deduplicate requests, make sure that every package doesn't actually data-fetch unnecessarily? Yeah, exactly. And that's the layer that allows us to be more efficient with our async requests.

Yeah, that's really cool. So here's the question that we kind of already touched on, but I think it needs a little bit more explaining. How do you deal with roll-out breaking changes in the federated modules, which all need independent deployments? Right. Yeah. We have, like I said, this tool that we are rolling out now, that's the new version of the Artifact Service, makes it very simple to roll back. It has an interface that we can use to say, hey, this one broke, mark it as unstable and return the last one. So it's solved with tooling, basically.

Well this leads to our next question. Did you use any existing module federation library or did you implement your own? And if you did your own, what do you think of some of the off-the-shelf solutions out there? Right. I think one of my teammates, colleagues, would be the best one to answer this question. But if I remember correctly, and Rob, sorry if I'm wrong, we ended up rolling our own, but it looks very similar to something existing. It was more like we tweaked little bits of it to adapt to our specific use case, considering a fork of what was out there for the next federated modules plugin, I believe. And what do I consider? I mean, they're all great. If you can use them, use them. It doesn't make sense to roll your own for something that's been already solved. We just didn't quite work for what we wanted.

Nice. How do you handle when one team breaks the stuff of another team through a shared library? Is there some kind of shaming ritual to put them in a corner, make them wear a funny hat, point at them? No, but I wish we had. No, I mean, we are very strict in the libraries themselves. Libraries that are shared with different microfrontends, they require 100% code coverage. I'm not saying that makes it safer. But it usually at least makes people think more about their changes.

Code Review, Type Safety, and Data Sharing

Short description:

Teams review code using a detailed code owners file and require approval from all consuming teams before pushing to production. TypeScript and the integration library ensure type safety and code completions in VS Code. Common contexts between microfrontends are shared through data libraries that use React Query. The monorepo itself provides information on available data and cache access.

And they need to be reviewed also by the team that's using it. Because we use a very detailed code owners file. And then while building the merge requests that will push that to production, it needs it requires an approval from every team that consumes it. So that's how we've covered ourselves from that scenario. Not to say it doesn't happen, right? But when it happens, we jump on it as a team as well. As a group of people from different sites to resolve it. No shaming.

Yeah, that makes sense. Actually, I'll highlight one other question from here, which I can't find right now. But it was about... So I'm assuming you also use some type script so you get type safety throughout the packages But how about things like code completions and the command-click thing inside VS Code, for example? Do those work when you're federating at runtime?

They do, yeah, because we have this integration package that I showed you, the integration library. That is consumed as it would any other regular import, right? The thing that it does at runtime is inside of it. Every application, every microfrontend is developed individually. It all has type-safety. It's all in TypeScript. It's type-safe. And it gets consumed by the frontend orchestrator that's also type-safe, and the async side that might break happens under the hood, and no one really touches it. So that's how we cover ourselves from that. Nice.

We have time for one more question. Kind of touched on this already, but I think this is something worth exploring a little further. How do you share common contexts between microfrontends? So I'm supposing this is runtime context, so things like data. You mentioned React Query. But could you say a few more words about how is that whole thing orchestrated? How do teams who are building one particular functionality, how do they know what data is available? What is going to be primed in the cache? Does it matter, etc., etc.?

Yeah, it does matter, and that is one point that we haven't fully solved. We have an idea, and it works already. We have what we call data libraries. So teams provide common data libraries that use, under the hood, they use React Query. They expose hooks so we can share the same query keys, and therefore access the same cache when different teams use it. But because we're migrating existing microfrontends that are standalone, they are not yet quite all there. But when they get there, we will not have the problem of knowing what's available because inside the monorepo itself, it will tell you what you can fetch safely by accessing a cache if it exists. Nice, that's really cool, actually. Awesome.

One final question for me. What is your favorite Serif typeface? Meriwether. Nice. Well, thank you so much, and I'll let you go. Good job on the talk. Thank you.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Remix Conf Europe 2022Remix Conf Europe 2022
23 min
Scaling Up with Remix and Micro Frontends
Top Content
Do you have a large product built by many teams? Are you struggling to release often? Did your frontend turn into a massive unmaintainable monolith? If, like me, you’ve answered yes to any of those questions, this talk is for you! I’ll show you exactly how you can build a micro frontend architecture with Remix to solve those challenges.
Remix Conf Europe 2022Remix Conf Europe 2022
37 min
Full Stack Components
Top Content
Remix is a web framework that gives you the simple mental model of a Multi-Page App (MPA) but the power and capabilities of a Single-Page App (SPA). One of the big challenges of SPAs is network management resulting in a great deal of indirection and buggy code. This is especially noticeable in application state which Remix completely eliminates, but it's also an issue in individual components that communicate with a single-purpose backend endpoint (like a combobox search for example).
In this talk, Kent will demonstrate how Remix enables you to build complex UI components that are connected to a backend in the simplest and most powerful way you've ever seen. Leaving you time to chill with your family or whatever else you do for fun.
React Advanced Conference 2022React Advanced Conference 2022
29 min
Understanding React’s Fiber Architecture
Top Content
We've heard a lot about React's Fiber Architecture, but it feels like few of us understand it in depth (or have the time to). In this talk, Tejas will go over his best attempt at understanding Fiber (reviewed by other experts), and present it in an 'explain-like-I'm-five years old' way.
TechLead Conference 2023TechLead Conference 2023
35 min
A Framework for Managing Technical Debt
Let’s face it: technical debt is inevitable and rewriting your code every 6 months is not an option. Refactoring is a complex topic that doesn't have a one-size-fits-all solution. Frontend applications are particularly sensitive because of frequent requirements and user flows changes. New abstractions, updated patterns and cleaning up those old functions - it all sounds great on paper, but it often fails in practice: todos accumulate, tickets end up rotting in the backlog and legacy code crops up in every corner of your codebase. So a process of continuous refactoring is the only weapon you have against tech debt.In the past three years, I’ve been exploring different strategies and processes for refactoring code. In this talk I will describe the key components of a framework for tackling refactoring and I will share some of the learnings accumulated along the way. Hopefully, this will help you in your quest of improving the code quality of your codebases.

React Summit 2023React Summit 2023
24 min
Debugging JS
As developers, we spend much of our time debugging apps - often code we didn't even write. Sadly, few developers have ever been taught how to approach debugging - it's something most of us learn through painful experience.  The good news is you _can_ learn how to debug effectively, and there's several key techniques and tools you can use for debugging JS and React apps.

Workshops on related topic

DevOps.js Conf 2024DevOps.js Conf 2024
163 min
AI on Demand: Serverless AI
Featured WorkshopFree
In this workshop, we discuss the merits of serverless architecture and how it can be applied to the AI space. We'll explore options around building serverless RAG applications for a more lambda-esque approach to AI. Next, we'll get hands on and build a sample CRUD app that allows you to store information and query it using an LLM with Workers AI, Vectorize, D1, and Cloudflare Workers.
React Summit 2023React Summit 2023
145 min
React at Scale with Nx
Featured WorkshopFree
We're going to be using Nx and some its plugins to accelerate the development of this app.
Some of the things you'll learn:- Generating a pristine Nx workspace- Generating frontend React apps and backend APIs inside your workspace, with pre-configured proxies- Creating shared libs for re-using code- Generating new routed components with all the routes pre-configured by Nx and ready to go- How to organize code in a monorepo- Easily move libs around your folder structure- Creating Storybook stories and e2e Cypress tests for your components
Table of contents: - Lab 1 - Generate an empty workspace- Lab 2 - Generate a React app- Lab 3 - Executors- Lab 3.1 - Migrations- Lab 4 - Generate a component lib- Lab 5 - Generate a utility lib- Lab 6 - Generate a route lib- Lab 7 - Add an Express API- Lab 8 - Displaying a full game in the routed game-detail component- Lab 9 - Generate a type lib that the API and frontend can share- Lab 10 - Generate Storybook stories for the shared ui component- Lab 11 - E2E test the shared component
Node Congress 2023Node Congress 2023
160 min
Node Monorepos with Nx
Multiple apis and multiple teams all in the same repository can cause a lot of headaches, but Nx has you covered. Learn to share code, maintain configuration files and coordinate changes in a monorepo that can scale as large as your organisation does. Nx allows you to bring structure to a repository with hundreds of contributors and eliminates the CI slowdowns that typically occur as the codebase grows.
Table of contents:- Lab 1 - Generate an empty workspace- Lab 2 - Generate a node api- Lab 3 - Executors- Lab 4 - Migrations- Lab 5 - Generate an auth library- Lab 6 - Generate a database library- Lab 7 - Add a node cli- Lab 8 - Module boundaries- Lab 9 - Plugins and Generators - Intro- Lab 10 - Plugins and Generators - Modifying files- Lab 11 - Setting up CI- Lab 12 - Distributed caching
React Summit Remote Edition 2021React Summit Remote Edition 2021
87 min
Building a Shopify App with React & Node
Top Content
Shopify merchants have a diverse set of needs, and developers have a unique opportunity to meet those needs building apps. Building an app can be tough work but Shopify has created a set of tools and resources to help you build out a seamless app experience as quickly as possible. Get hands on experience building an embedded Shopify app using the Shopify App CLI, Polaris and Shopify App Bridge.We’ll show you how to create an app that accesses information from a development store and can run in your local environment.
JSNation Live 2021JSNation Live 2021
113 min
Micro Frontends with Module Federation and React
Did you ever work in a monolithic Next.js app? I did and scaling a large React app so that many teams can work simultaneously is not easy. With micro frontends you can break up a frontend monolith into smaller pieces so that each team can build and deploy independently. In this workshop you'll learn how to build large React apps that scale using micro frontends.
JSNation 2022JSNation 2022
41 min
Build a chat room with Appwrite and React
API's/Backends are difficult and we need websockets. You will be using VS Code as your editor, Parcel.js, Chakra-ui, React, React Icons, and Appwrite. By the end of this workshop, you will have the knowledge to build a real-time app using Appwrite and zero API development. Follow along and you'll have an awesome chat app to show off!