Building Resilient UIs with React

[00:01:02]Okay. So, hey everyone, asalam alaikum.

[00:01:05]Welcome to today's session. As you know, I'm your host Mahhamtaher. I'm working as a content strategy and community manager at Code with Essen. As you all know, Code with Essen is an online hub that currently consists of 5,000 plus members who are developers and tech professionals. Here at Code with Essen, we aim to provide a free online platform for anyone who needs guidance in his career, wants to grow, wants to collaborate in open source projects and connect with our senior mentors. We also organize tech events, non- tech events, career growth sessions, hackathons, workshops, boot camps and so on. So today we are hosting a tech event that is about building resolent UIs with React. For this event I would like to welcome our amazing speaker Faris Aiz who is a staff front-end engineer specializing in React, NextJS monetization systems and resilient web architecture. His work spans green field builds and legacy refactors across fintech, SAS, fitness and connected TV with companies like small PDF, FIT, discovery, GCN and NAVRO.

[00:02:14]So beside this fires also coorganizes ZurishJS contributes to tools like race resist and spends time contemplating life's great questions. So now let's move towards the session. If you guys have any questions, feel free to raise your hand or write down in the chat.

[00:02:35]Okay. So now without taking further time, I would like to pass this virtual stage to you Faris.

[00:02:42]>> Perfect. Thank you so much.

[00:02:44]>> I'm just going to get started with sharing my screen >> and then we can get started. Wonderful.

[00:02:52]Are you able to see my slides?

[00:02:55]Yes.

[00:02:56]>> Fantastic. So already got a fantastic introduction. I might do a little bit also of one on my side. We're going to be talking about building resilient UIs in React. Uh even though this is a React focused talk and we'll see a couple of examples in NextGS2. This is stuff that is agnostic across multiple frameworks and libraries. So whether you're working with Vue, Angular, Astro, Nux, whatever it may be, a lot of these platform, a lot of these patterns are applicable across several of these. So this is not just focused on React. It's just easier if we all look and read something that's a little bit more familiar if you're used to working with React syntax. So, a little bit about myself, already got an awesome introduction. I'm a staff front end engineer at a company called Small PDFs. Um, I've been working there at around about two years. Even though I work at a PDF company, a really fun part uh or fun fact is that I've not touched any parts of the PDF product and people tend to ask me some really interesting PDF questions that I don't tend to have answers to. uh I work predominantly in the uh fintech or the payments part and architecture making sure that we can monetize the platform people can pay and have an accessible way to be able to you know um have people go through our checkout flows retention so on so forth that's what I work on uh I've got previous experience in the connected TV industry across the platforms that Maha mentioned uh fintech fitness technology I love web performance and engineering leadership I love contributing to some open source projects especially Ray Cust it's an awesome awesome project yeah co-founder of Zerg2 running conference in September and several meetups. Uh so I very much am a community first individual and I'm also a Stripe community builder. But enough about that. I want to go back to the subject and talk a bit about how do we build resilient UIs in React. And instead of focusing on the software part of that, I want to like take a step back and focus on what does the word resilience mean?

[00:04:40]And if we just go look it up on Google, no technical definition. It's just simply the act of springing back, rebounding or resiling, which is something that we face in life in any case. When you fall down, when something happens, when you have a down day, you got to pick yourself back up. You got to survive. You got to, you know, essentially have a system with grit. And so, if we think about the English word itself, it almost relates to what we want to do when it comes to applying it to software patterns. You may be building your platforms on local host on your MacBooks, Windows machines with a great Wi-Fi connection and you're going to ship it out in the world and people are going to be dealing with power outages. People are going to be dealing with 3G connections. They're going to be dealing with all sorts of problems and some of them are not even in your control where you're dealing with APIs like maybe Stripe or third party APIs that are open public APIs like the Pokemon or Star Wars API that you have no control over and they just may be down for a period of time. And so you don't want to inherit that lack of reliability or lack of resilience. you want to add some patterns or something into your platform so when it goes down it can spring back up or do something at least to support having great user experience. Now why care about this in the first place? Your React application or any web application is an integration layer. And what do I mean by that? Each of these points of integration are points of failures. Anything you add to an application can fail. You can start your create react app create next app or whatever your barebones application is.

[00:06:12]But the second you want to start fetching data, you're dealing with APIs.

[00:06:15]At some point, you may want to accept payments and monetize. And so that can fail, too. You have authentication, which may not work all the time. Feature flags, which may be down, client caches that you have to deal with. They're partially not working, optimistic updates, which you have to roll back if something goes wrong in the process, and a bunch more stuff. Each of these things can fail, and these are very common things you'll be finding in any web application you build that has some level of complexity. Now, talking a little bit to the experience that I've had in the past couple of years dealing with large platforms, to give you context, small PDF has tens of millions of users per month. When something goes wrong, you find out very fast. And the easiest outages as in something going down or something no longer working, it's out of service are total outages.

[00:06:58]The e those are the easiest ones to notice. So, this is an example of a dashboard and trackjs or you can have sentry new relic, whatever the equivalent may be. And an easy outage to notice is all the numbers just going red and skyrocketing. This is what I would consider a total outage. And this was, for example, a case where one of our API tokens for Brainree, which is a payment service provider, was revoked, not working, and we were having a bunch of errors. 1420 users were impacted as a result, and each of those had an intent to pay. If $10 was the cost of every monthly subscription and I'm sure there were yearly ones mixed in that you can times those user impacted by the amount of subscriptions you would have had and there would have been a pretty large loss. In this same uh in this same sense this is our data log dashboard and you can see the numbers completely plummet.

[00:07:47]These are very visible easy to notice outages that are happening. It's very clear something is going wrong in this dashboard. And the much harder ones to notice are the suff issues. Now, that's what we talked a little bit about about if you had caches or other issues, you could have partial outages with several APIs that you're dealing with. Out of the 10 that you may be calling, one of them may fail and the rest are fine. You maybe have stuff that only fails on certain environments but not all of the environments. You may even have just regional issues. Right now, I'm in Barcelona, Spain. Usually, I'm building stuff when I'm working in Switzerland. I in Barcelona, Spain, our platform shows euros, for example, for checkout. In Switzerland, it shows Swiss Franks. the platform changes based on the region.

[00:08:29]Just like you have localization of languages, you may have problems that only affect certain regions. I've had a case where in the past I messed up an indentation of a YAML file and I took down our platform for South Korea and Japan, but because I was in Switzerland, I had no idea that they were out for 45 minutes, unless you have the appropriate alerting and monitoring to be able to get an idea of what's going on. You could have conditional ones where only retries are failing and only on Safari for some reason or race driven ones where a user tries to pay for something before their payment gateway is effectively loaded and that means that something doesn't work.

[00:09:02]Now this is an example of a dashboard of errors that we have at small PDF and you can see in a given week there are 732,000 errors with a quarter million users impacted. And the great part is we're down 17% from last week. That's a lot.

[00:09:18]That's a massive volume of errors. I almost consider this to be a sea of errors. And so we saw previously that there was an outage for around about a,400 users or 1,200 users. That's nothing in comparison to a quarter million, right? And so when you're relying on trendbased detection or anomaly based detection, depending on how you do your error grouping and so on so forth, you may have a very hard time noticing these issues. And so again, when I say this is a sea of errors, if you were to take a rock and throw it in the sea, because of all the waves, you have a very hard time noticing the ripples. And the ripples are what you may want to notice when something is going wrong because a rock is thrown has been thrown somewhere and there's an outage. There's something that's happening. There's a rippling effect, right? And what we tend to want to do or what we should be doing is creating ponds of errors. So smaller groups of errors where it's easier to notice trends by either having some sort of tagging system of sorts or there several ways to get to a way where you have an isolated scope of a bunch of errors where you have an easier time noticing trends based on seasonality and so on so forth. And if you throw a rock in a pond due to the lack of waves, you're more likely to notice if something is going wrong. Now, to take an example of some outages I've experienced in the past, this was an outage or postmortem written as a result of some postal code payment failures happening in Canada and Great Britain. Again, two countries that I haven't necessarily visited or tested my application in, but for 35 days, because we were sending the wrong postal code format and it was invalid, payments were not working. And so, we lost around £30,000 just as a result of those two countries not working.

[00:10:54]Then there's another one which is even longer where we have 3D secure payments failing. And 3D seccure is not something that pops up every single payment. It's that authentication step that exists where you have to make a confirmation with your phone or so on so forth once you make a credit card payment and then maybe 10 20% of the time you'll have something that pops up. So this is may may not be something you test every single time. And for nine months this was failing. And you can imagine that was quite catastrophic when it comes to numbers. And so what are we learning from this? At scale, detection is much harder than prevention. So we have to work a bit more on preventative measures to work together with detection methods.

[00:11:35]And so what are typical resilience patterns that we could employ? And the first one I like to look at is a circuit breaker. Circuit breaker is something that's very familiar in all of our houses and apartments and so on so forth. You have a fuse that exists and at some time if the circuit is overloaded, the fuse snaps to be able to save something else from not breaking.

[00:11:51]And so if your one part of your system is overloaded, you want to make sure that some fuse snaps to make sure other parts of your system aren't taken down as a result. And it really depends on your architecture how that would take down stuff of the parts of the system.

[00:12:04]You have three core states when it comes to implementing a circuit breaker. A closed state, a halfopen state, and an open state. And so the closed state is essentially the circuit is connected and everything's moving through that system.

[00:12:15]And so you have normal operation requests passed through. So everything's green and looking good. The secondary part is if an error happens or there's a failure and a threshold has been reached, you set all the requests are blocked and there's an open state. This the circuit is broken. And then after a timeout has passed, you want to sort of test this request. And if the test passes, then you go back to fully closing the circuit or if the test fails, then you open back up. And this allows you to just temperature check if the system is in the condition you want it to be in to resume normal operation.

[00:12:47]Now, if you want to look at how this could be implemented in an XJS application, what's great with XJS is you can create API handlers really quickly to essentially maybe maybe even create a proxy layer where over here in this NexJS handler, what we're doing is making a product details request. And so what we're doing is we're using a library called a possum, which I'll show in a second to create a circuit breaker.

[00:13:05]And then what we do is we fire that breaker and that breaker will handle whatever we originally wanted to do maybe as an asynchronous request, asynchronous request or so on so forth.

[00:13:15]and then deals with either returning the 200 response with the status of the circuit breaker and the data or returns some sort of a fallback and error if it's not in the ideal state. And so that if we look a little bit closer to that product details breaker under the hood it's doing what we would have done in any case without the breaker which is fetching a product from maybe some other upstream service and then we set a timeout an error threshold percentage and a reset timeout and it takes care of the life cycle of managing whether this should pass through or not based on the API is working or met that threshold.

[00:13:43]And so you can use this NodeJS library called Apossum to effectively do that.

[00:13:47]It's pretty simple these days. You don't have to reinvent the wheel. Now the retry pattern I like to think is the one that we use the most and we often mistake for being one of the easiest patterns. And I don't think that the retry pattern should be looked at as something that's super simple. It's easy to implement, but it's also very easy to get wrong. And so what happens when we have a retry pattern? If one request fails, you retry maybe a second time or third time. Or if you're using task query, it automatically does three times. But sometimes you can have a case where you have one request that fails.

[00:14:18]And what the retry mechanism does, it just launches a bunch of retries. If you have a bunch of clients that all have failing requests for a certain thing and they all have retry mechanisms built in place and they shoot off a bunch of retries, what they could happen is they could take down a service again. Or what they can do is inadvertently what uh they could actually reach an API limit.

[00:14:41]And so sometimes an API that you're working with may have rate limits like 150 queries per minute. And you could end up having a case where your retries caused you to pass that global rate limit. And we had a case of this happen where for our payment provider, we ended up doing too many retries. We reached a global rate limit and then it took down all other endpoints because the limit is at the API level, not at the endpoint level. So you could be making an an a request to resubscribe a user that gets you over the threshold and then you can no longer even create subscriptions. And this is very dependent to certain API providers. Some of them have limits at the get request level that are different to the post request level and it's dependent on it and potency or so on so forth. And so you really have to fine-tune how you're managing your retries in accordance to um you know the the type of endpoint you're requesting.

[00:15:33]And this is an example of the postmortem for 5 hours. Our API quota was exhausted as a result of those retries. And so what we're learning here is not every error deserves to be a retryable error.

[00:15:45]If we take the example of a 400 error, which is a validation error, if you send maybe a faulty zip code or in badly formatted zip code, you don't want to retry that because a user needs to modify whatever you're sending in that payload to be correct so that it can then pass the next step. Right? But if you already know that a validation is being failed, retrying the same thing is not going to get you a better result. So once we get over to retriable errors, the next part is even taking a step further. Normally retries they spin they they fire one after another exponential backoff starts to create these breaks.

[00:16:19]So if you an exponential backoff an example of that is you may retry one request and then you wait a second to breathe. You retry the second request and then you wait two seconds third attempt 3 seconds fourth attempt and you're giving this breathing space that exists. But a problem with that is you can land yourself into a thundering herd problem, which we'll look at in a second. And if you have multiple clients failing and multiple of those clients are then retrying at the same intervals, what would happen is that if the service were to come back down, you have so many clients queued up to hit the same service, then you take that service back down and that's a thundering herd problem. That's where you, you know, enter with a with a jitter or introducing a jitter which is you have that exponential back off whatever the increase of that second timeout is and then you add some randomness to it. So the first one happens in 1.1 seconds, the second one happens in 2.345 seconds, the third one happens in 4.73 seconds, I don't know, but you're adding randomness to make sure not all clients are shooting things off at the same time.

[00:17:20]So the thundering herd problem is exactly for example what happened to Cloudflare on the 12th of September 2025 where a use effect ran in several loops uh as a result of a dependency array not being um you know they included a problematic object in the dependency array and this caused several reruns of the use effect which shot off several requests. Several clients were doing that and then they ended up having a thundering horde problem which then once the service was available everyone tried to use it at once and then the service went back down.

[00:17:48]And anytime you're facing any problem with the use effect, the best person to look at is David Kpiano because if Cloudflare is down, he's probably gonna say something if a use effect had something to do with it. Um, but yeah, moving forward, which I would say is also another one that we are tend to be exposed to is the timeout pattern. And so this is just as simple as you may wait for x amount of time for something to happen. And if something doesn't happen, then you bail or you stop that from happening. A very classic example could be a long hanging request. And if we're doing server side rendering, one of the problems with that could be in the pages router world where you are making a request or starting a blocking request on the server side in the get server side props to await some data that you want to send as the initial uh pre-populate in the initial HTML and send to the client. Your fastest load time is only as quick as your slowest request. And so you end up getting a new example where let's say I increase the latency of a serverside request to 200 milliseconds to be able to generate this ser this um uh UI on the server side. If I were to navigate to that, you have Chrome just loading for a period of time and nothing's able to send to the client and you have nothing to interact with.

[00:18:59]And so what that happens with a timeout pattern here is that maybe you put a 200 millisecond um you know uh you you you have a 200 millisecond request or you add this latency to it but you may have a timeout at a 100 thousand milliseconds. At that point, what you would do is if the request takes less than a thousand milliseconds, perfect.

[00:19:19]You do SSR, you go to the client. Then if it takes longer than a thousand, you bail and maybe you start to reconcile and you send the initial HTML and then maybe you you recover on the client side. And what this may look like in this get server side props is exactly we have this pre-fetch query which is something from tanstack query. We're fetching something from a transaction service and then we dehydrate that. We pass that in the props. Now what we would do is rework this into creating a prefetch and passing a predefined timeout like 500 milliseconds which is a you know pretty pretty constrained would recommend something a little bit higher than that. You're prefetching with the query keys of tanset query being in the using these query key factories which TK Dota has a fantastic article on and making sure you can reconcile with that in the client which we'll see in a second and what you that create prefetch function does under the hood is uses something like a promise.ra race and depending on whether the promise finishes first for the request uh to to the service or whether the timeout finishes first that's how it then handles accordingly whether it needs to bail or not and then on the client side if there's nothing initially in the query cache being sent because it bailed from that since we use the transaction keys query key factory we can match up against that and this reconciliation process starts where on the server side because we could not attain the information because there was too much latency we go and we try to recover with a loading state on the client side and then we have that retry delay which allows us to have this exponential backoff and so on so forth. So in optimal conditions we're doing SSR and in suboptimal conditions we bring the UX to being in a better place by doing CSR.

[00:20:56]What we could do is even take this one step further if you're using a more modern version of Nex.js like 16.3 where you have the app router and you could stream the results. So you can actually start the request on the server side and then you can stream that all the way to the client to make sure you're not blocking and using partial pre-rendering to send these shells that are generated on the server and then each individual request that's you know servicing the information or data for one of these widgets then streams in and provides that and so you don't block the UI anymore but not every single framework or library provides you that flexibility of streaming so you may have to mix and match. Another one is the bulkhead pattern which most don't hear of because it's more software architecture devopsy or s like to hear of if you're a front-end engineer but it's actually something we very commonly deal with.

[00:21:39]It's error boundaries. The bulkhead pattern is essentially isolating something to make sure that if something goes wrong within the scope of something that it doesn't blow up and affect other things. An error boundary is just a very fancy try catch, right? And that's what we use try catches for. If a promise fails, you catch it within the scope, something throws, and then you can deal with it in the catch. Error boundary, same thing. Something happens in your application, blows up, you just catch it in a global error boundary, and then you can render some error UI of some sort, some fallback UI. Now most applications tend to have a global error boundary.

[00:22:13]And that's not an ideal case because if I show you an example over here where we have four quadrants, four different pieces of UI. Why is the fact that I have an isolated UI on the top left mean that if it crashes, the entire UI goes down and that's what's hitting the global error boundary. These are four distinct pieces of UI that don't have anything to do with each other, but they're all causing the same problematic experience. And so if we even take it a step further and look at Sentry as a dashboard and see what errors are being returned, if I just send the raw responses to Sentry, the raw stuff that gets ingested, you can have you can look and see that we see error, type error, and error. Now, if you're dealing with those 700k errors that we are at small PDF, you're going to have a very hard time digesting this and you're going to ignore it if you have a Slack alert channel that's just showing error, error, error, and you're getting those notifications and they're absolutely useless. So let's see if we can change that a little bit. The first thing is creating these quadrant error boundaries, which is maybe just a wrapper around an error boundary or a specifically defined error boundary. And we're forcing ourselves to encapsulate relevant pieces of our UI. So those four different components, those four widgets would have four different error boundaries. They're each serving a quadrant. One thing we're also doing is we're sending an error tag. Now this error tag is a is a defined um string and you're using TypeScript template strings to make it uh fit a convention of some sort. So you could either say that it has to end in error or maybe this string can end in boundary error or whatever you want. And you're essentially using the type system to enforce sending a unique identifier to an error boundary or to any point of failure that may exist. So that if it runs in the component did did catch and we report this error, we then take that error tag and we create a new custom error with that and send the originating or the underlying error as a cause to be able to keep the chain and uh the stack trace. And that way we're able to create an identif identifiable error which we can then copy and paste the identifier into our IDE and locate which part of our codebase caused the problem. Now, if we were looking at this situation again where we're clicking a couple of times and the UI uh the we still we throw something. Now, you can see that it's isolated to that particular quadrant.

[00:24:30]And on top of that, because you may want a different user experience for every single error or thing that goes wrong, you can provide a unique fallback for that. And so, that's a much more delightful user experience than the entire application blowing up and having to refresh the browser and potentially losing some state if you were in the middle of a flow. then with those error tags passing that all the way to Sentry and you're going to have a much easier time identifying what went wrong because when we had those errors you can see now that we have timer countdown error input render error button no work error and it's much easier to identify in the sense that if you were to receive an email from Centria Slack notification detailing what happened you immediately in the title can understand where in the codebase this happened and that makes your life so much easier in terms of creating a meantime to resolution and that's where I want to start speaking and getting towards the end about how do we measure me success. We measure success and the way I like to do that is with Dora metrics. Door metrics are four core metrics around deployment frequency. How many times do we deploy in a day? And if you're one individual or five person team, you don't have to meet 300 deploys per day. It's not the idea that the more deploys that I do or I every single line I change in a read needs a new deploy is some sort of a sign of success, but it sort of signals how easy or frictionless it is to have a healthy deployment and frequent deployment cycle. and doesn't have a lot of red tape, then there's lead time for changes. How long does it take for it for a commit to get all the way into a production system? And so if you have flaky end to end tests, unit tests that constantly fail or whatever other things that block you or a lot of pre-commit hooks or pre- push hooks that end up being blockers for you to be able to solve something. Whereas if um in the sense that if you were to receive a bug ticket, you may fix the change in 30 minutes, but you may not be able to get out get it out for two hours. So how much ceremony in process is there to get something out into a production system?

[00:26:20]And then what's the meanantime to recovery? So if something were to go wrong, how long does it take you to fix it? And this may not just be about you typing code super fast, fixing the bug and getting it out. It could even mean how long does it take to recognize there was some issue and then get to a place where you can either roll back if you're retaining multiple versions of your application in history. Uh or you have a strategy where you're using git versions and then you're tying it to a different commit hash or you have a really quick pipeline and you're able to dish out that solution or hot fix really really fast. And then finally change failure rate. How often does a change in a production system cause a failure? And so if you have a 100 releases and 15 of those fail or have some sort of an outage, you have a 15% change failure rate. And what's wonderful about this is that these metrics have little care for how many unit tests because we at some point glorify what our unit test coverages or what are our integration test coverage or does our sonar cube pass and we have end to end test for every single flow. But if those end to end tests are flaky, you may not even trust them in the first place. doesn't care what lint rules you have or how many claw MD files or anything else for that matter because what matters at the end of the day is user experience and you want to be able to rely on metrics that you can build that are the least gamifiable possible and that's pretty much it. So so long and thanks for all the fish and if you want to connect with me that l the QR code on the left is the one for you and if you have any feedback in regards to the session it's the purple one on the right. happy to jump to questions, but I'll leave this on the display for another 10 20 seconds in case anybody wants it.

[00:28:02]All right, sounds good. So I think uh we are done for right. So now we can take questions.

[00:28:12]>> Okay.

[00:28:14]So let me just show some questions on screen. Here you go.

[00:28:33]>> So this question is a little bit about the scope of or what I'm interpreting from it is like where are we at in the React ecosystem right now? Uh as most people are preferring Nex.js. So do we have still good React vacancies? I mean, at the end of the day, Next.js is built on top of a lot of stuff that is React, right? Like, um, if we're thinking about maybe the job market, we did have a big boom in terms of maybe the amount of React jobs or React came back to the top as one of the libraries or frameworks, especially because in the in the AI era, so many of the models are trained or have a preference or a bias towards React. So, that's why I would still say that there's still a lot going for it. the NextJS team. I think Dana Bramov recently joined the Next.js team. You got Aurora that's on the NextJS team.

[00:29:20]You got a lot of awesome people in Burcell's um bringing some really cool talent to the Next.js team and they're doing a lot of effort to do some more uh community oriented work and support in the ecosystem. And so I think you're generally safe if you go for Nex.js in the sense that if you're picking in the React ecosystem, Nex.js inadvertently means you will know React. You have to know React to be able to do Next.js.

[00:29:43]You're now just picking what is the way you want to go about building your application. Even if you look at the react docs, react docs will suggest that you use create next app because most people go for frameworks and with react barebones, you tend to have to plug in how do you manage routing? How do you manage x y and zed and nextj just comes baked in with those opinions. So you're pretty safe going there. But I would also encourage looking to see where the ecosystem is going in terms of you know trying out tanstack start or trying out Astro because you can even write react components in Astro and you can very quickly transition an XJS application into Astro. So just understanding like h how different frameworks are handling SSR or streaming or composite components um React server components or how they're handling just not sending a lot of the JavaScript bundle over to the client and doing a lot on the server side and remaining static first. So I would just recommend keeping an eye out on that.

[00:30:35]>> All right, sounds good. Thanks for the answer. I hope say got his answer. Now let me just get to the next question.

[00:30:44]Here you go.

[00:30:49]>> Cool. So as a beginner, can we start with React for full stack web over nextg to land our first job? So React naturally isn't a full stack framework.

[00:31:00]That's what Next.js was created for because Nex.js allows you to create those API routes and that's what creates it as a makes it its full stack framework, right? It allows you to create the backend and allows you to have the front end in the same codebase, right? And so generally today the expectation is in the job market moving towards full stack development product engineer development because with these AI assistants now we have a little bit more flexibility that even if you're a little bit more front end first like I am you still have some flexibility to architecturally understand or conceptually understand how you're supposed to do some things on the back end and be able to execute and validate that with an agent. You know in my day-to-day job I'm not a go I I don't know Golang, right? But I have to deal with a Golang back end. And so I'm able to send a cloud code agent to go review how certain things are done within from a logical perspective in a Golang codebase in respect to how the open API specs are designed in terms of the endpoints that I have to work with and helps me understand the business logic of the back end to be able to work with the front end. Right? You're going to if you're really starting out, I would say start with React first just to understand the concepts and the scope of React. Like what is React for? Where are the limits? what when what point do you have to bring in routing into the story at what point do you have to bring in stuff that nextgs already has baked in and then add nextjs as a layer on top.

[00:32:16]So then now you can separate the two and if you work in code bases where you have only react like right now I work in react codebase that doesn't even have server components the react 16.8 codebase I can understand the limits of working with just that rather than a full baked solution like react uh like nextgs. I hope that answers it.

[00:32:34]>> Yeah, thank you again for the answer.

[00:32:36]Now just let's to the next question.

[00:32:42]>> Okay, here we go.

[00:32:45]>> What are the top best practices you use to build resilient UIs in React? Um I think generally the question also is like what point should you build resilient UIs in React? Um you can get away for a while or without a lot of scale um before you need to implement resilience patterns. you're if you're building a side project and you're build or building any react application that has under actually I can't even say under 10,000 users because if you have an enterprise application you tend to have a smaller user base but each user means a little bit more what I would say is it very much as all software things it depends if you are using something like tanstack query you are benefiting already with some resilience baked in so setting the right defaults in terms of how many retries you want already setting up the retribal errors are small gains that you can bake into whatever you're building without having to rearchitect how you think about building your application and resilience into it because sometimes it can be a real pain now reworking all the error boundaries or reworking circuit breakers into every single thing. Start with the retries that's the easiest. If you're doing a lot of SSR maybe timeouts are the way to go. And if you're going for stream if if you have the app router you can just go for streaming out of the box and you don't have to deal with that timeout problem. the best practices are only as are really dependent on what you're trying to get out of the application and who they're what it's servicing.

[00:34:13]>> Right? That makes sense. Uh we have last question for us, I think. Yes, here we go.

[00:34:21]>> How long would it take me to learn React as a beginner? I have experience with PHP and Laravel. Would React be a good addition to my skills and resume?

[00:34:28]Depends on the kind of developer again that you want to be, right? Um, I've seen people pick up React in a couple of weeks, right? And that's that was fairly easy for them. For other people, they can also pick up the basics of React.

[00:34:42]And React is not super complicated. It's a very forgiving library, right? Um, then understanding the nittygritty of how the reconciliation works within React, how maybe server components work, or how do you want to compose things or work with a large codebase. That's what takes a lot of time and a lot of experience.

[00:35:03]My recommendation would be is we're in a world now where I think there's a little bit less expectation on do I need to know react or do I need to know Vue or do I need to know Angular but more do I have software fundamentals and understand what my web application needs or what do I need to implement in it. Right? So if you have an application that you've built in the past um whether it be for me it was a fitness application where you could book classes and you can rebuild that in a couple of different stacks just to understand the bounds and the limits of each one of them and how you're trying to express the same thing in different libraries and frameworks. You're already going to become a better software engineer and the stack won't matter as much. So take something build it in React. Take that same thing, rebuild it in view. Take it and see how much further you can go if you do next.js. Do pages rather than switch to app router, right? And you'll change the way that your brain associates building web application less with the syntax and whatever framework or library you're using and more that I need to implement caching. I need to implement something needs to rerender. I need to manage state at some point.

[00:36:12]That's what's important.

[00:36:16]>> All right. So, I hope that also answered the question. Now uh thank you so much Price at the end for incredibly insightful session >> and I'm sure everyone here gained a lot from your valuable insights and also I would like to thank everyone who joined us today and ask the questions. I hope you made most of the from this session.

[00:36:39]Okay. So if you have any further questions for F please feel free to reach out him on LinkedIn. I have shown his LinkedIn profile on the screen. You can follow him. Thank you >> and connect him. Once again, a huge thanks to Prize for joining good with us as a speaker.

[00:36:56]>> Thank you so much. Have a fantastic day.