High-performance Next.js

Okay, so welcome everyone to high performance next.js before we start let me introduce myself very very briefly. I am Michaela. I I'm from Milan in Italy. I work as a senior software architect at near firm. I'm a Google developer expert and a Microsoft MVP and you can find me on Twitter at Michaela code. So this is where I live most so if you're interested in staying in touch with me, this is where you can find me basically every hour of the day. I'm also the author of real world next JS, which is a book that as in my guest talks about next. Yes. So again if you're interested in Talking about next year's we will have also Q&A session at the end of this Workshop. So before the end of the call, we will have the possibility to share our thoughts. I can answer to any of your questions, hopefully, so what another very quick poll how many of you has participated to react Summit as an attendee or speaker? Okay, a couple. Oh, wow a lot of people. Okay great. So how many of you have seen my talk about next year? Yes. Okay, great. So I will test if you were paying attention because part of this Workshop is based on that talk and I will give you whatever you need to. Be be able to to write the next next year's app. I didn't want to repeat myself, but that happens. And so sorry I see one hand up. So sorry. What's your name? Designer do you want to say something? Okay, no worries. So never be worried about interrupting. Oh, thank you for it was amazing. Thank you. Never be worried about adapting interrupting at any time. Please write me in the chat or raise your hand. I will give you all the time you need for asking questions. Don't worry about that. So I know at this point many of you has followed the talk, so that might be a bit repetitive, but I need to repeat a couple of Concepts about next JS taking from my from my talk so that we are all on the same page before proceeding any further. So let's start by asking ourselves. What is next Js? So next JS as we all know, it's a server-side rendering framework basically for next for react.js and it basically wants to solve a problem that react has as an intrinsic problem of the nature of react itself. So basically when we build a single page application or an entire application with react, this is what we get when we first load the page, right? We see a spinner and we have to wait for the whole bundle to get transmitted from the server to the client. Then the client has to render the djsx and eventually after some time we end up having our website. So and we can start browsing the website after the hydration process. So as you might guess it depends on the kind of website that we have the perform the performance is can really vary. So if you are good developers and we defer a lot of loading with lazy load stuff we might be in that scenario for a very tiny period of time but if we have a very large application that can take up to several seconds, which is very very bad. We all know that given the Google risk purchase people tends to abandon a website if there's no content after four seconds, so we really care about time to first bite first contentful paint and all the metrics that we need. To determine if our website is performant enough or not. So this is the problem with client side rendering mainly so better performance is on first load and also bad performance is on the SEO so search engine optimization level. Nowadays Google it's capable specifically Google. It's capable of indexing content build in the virtual Dom by react angular view Etc. But we also have to think of other kind of search engines. So for example, If we care about the Asian market where Google is not the number one search engine, we have the index for example, which is not capable as for today. As far as I know through index content created by react or virtual tone content. So if you let's say you build an online e-commerce that targets specifically the Asian market, then you might be in trouble because Google it's not the number one search engine there. So we can't guarantee a good SEO result for our web application. And again, please let me know if you have any questions. This is the right time to to ask for them because I can explain more in detail if there's something that I'm missing or you need more information about. So okay basically client said rendering so we will call this CSR from now on as pros and cons. Right? So it makes it makes your app feel like a native app. So when you're browsing your single page application, it feels like you're on a smartphone right because you have super quick transitions everything. It's already loaded into the browser and we just have to render it. So there's no page refresh and continue communication through the server and waiting for the response to refresh the page. We can make everything extremely lazy and by lazy, I mean that for example We might not have the content for let's say we have a single page application that it's a Blog right? We might not have all the pages for the blog. Of course. We will need to ask the server for the data to be inserted in every single page. But we do that lazy every single time. We want to assess a page and we can we can make like positive uis. Do you know the concept of positive positive uis? Thumbs up if you do, otherwise I can explain and try to explain it at least. Okay, just one. Okay, great. I will explain so for example. How many of you are on Instagram? No one. Okay. Okay now okay. Now it makes sense great. So basically Instagram, it's a perfect example of what a positive UI is right. It means that for example, you are offline you have in cash a list of posts. You can double tap on a post to give a like right, but if you are offline, there's no way that you can communicate with the server because you're offline, right but it will say okay you gave a like and as soon as I go online, I will give this I will send this communication to the server so that the like can be propagated to the user receiving the like for example So this is an example of positive UI we presume that everything will go right at first time and if anything face we will just give a warning so that's the case for clients that random. For example, we can deeply exploit these kind of psychological you user interface and user experience where we say. Okay, you're asking for that page. I will preload the page with a skeleton loading Etc and I will assume that the server will send me the data to be rendered on the on the on the page and if the data it's not available in the in the database, for example, I will just give you an error no problem. Otherwise, you have a very smooth user experience and this is really really important when you're writing web applications. Please let me know if that makes no sense. Let me see in the chat. So okay. Dimitri is asking is the positive UI a kind of progressive web app progress. Oh, sorry. Yeah people way. So yes, let's say it's I wouldn't merge the concept of positive UI with the progressive web apps and that's because the positive UI it's a way of Designing and thinking about your application and it's really easy to implement it with clients that rendering applications for example on Native applications because you already have everything inside of your JavaScript bundle. So you don't have to continue communicating with the server and refreshing pages every single time. You just assume that everything will go. All right. You want to leave a comment? No, man. It doesn't matter. If you are not able to reach the server at this time. You can show the the comment right now on your blog post and retry several times until you can reach connection or just give an error after and fix the amount of time. So, this is a very good Advantage. I see in exploiting clients that rendering capabilities and I really wanted to go deep. That concept which is something like couldn't explore during my talk because of you know time limitations. But again now it's the correct time to expand on certain Concepts. And so yeah, we cover why it makes you feel your app feel like a native app a white page transitions are so easy because you basically don't have to refresh the page. Right? So you just make a transition from one page to another lazy loading and performances. We already covered that and less server cell workload. So basically if you how many of you have ever tried create react app Okay. Okay several people. That's that's super cool. So you perfectly know that for example, when you have a create react App application you only need basically one HTML file CSS and JavaScript, which are all static assets. Once you have static assets you take those assets you deploy them on a CDN on AWS S3 and you don't need a server at all. You just take this files and throw them on something that will serve them for you. You don't need a server at all. You might need an API server, but that's something else. We will discuss this later. You only need To serve static assets which makes makes first of all your infrastructure way cheaper because you don't have to my internet server which means you have less. It's a cheapest or cheaper option. You don't have to maintain so you don't have to pay a person for maintaining a server security releases and I don't know I run time upgrades whatever so that's super super cool and we already see the cons of clients at rendering so but for SEO and bad for initial page load time, so we know something about that already. But the problem is that this cons are really bad for modern web development. Right? So this is where nextgs alongside other other Frameworks such as Razzle or I know angular Universal nukes. And so and so on they provide a new way for rendering react, which is server set rendering. So why with client said rendering we see a load there a loader spinner or whatever when we first assess the page. This is not the case for service centering where as soon as we make a request the server will pre-render the page, of course on the server and we'll transmit the final page to the client. We already know that So eventually we will have the pre-rendered page on the client itself. After that, there will be a process called react hydration, which will basically make our application interactive so we can start if we have like a new state if we have a use context. If we have any hook running or any JavaScript script running on the client, this is where hydration will run and we'll make JavaScript interactive on the page. pros and cons again web applications might be a bit more secure and that's for a very simple reason. So imagine you have a client-side rendered application. And you have like what's the name an account page where you can update your password for example, okay. What happens at this point you want to update your password? You have to communicate with the server and you have to send a new password to the server. How many of you are familiar with the concept of men in the middle? Okay. Okay, cool. A lot of people let me. Okay, let me give you a short example for the people that it's not really familiar with that. So many in the middle. It's a kind of attack which is a big security concern that basically let's say you are in a public hotspot and you're connected to a free Wi-Fi source. Well, you don't know who is basically running this wi-fi. So whoever it is he can they can have access to the data you're transmitting from the client to the server. So if you're sending a password and it's not well encrypted or end to end the Crypt that this person could potentially see your password and use it and I'm 100% sure that the vast majority of us. It is in the same password for bank accounts, Facebook Instagram Twitter and whatever and not blaming anyone, I'm one of those I know but that's what happened and that's why we really care about this. if we have a server that means that certain critical calls can be run server to server. So the traffic it's hidden for malicious users that also means that we have access to http only cookies, which also means that browser extensions or third-party scripts cannot have access to the cookies on the client side. So these is a big game changer when it comes to security and that's because there is no basically we can high traffic for from the from the users of our website. Let me see in the chat. I got my password hacked before was a real pain. I recommend using something like LastPass. Yes. Absolutely. If you're a Apple user just use the built-in Tools in apple. I use one password and it's working very very, well. Absolutely. This is a very good suggestion. Thank you. So we can basically we were saying we can basically hide our traffic great. Another Pro is that we have more compatible websites. So given that we render everything on the on the server side. It means we are sending an HTML5 directly to the client and the browser if JavaScript it's not enabled for example on the browser. You can still navigate the website in some ways and that's because you can fall back to Links instead of State Route push Etc. It depends on how you manage your website, but technically speaking you might have more compatible website even on older browsers. Enhanced search engine optimization, of course, we have that and that's because again, we have already rendered all the HTML. So the Search engines will be able to to index the content way easily. They don't have to wait for the virtual Dom to load and then wait for the content to show up and also highly Dynamic content, which means that we can create new pages depending on. Who is browsing the website so a very quick example, let's say I am one of the users and I see first on my screen Logan. So I will take you as an example. Let's say I am logged in as Michaela Logan is logged in as Logan we couldn't have two very different experiences directly from the server side because of our users. So we are different users. We might have access to two different experiences, right? Okay. so this is a nice to have There are also some cons. First of all a server is required. So there's no way we can run server-side rendering without a server those days. We have many different alternatives for server-side rendering we have for example serverless environments so we can deploy our application to what's name AWS or Google cloud or eight as your functions and we don't need a server in a strict term. We can use serverless environment or we can use Google Cloud run Computing or ac2 and AWS we can use whatever we want. But we need to maintain something or we need to pay someone that maintains that for us. So if you follow my talk, you know what I'm talking about, you know, I mean the costs are really really high. So higher server workload means that as soon as the server gets certain number of requests. So we have more requests coming there will be more workload. We will need to scale or in the case of a serverless environment. We will need to pay a lot for running for making our application scalable. That also leads to a higher maintenance course. So let's say you are running a kubernetes cluster with a number of PODS and a load balancer balance in the traffic amongst all the parts. This is something we have to maintain. This is not something easy. And let's say there is a very high security fix on nodejs 16 and we want to upgrade it. We have to upgrade the image of our containers on several different parts and then we want to upgrade to note 18. So we have to run another maintenance operation, you know, so While server-side rendering it's giving us many ways for keeping stuff easy make it comparable make it secure. It also have some very heavy drawbacks. So that's something we want to keep in consideration any question on that before we proceed. You can also use the chat if you prefer. Okay, let's go. Last but not least one of my favorite random strategies so static side generation. So it's quite similar to server side rendering except we build the pages at build time. That means that it's super easy to scale because we end up having only static pages. Right? So we we don't need the server. We don't need a server on the on the back end because we we already have built everything at build time performances are the best performance is possible. And that's because we already rendered everything. There's no server workload at all. We only take a file from a CDN serve it or take a file from a server and serve it again requests are typically secure for another reason. It's a different way of thinking of security in that sense. We don't have a server which on one side can allow us to you know deal with the security with private information but not having a server also means that that might not be subject to for example distributed the night of DDOS. Sorry not. it's really difficult for a non-native English speaker to talk about that. Sorry. So we we might not be subject to DDOS for example attacks because typically if we deploy our website for example on cloudflare pages cloudflare it's built to resist this kind of attacks, right it's built to resist to slow loris attacks, for example, so we have another kind of security in that sense and depending on the content of our website depending on the purpose for our website. This is something we want to keep in consideration. And it also has some counts. We already know that so no Dynamic content on the server side. So again, if I log in and another person logs in with a different user we would have the same experience basically unless we render stuff on the client side. And in fact, it has to rely on clients are rendering for dynamic content. and the worst part is If we have a very large website with like I don't know. 1 billion pages and we made a typo on one of those we have to rebuild the entire website to fix that type, right? And thankfully next. Yes fix that with incremental static regeneration. So we will see that in a second. One nice thing about next. Yes. We already know that it's hybrid rendering means that for every single page. Every single page now website can adopt a different rendering strategy. That's really important to know. Then I see sorry. I'm going through the chat. Okay, I see Logan saying personally I have found SSR to be. not to be much better low time than CSR SSG seems better in almost every case 100% agree on that and this is your anticipating something. I wanted to say later on and this is which is very good. If you want the secret of making nextgas Fast the secret, it's this we can say that in like one second. This is a free hours Workshop. So I didn't want to say that at the beginning but we're already there. So let me say it. When you need high performance is in computer science, you typically do two things. caching and queues in that case we have caching so you can either use a static side generation. Which is basically or any incremental static regeneration so that you build the page you pre-build the page that build time or if you are in the situation like Logan where you say SSR, it's not much better than CSR and I totally agree with you in that case. You want to use a CDN in front of your website so that you can cash the response and serve the response without hitting the server every single time. This is the real secret of making every web application fast and next year. It's not an exception one. Nice thing that you notice when you start writing next year's applications is how versatile specifically so the team behind next. Yes is good at dealing with the cash. If you look at the caching headers cashing mechanisms, they do an owe some job for all of us so cashing. It's the answer for running a very fast next year's application and it's also the answer for making it cheap because you know, if you hit for every single time for server-side rendering I mean, this is costly you pay every single time. It's the server but if you have a CDN you pay for every billion of requests every million of requests, which is way cheaper than a server. So yeah, I totally agree with you and static said generation. It's in my opinion the way to go for most of the cases, but there are some extra exceptions and we will see them later. Okay. Oh, thank you Joseph. I'm glad you're here too. And now it says can we have next? Yes in some part of our current react application that needs SSR of or SSG? so if you mean that you already have A react application and you want to transform it into an xjs application. There are a way to do that. There are ways to do that. I think there is also a code mod on the next us repository that helps you transform your current react application into next js1. From from now on you can basically just use an xjs and decide to use static side generation class rendering when you need it and whatever. Oh, okay, if you mean gradually migrate to next Js. Okay, things are getting more interesting at this point, but we will be going into a software architecture. Meaning that you could have like an API Gateway somewhere saying okay all the pages under let's say slash blog now. I will route this this traffic into an xjs application all the other routes or create react app. So to these things servers serving two different applications. You can do that with a reverse proxy. For example, like engine X Kathy or whatever or you can do that with an API Gateway. So you can route the traffic on some routes goes on next. Yes other routes those on react one nice thing is that you can share components. So should be quite easy to do it. Okay, Logan says just a deep. Oops. Sorry just the difference in build time over create react up. It's worth it. Yeah, and yeah and Felix is also right swee is such a good Builder and the performance is insane. Yes. I totally agree with that. And I do know how many of you are aware of that. But let me ask a question how many of you are writing typescript? Okay, I'm super happy to see people writing typescript. You gotta know that. Oh some. Okay. So the creator of a swc it's now writing a porting of the typescript compiler in golang. So hopefully we will also have awesome performances during type checking in Nexus and in typescript in general. How cool is that? And this project it's also supported by versa. So I'm a huge versatile fan as my guess. Um, okay. He brought him how much easy is to access user cookies in SSR and SSG in case of session based off. This is a good question actually. And so basically with the biggest problem I see with cookies. as we were saying before you don't have access to server-side cookies with the SSG. So basically it means that if you have HTTP only cookies you really need service at rendering to to get this cookies. Why do you want server server set only cookies for security concerns so that if you incorporate a script a third party script browser extensions, they won't have access to the cookies. so this is why I find cookies to be a bit dangerous and a source of big hacks, you know for any any web application not just JavaScript based and sorry I see savinda having a rising their hand. I don't know if you have something to ask. Oh, no. Okay, I guess not. Okay. Felix says as far as you know static surgery, it's not made with user information in mind. You have to go with SSR. This is correct. But how would also like to point you to for example out zero right. So if you are in using Auto zero or AWS Cognito or any identity provider? They have sdks for client-side only applications. Maybe you don't have to use cookies. So that's my point. You can still use. Authentication we can still use user sections with client side rendering so also static side generation. It's just a different way of dealing with it. And in my opinion it's a bit more insecure. If you're not aware of all the risks that comes with that. So if you use the official SDK for out zero, I'm super happy with that. If you have to implement your own authentication, okay, that things becomes to get more interesting. You know it. Is there anyone okay, this is a strong strange question. I'm sorry. Is there anyone who wrote my book yet? Didn't want to promote just asking. Okay in my book, there is an entire chapter describing how to build authentication from scratch. So how authentication works and why you should use of the zero for example. So if you're interested, I'm sorry. I didn't want to promote my book so bad, but there is an entire chapter talking about that and how to deal with Authentication. Okay. Okay. Thank you for buying it. So let me go with a couple of more explanations, then we can start dividing in teams and work all together. So let me explain quite send rendering for those who are not very familiar within a with naming. So basically you make a request to the server as soon as you make a request. The server sends, you are white page blank page with the JavaScript bundle as soon as the bundle gets what's the tour gets interpreted by the JavaScript engine on the browser. It starts to be the whole page. Okay. So as you can see as time passes by we compose the page one piece at a time. So we might need several seconds again to have our page complete. This is not the case for server-side-drending. So you make a request you wait several seconds at this point if the page is really heavy, of course on the server you wait for it and you get back to complete page after several seconds. With the static side generation you ask for the page the server already have it. It doesn't have to render anything and will send back the page. And you're done. So that's all you need. And okay. Sorry. I see a couple of questions. Oh, thank you for sharing the book. You can also buy on Amazon if you prefer. Okay, so as we were saying this is super cool right stat. It's a generation is super cool. But still you need incremental static regeneration that basically allows you to to rebuild a particular page after some any. Let's say after X seconds have elapsed. So for example, let's say you have a typo. Oh, no, like explain with this example. Let's say we have this web page. Okay, we say that every five minutes. We have to check if there's a change in that page and if there's a change we have to rebuild the page and remember this is a statistically generate page. So after one minute of the publication, One user comes they will see that page right after three minutes another user come and see that page again. After five minutes because that's a lazy operation another user comes and see the exact same page as for the other users. So five minutes has passed the next user will trigger a new build for the page. So the next user after five minutes, we'll see the page the new page which in that case shows an Irish Setter instead of an English one dark background Etc. So after five four minutes another user comes and we'll see the same enough five minutes. Another user will see the same page again. And now there is an error you see this is an Irish sector not an English one. So if we want to publish a change because there's a typo after five minutes. We will have a whole new page for the next users. So to interrupt but no, why does the whole content change? I don't get that. Oh, okay. No, no problem. So, let me go here. Let's see. We we want to change that page. Okay, the page content. We don't want to rebuild the entire website, right? Because maybe the let's say this is a very big website so we don't want to rebuild it. Because maybe it takes like let's say I've been working in a company where the whole build process to like three hours. It means that if we have a problem on a Content coming from an API, and we have to change for example the background color from light to dark we have to wait three hours and that's just an API call telling you the color for the background, right? So with incremental static regeneration, we basically statically generate this page. And we say okay next JS every five minutes when a user comes look in the database or look at the apis. Look at the data inside get static props. Look at this re-execute get started props and re-render the page every five minutes if there's any change If there's no change. We will keep it as is. If there's a change, for example, let's change the dog image and the background color. Then apply the change. In five minutes if there's no change we will keep it as is. I hope it's a bit more clear now. Yeah, thank you. Okay. Okay. No problem. It's good that you ask please everyone ask questions as much as you can. So what this is something that it's a bit confusing because I say that This page is statically generated. Well, actually it's not beware of that incremental static regeneration means that we set some caching HTTP caching headers. So the page is run under server-side rendering again, but we have some caching headers. So it's not a static page. You still need a server? Okay, I want this to be very clear. Okay. So I've prepared a very very simple next year's application. You can find it here. Please clone this repository and thumbs up when you cloned it. One requirement for this Workshop was to have no JS installed on your machines. So I hope everyone of you has no JS installed. Okay, cool, so This is what we'll do. You will need to install autocannon. How many of you are familiar with autocannon? Okay, you will like this. So sorry, I have this very big Zoom window and I can't see anything on my computer. Oh my God, this is so bad. I can move it. Okay, so let me show you. How to Canon it's a super powerful tool for stress testing your applications, which is also giving you some benchmarks. about how it performed so Never try this against live server. Only do that on your local machine. It is not legal to run DDOS attacks against any server, which is not yours. Please remember that but this is super useful for us and I will show you how how so you basically have to install it. So npm install autocannon. Let me share with you the command again in chat. Just install it. And there are a number of options. I would like to experiment with those options. And with it will give you the following output. So it will tell you the latency. Let's say by default. It runs on 10 different connections it runs. that case 200 250,000 requests in 10 seconds, and it will show the latency. After 50% of The Benchmark 97% of The Benchmark Etc. And request per second as The Benchmark goes on. So if we talk about performance we need some numbers, right? This is a perfect tool for measuring performances. So show me your thumbs. How many of you have installed of the Canon right now? Oh some oh some good. So this is the first task. You have to build you have 15 minutes. You have to build the next year's application run out of Canon against it. So please read the documentation. I wanted to collaborate. Then instead the application you will see next JS app. If you go on pages there is only the index page because that's what we care about now. If you're looking at my screen, you will see get server-side props. And you will also see that I have commanded get static props. So you will need to change get server-side props. comment this uncomment these and run autocannon again. Then you have to compare the results. Then we will go back to the main room. So the one where we are now the main room. And and we will comment the results together. Okay. So you will see if you go on API for products that I created a random latency function, which means that it will give you up to five seconds latency for every API call for composing the home page. So don't worry if it's slow this is on purpose, okay? And my suggestion for running these this task would be choose one person which will share the screen and then you can start coordinating the efforts. Okay? So let's move on. Okay. So task number two. I would like you to try know the clinic how many of you are familiar with? No the clinic. Okay, let me do the other way around how many of you are not familiar with? No clinic. So not Clinic. It's another tool be it in your form the company I work for. Auto Canon was one of those not Clinic. It's another one of those and basically not Clinic. It's a profiler for your nodejs applications and also and now it also supports next JS. So there are many things we can do for example not cleaning doctor. So basically you can run node Clinic behind autocannon. And it will profile and found potential issues in CPU usage memory usage Etc. Bubbleproof, which is a bit more trickier, you can see which function has basically a dependency on another function or is triggering another function again Etc. There is flame, which is awesome. It gives you a flame graph of the V8 engine on node.js of your dependencies of webassembly wherever you need. And the Heap profiler of course, which provides the heat for the node.js runtime. So when we talk about performances also in nextgas, of course. We will need these tools. So autocannon and node Clinic are two of the tools you want to have in your tool set. For you know helping you understanding how to enhance the performance of your applications. So the next task would be installed Clinic. Sorry, let me take the Should be just cleaning. on npm Yes, so just install it. Let me share with you. Okay the command. Install it and another 15 minutes. You have to build the next yes app and run the below screen. So let me copy paste the script. It um, I do expect to see a problem. So it I I mean I made some tests. And it showed some problems. I want to see if you had the same. Okay, sorry, stop the sharing. I want to see if you find the same problems run it with SSR or SSG in that case. I would say try with both. But in that case with the doctor, I would expect the very similar results. So it's not about performances in that case. Why not both the jpeg? Yeah. It's not about the performances but about The way you can look up for errors in your applications, and there is one. And I want you to find that error. It's not on a bug but it's something that it's slowing down everything. So I want you to find this using node cling. Okay, so I had a question from Joseph. We'll be going over the use cases all for using either SSG SSR or it's as I are told by chance. Yes, absolutely. And actually I'd like you to be thinking about that and I will be reviewing your your ideas. So let me share my screen again. Okay, so it was on GitHub, okay. So, this is Task number three. And this is where I want you to really think about. What's the best solution I will divide you again in the breakout rooms. And you already have the products. I want to create a page for every single product. And I wanted to justify which rendering method will use for every single product. How does it sound any question? The idea would be to have one person sharing the screen inviting code and not in the other people helping this person. Okay, every time you have a problem, please write me in the chat. Here on Zoom. I will be there for helping you. And I'd love to hear some discussion in the team to determine which is the best solution and how would you approach that as it was a production? Solution I will share with you the slides so you can continue the workshop on your own but we don't have time to go through the next slides, but I want to talk to you about adrs. How many of you are familiar with the concept of adrs? Okay, so ADR it's short for architecture decision record. And that's because as we were saying at the beginning thinking about next year's it's also a work for our software architect because this is not only engineering, you know, you have to to see your whole infrastructure to determine how to support High loads. So adrs are on Amazing way for determine how to create our Let's say our infrastructure or our web server or whatever and it's also good way to discuss this with your colleagues and also with your manager. So let's say you have to write a social network web app just like Instagram like in my talk. I you told me many of you was my talk. So you're already know where I'm going and let's see. The homepage is common for every single user the content changes depending on the user login. So we don't have 20 minutes right now, but I will leave you this. Let me take this link. I will share in the chat. I would like you all to get known to the ADR. So if you have a doubt if you don't agree with your manager and you want to be efficient in telling what's wrong about the current solution, or you want to propose something new. Well the ADR it's the right way to proceed. so you basically have a title for your ADR for example, social network homepage. Okay, the context and problem statement which might be like I have to build an a social network. I have an homepage the homepage shows content depending on the current login user and we have a lot of traffic a lot of static assets. So this is the kind of problems you need to deal with, right? Consider options so we could go with static side generation for the page or server-side rendering for the page. We could use incremental static regeneration. So these are the options we are considering Decision outcome we decided as a team or I decided as an individual by comparing my option with my manager's options. For example that for me the best option is and I'm giving you mine static side generation. Why is that so positive consequences of static set generation in my opinion is that um the content is highly Dynamic and depends on the user that it's logged in, right? It means that if I log in another user logs in we will see different feeds for for example on Instagram depending on the people we follow so it's not really important for Google to index the home page. Google only wants to index, you know, the header the title of the social network Etc doesn't want to index the content of the homepage. So we can just statically generate it and serve it through a CDN which is faster, which is more reliable. What is the negative consequence of that so we go down negative consequence negative consequences are if we have to change the logo we have to rely on incremental statutory generation or we build the whole website. We know that. pros and cons of the options So for static side Generations, we have pros and cons. For incremental static, sorry for server-side renderings. We have this pros and cons. And for incremental static regenerations, we have other pros and cons and we put everything there. More information if I want to give more information to my team my manager and whatever. So it's my opinion and that's a very personal opinion. That this is the best way you can propose something to a team to your manager to your colleagues because you there is a formal way for communicating and it's a complete way of determining how you made your choice. So given that as we saw this Workshop, it's more about architecture that engineering at this point. This is the way you deal with software architecture in a very effective way. Yeah. Absolutely. There are many different templates. This is my favorite one. You can look for ADR on Google and see the template you prefer but the concept it's always the same you give many options you document your options and you give your suggestion and then you discuss So that's also a way for keeping documentation about the decisions you make on an architectural level and by doing that I'd like to share my contacts. So in the meanwhile if you want to Take my contacts. Follow me on Twitter LinkedIn and GitHub. This Twitter is where I live most so please feel free to reach out after the the work.