1 00:00:06,719 --> 00:00:10,800 Hey, welcome to Adventures in Angular, the podcast where we keep you updated 2 00:00:10,880 --> 00:00:15,640 on all things Angular related. This show is produced by two companies, Top 3 00:00:15,679 --> 00:00:19,399 and Aves and Onvoid. Top and Doves is where we create Top and Doves 4 00:00:19,399 --> 00:00:23,559 to get top and pay and recognition, but working on interesting problems and making 5 00:00:23,559 --> 00:00:29,600 meaningful community contributions. An Onvoid which provides remote design and software development services on 6 00:00:29,640 --> 00:00:35,439 a performance basis, so clients only pay when tasks are delivered and approved. 7 00:00:35,960 --> 00:00:42,240 In today's episode, we will talk about server side rendering in Angular all the 8 00:00:42,600 --> 00:00:46,520 nuts and belts that comes with it. So we're going to talk about what 9 00:00:46,679 --> 00:00:52,640 is hydration three rendering, attP caching, a lot of stuff that is baked 10 00:00:52,719 --> 00:00:56,479 in that, and we will also try to cover some of the improvements that 11 00:00:56,520 --> 00:01:00,960 we had to assr in Angler seventeen. My name is Luke Spaganini. I'm 12 00:01:00,960 --> 00:01:04,159 the founder of Onvoid and you're hosting the podcast and joining me in today's episode 13 00:01:04,319 --> 00:01:08,599 is armand Vardenian. Hey, everyone, seems like I missed a couple of 14 00:01:08,640 --> 00:01:17,200 episodes. Yeah, it's always good to have you. It's nice because when 15 00:01:17,200 --> 00:01:21,879 you join, I already know that it's gonna be packed with content. Every 16 00:01:21,920 --> 00:01:25,719 time they join us. Like you know, Arman always joins them before we 17 00:01:25,760 --> 00:01:29,359 start recording. He tells me, I have so much to say, and 18 00:01:29,439 --> 00:01:34,519 I'm like, okay, yeah, well that's great. Thanks to the Angular 19 00:01:34,719 --> 00:01:40,920 core team, we have content for years to come. I guess. Yes, 20 00:01:41,400 --> 00:01:45,920 yes, they've been very, very busy. Okay, let's get into 21 00:01:45,959 --> 00:01:51,719 it. So first, let's just explain what is server side rendering, because 22 00:01:51,799 --> 00:01:57,079 I'm sure that there might be people out there that don't even understand what it 23 00:01:57,159 --> 00:02:01,159 is. And then we can go into why it's important to benefits, pros 24 00:02:01,200 --> 00:02:05,439 and cons, and then we can talk about the futures. So Arman, 25 00:02:05,519 --> 00:02:10,680 would you like to tackle that question? Oh sure, I have recently relearned 26 00:02:12,520 --> 00:02:16,039 a lot of stuff about service side rendering, and of course this is a 27 00:02:16,080 --> 00:02:22,599 feature that has been long present in the Angular ecosystem, like the concept itself 28 00:02:22,639 --> 00:02:29,240 with you know, but we have lots of new improvements and yeah, they 29 00:02:29,240 --> 00:02:32,360 were going to touch them a lot. So initially it was like service size 30 00:02:32,400 --> 00:02:37,560 rendering, why would we want it? So when we build like classical Angular 31 00:02:37,560 --> 00:02:45,400 application, what we get is a client side rendered application. So what that 32 00:02:45,560 --> 00:02:49,159 means is that, like in general, when you go to some website, 33 00:02:49,759 --> 00:02:53,199 you would receive a bunch of HTML and probably some JavaScript inside, and the 34 00:02:53,240 --> 00:02:59,080 browser will first render the HTML, and maybe the joscape itself will also render 35 00:02:59,199 --> 00:03:06,240 parts of that page dynamically. So classically we just get some HTML and the 36 00:03:06,280 --> 00:03:13,000 browser will just immediately proceed to painting it, rendering it painting in the viewpoort. 37 00:03:13,199 --> 00:03:21,159 Okay, so that is of course perfectly acceptable. But the community and 38 00:03:21,560 --> 00:03:28,719 all the cool UI people wanted like a mobile application feel in the browser, 39 00:03:29,120 --> 00:03:32,680 and we get it with client side applications, with client side rendering or single 40 00:03:32,719 --> 00:03:38,199 page applications like what we say right, and single page application don't really have 41 00:03:38,360 --> 00:03:43,960 much of HTML. Essentially, you get like an index HTML file that has 42 00:03:44,080 --> 00:03:49,599 reference to a bunch of jazsk files, and then those JavaScript files will render 43 00:03:49,800 --> 00:03:54,240 our UI. So when I say these jazsk files we mean Angular source code. 44 00:03:54,919 --> 00:04:03,479 We mean our own code that we authored in the with the purpose of 45 00:04:03,840 --> 00:04:11,960 rendering some UI and adding some dynamic stuff to it. Okay, So in 46 00:04:12,000 --> 00:04:16,519 that scenario, the jobs coupt will emulate everything that is related to the applications 47 00:04:16,759 --> 00:04:20,120 life. It will render, it will provide routing, so if you click 48 00:04:20,160 --> 00:04:24,279 on a link, you will sort of go to another page but not really 49 00:04:24,319 --> 00:04:28,920 go to another page. What happens is that the content gets replaced and a 50 00:04:28,959 --> 00:04:34,759 special API is used to push this new URL into the browser's history. So 51 00:04:34,800 --> 00:04:40,959 it feels like you are navigating, but in reality you are not going anywhere 52 00:04:40,959 --> 00:04:45,360 in They're not making new HDP requests, downloading the nutl page rerendering and some 53 00:04:46,040 --> 00:04:49,360 and it's a cool thing. It's a really awesome thing. Evidence by the 54 00:04:49,360 --> 00:04:55,759 fact that when single page apps like were created initially everyone was crazy about them. 55 00:04:55,800 --> 00:04:58,759 Always make a single page app with make a single page ap. But 56 00:04:59,399 --> 00:05:03,319 like with any think, it has its own downside. So one huge downside 57 00:05:03,639 --> 00:05:11,360 is the SEO problem, the search engine optimization problem. Essentially like web crawlers 58 00:05:11,519 --> 00:05:15,959 like Google and Being and so on. When when we search on Google, 59 00:05:16,279 --> 00:05:21,600 it has a big database of websites with keywords, so this is found on 60 00:05:21,639 --> 00:05:27,319 those pages and so on. So how they know those pages have that content 61 00:05:27,800 --> 00:05:30,560 is that they use a program it's called like a web crowller that would go 62 00:05:30,639 --> 00:05:35,199 around the web, find new pages and index them into the database. The 63 00:05:35,360 --> 00:05:41,279 problem with web cross is that those webcalls usually are like browsers. They will 64 00:05:41,279 --> 00:05:46,199 get an HTML page and they will record whatever you have on your page. 65 00:05:46,360 --> 00:05:48,319 Okay at indexing then the future, if you have I don't know, a 66 00:05:48,360 --> 00:05:55,199 cooking website, someone searches something related to cooking, your website would probably be 67 00:05:55,639 --> 00:06:00,199 found somewhere in the Google's database. But the thing of page application, as 68 00:06:00,240 --> 00:06:03,360 we mentioned, they deliver only just MPTHTML with some JavaScript, so often web 69 00:06:03,399 --> 00:06:05,639 crawls we just say, oh, you know, this is like an empty 70 00:06:05,680 --> 00:06:13,360 page. So your single page application most probably will not be ranked and indexed 71 00:06:13,399 --> 00:06:16,600 by Google. So yeah, that's a big blow if you are creating a 72 00:06:16,639 --> 00:06:20,839 website that is not like a like not an enterprise solution, but more like 73 00:06:20,879 --> 00:06:27,079 an e commerce or marketing or whatever that you need people that need traffic. 74 00:06:27,079 --> 00:06:30,720 You need people coming to your website. And if people cannot find your website 75 00:06:30,720 --> 00:06:38,600 on Google, your toast right. And so that's just one problem that we 76 00:06:38,680 --> 00:06:42,920 didn't have the server side approach when we had all the HTML. And of 77 00:06:42,959 --> 00:06:47,040 course another problem is the initial page load. So with when you get prepared 78 00:06:47,240 --> 00:06:56,279 HTML file, it's fast rendering it immediately persistent rendered HML. But with client 79 00:06:56,319 --> 00:07:00,240 side rendering we had an MPTHTML file, then you have to down a lot 80 00:07:00,240 --> 00:07:03,560 of bunch of JavaScript. Then that bunch of JOBSRIP needs to be compiled, 81 00:07:03,680 --> 00:07:10,560 and then it needs to run, and then it will start rendering the UI 82 00:07:12,319 --> 00:07:15,319 and again after it has finished rendering. It works way faster and smooth than 83 00:07:15,439 --> 00:07:19,000 service side rendering when you have to like throw away the old page and build 84 00:07:19,000 --> 00:07:24,079 one. But this initial loading process is slow. And for again, for 85 00:07:24,279 --> 00:07:29,680 website that depends on traffic loads that want more users that want clicks, that 86 00:07:29,800 --> 00:07:34,040 want like marketing stuff and so on. Initial page load is a very crucial 87 00:07:34,120 --> 00:07:39,920 metric, Like people don't like websites that load in like five seconds, okay, 88 00:07:40,639 --> 00:07:45,720 And that's pretty understandable. So it went back in the day, Angular 89 00:07:45,800 --> 00:07:51,959 only had spa single page. But I don't exactly remember from when we got 90 00:07:53,000 --> 00:07:59,199 Angular Universal. Angular Universal previous solution for Angular in with service side rendering. 91 00:08:00,120 --> 00:08:07,639 What it meant is that Angular itself is rendering engine. Cannot only run in 92 00:08:07,680 --> 00:08:11,000 the browser, which is understandable for us, Like in the browser, okay, 93 00:08:11,040 --> 00:08:13,439 it uses like document, the ed element, create element, blah blah 94 00:08:13,439 --> 00:08:18,360 blah. It's understandable for us how it works in the browser, but it 95 00:08:18,480 --> 00:08:24,519 also can work on other platforms. It can work on a server like like 96 00:08:24,680 --> 00:08:30,199 a node engine node rendering engine like we have like pug right or stuff like 97 00:08:30,240 --> 00:08:33,720 that. It can work like that. We can tell a node Jazz server, 98 00:08:33,000 --> 00:08:37,240 you know, use Angular to render HTMO pages on the server side. 99 00:08:37,279 --> 00:08:43,879 And it's really possible because when we go to the main ts file, usually 100 00:08:43,879 --> 00:08:50,519 in a classical setup, you will see some imports from Angular slash Platform Browser. 101 00:08:52,399 --> 00:08:58,559 A platform browser contains all the stuff that you need to run your Angular 102 00:08:58,600 --> 00:09:03,600 app in the browser. So if you're building for a browser, then sure, 103 00:09:05,600 --> 00:09:09,960 no problem use Platform browser. But you can also use Platform server and 104 00:09:11,039 --> 00:09:15,960 you can use Angular Universe. So what you could use Angular Universal before v 105 00:09:16,240 --> 00:09:20,799 seventeen. Okay, you can do service side rendering with Angular. You can 106 00:09:20,840 --> 00:09:26,279 have a server like not j just server that would render the pages in the 107 00:09:26,320 --> 00:09:31,480 back end and then serve prepaired content. Okay, so this is essentially what 108 00:09:31,600 --> 00:09:37,000 server said. You rather up the service side, you serve ready HTML and 109 00:09:39,159 --> 00:09:46,200 both your SEO and initial pageload improved significantly. That's what service rendering is in 110 00:09:46,240 --> 00:09:56,440 this context. Okay, Okay, so if we try to summarize and kind 111 00:09:56,440 --> 00:10:03,759 of condense everything, Basically, when you're coding Angular, you have single page 112 00:10:03,799 --> 00:10:09,399 applications which are rendered in the browser, which means that if you inspect the 113 00:10:09,639 --> 00:10:13,480 HML that is being returned from the server. Instead of the old days with 114 00:10:13,840 --> 00:10:18,080 PHP and passion servers, where you would have the HML with all the information, 115 00:10:18,600 --> 00:10:24,240 you only have the HML like referencing script tag, and that script tag 116 00:10:24,360 --> 00:10:30,840 contains everything. So that is a problem for crawlers such as the Google crawler, 117 00:10:30,919 --> 00:10:35,759 because it's harder for them to index your website to understand what content you 118 00:10:35,879 --> 00:10:39,279 have so that they can show you in the search results. So server side 119 00:10:39,279 --> 00:10:46,399 rendering is a way for you to instead of returning this MTHML, you can 120 00:10:46,440 --> 00:10:52,159 make sure that in the initial page load, it already returns all the rendered 121 00:10:52,360 --> 00:11:00,000 HML that the page is going to have, so that both improve improves your 122 00:11:00,200 --> 00:11:07,320 ranking on search engines and it also increases your uh. This increases the speed 123 00:11:07,639 --> 00:11:15,120 of the first the what's the called the first time to render? I forgot 124 00:11:15,200 --> 00:11:20,320 the I know, I guess you refer to time to first bite that that 125 00:11:20,360 --> 00:11:24,799 can also be improved. But with another technique. I think it's like initial 126 00:11:24,799 --> 00:11:31,519 pagelo isn't initial? Yes, that's the one. Yeah, okay, so 127 00:11:31,559 --> 00:11:35,440 these are are the main benefits though, yet, now what are the cones? 128 00:11:35,840 --> 00:11:43,879 U service arren sound school, who should not do it. The interesting 129 00:11:43,039 --> 00:11:50,879 thing about the cones in this scenario is just whatever I say about like, 130 00:11:50,000 --> 00:11:54,639 oh, you know right now this is a downside. It's either a problem 131 00:11:54,720 --> 00:11:58,919 that has been fixed so they don't really have it anymore, in like virgiency 132 00:12:00,000 --> 00:12:03,559 teen or seventeen, or it is something that's going to be addressed anyway. 133 00:12:07,799 --> 00:12:11,480 Okay, let's talk about some things that you need to consider. I wouldn't 134 00:12:11,519 --> 00:12:16,279 exactly call those cons but those are things that you need to be mindful of. 135 00:12:16,720 --> 00:12:20,120 In general, your Angular components will be just rendered on the service side 136 00:12:20,120 --> 00:12:24,679 without a problem. So if you're using just Angular I like using template and 137 00:12:24,799 --> 00:12:31,840 bindings and whatever, you have no problems in that regard. Angler would just 138 00:12:31,840 --> 00:12:37,039 easily render that on the service side, no questions asked. The problem comes 139 00:12:37,080 --> 00:12:45,399 when you sort of try to leave Angular itself inside an Angular app and try 140 00:12:45,440 --> 00:12:50,039 to, for example, manipulate the dom manually. If you say, I 141 00:12:50,080 --> 00:13:01,639 don't know, document query how it's called curry selector and find an element and 142 00:13:01,720 --> 00:13:05,440 maybe change a property, or I don't know, manually remove something, and 143 00:13:05,519 --> 00:13:09,799 that is something that might happen. That is a scenario that I mean, 144 00:13:11,000 --> 00:13:15,960 Angler is great, but sometimes you want to manually do something with the I 145 00:13:16,000 --> 00:13:20,240 mean virtual scrolling, whatever might. You might need to do that anyway. 146 00:13:20,480 --> 00:13:26,279 It's not a very popular scenario, but it isn't unheard of either. So 147 00:13:26,320 --> 00:13:30,200 the problem is if you start coding like that, if you reference window, 148 00:13:30,320 --> 00:13:33,159 if you reference document and so on in your code, well that's not going 149 00:13:33,200 --> 00:13:39,279 to work on the server. Server doesn't have a document object. It's a 150 00:13:39,360 --> 00:13:45,039 server. It's not a web browser document and window and navigator history and so 151 00:13:45,120 --> 00:13:52,360 on. Those BOM or dome APIs they only exist in a browser. Like 152 00:13:52,559 --> 00:13:54,679 you couldn't access, for example, file system in the browser, right, 153 00:13:54,679 --> 00:13:58,960 it's not jazz thing. So the same goals the other way. You cannot 154 00:13:58,960 --> 00:14:03,759 access DOM because what don't there is no document object model on the server side. 155 00:14:03,919 --> 00:14:05,559 So if you have to do this manipulation, it can get kind of 156 00:14:05,600 --> 00:14:09,039 tricky depending on what you're trying to do. Well, it used to get 157 00:14:09,120 --> 00:14:18,320 kind of tricky until version sixteen because now the problem was that you usually put 158 00:14:18,360 --> 00:14:22,919 that sort of code in life cycle hooks. Okay, because if you put 159 00:14:22,960 --> 00:14:28,559 that code in some method and then call it that method only when the user 160 00:14:28,600 --> 00:14:33,080 clicks on a button, for example, then you're guaranteed that that code will 161 00:14:33,159 --> 00:14:37,879 run only in the browser. Right, So okay, that sort of code 162 00:14:37,919 --> 00:14:41,799 wasn't the problem even previously. But what if you want to do that manipulation, 163 00:14:41,879 --> 00:14:46,600 for example, when the component starts rendering like engelining it. The problem 164 00:14:46,679 --> 00:14:50,720 with anginet is that it's gonna also run on the server side, okay, 165 00:14:52,559 --> 00:14:54,440 and on the server side you're going to get an error saying a document is 166 00:14:54,480 --> 00:15:00,120 not defined. Like what are you talking about now? Starting from angle or 167 00:15:00,200 --> 00:15:07,000 V sixteen, we have two methods after render and after next render. Well, 168 00:15:07,039 --> 00:15:11,840 not exactly method they are just functions which can take callback, and those 169 00:15:11,919 --> 00:15:22,080 functions guarantee that the collbeck only runs on the client side. Okay. You 170 00:15:22,120 --> 00:15:28,080 can just put those functions in the constructor and provide any callback and you're guaranteed 171 00:15:28,480 --> 00:15:31,200 the cobeck will only work in the browser. So now you're actually okay, 172 00:15:31,240 --> 00:15:35,159 this code only client side, and after next render works only once, and 173 00:15:35,279 --> 00:15:41,360 after render works after every rendering cycle. Okay. Essentially, in the end 174 00:15:41,399 --> 00:15:45,759 of the day, they're just a mild different behavior, but they they're the 175 00:15:45,799 --> 00:15:48,759 same. They provide you with the capability to clearly say, oh, you 176 00:15:48,799 --> 00:15:54,320 know, this code is gonna work only in the browser. So that's probably 177 00:15:54,360 --> 00:16:00,120 the main problem that people encountered with, you know, service side rendering when 178 00:16:00,159 --> 00:16:03,600 they wanted to do manual no manipulations and so on, And of course it 179 00:16:03,679 --> 00:16:07,679 has a bit of a learning curve, but it's not that hard, like 180 00:16:07,759 --> 00:16:11,919 you don't add lots of overhead your projects for that s. Everything works as 181 00:16:12,000 --> 00:16:18,279 it used to. You just gotta be careful about the client side versus service 182 00:16:18,360 --> 00:16:21,200 side thing. And now we got us covered. And the good news is 183 00:16:21,200 --> 00:16:25,120 in Angular seventeen, those two functions are now stable, so feel free to 184 00:16:25,200 --> 00:16:33,159 use them if you're doing sssor and Angular seventeen. Yep. Another count is 185 00:16:33,960 --> 00:16:41,039 that you're putting more load in your server which is serving the front. So 186 00:16:41,080 --> 00:16:47,919 right now, if your server is just sending out static files, then that 187 00:16:48,080 --> 00:16:52,240 is so much easier, like the server can just cash that and return it 188 00:16:52,440 --> 00:16:59,120 kind of immediately. But if you're trying to do server side rendering on the 189 00:16:59,200 --> 00:17:04,079 spot so that means dynamics service are rendering, then once you make a request, 190 00:17:04,319 --> 00:17:10,279 the server will have to render the entire page before returning it. So 191 00:17:10,440 --> 00:17:17,559 all the work that the client's browser would have to do to paint the page. 192 00:17:17,640 --> 00:17:21,720 Initially, this will be done in the server before it gets returned, 193 00:17:22,200 --> 00:17:26,839 so that might decrease. Well, it's definitely going to decrease the amount of 194 00:17:27,000 --> 00:17:33,519 requests per second that your front end server can return to clients. The good 195 00:17:33,519 --> 00:17:38,039 thing is that since all those things they are stateless, you can just have 196 00:17:38,160 --> 00:17:44,119 more of those servers running in parallel and put a load balancer in front of 197 00:17:44,160 --> 00:17:48,039 them, so it's not really a scalability problem. But if you have like 198 00:17:48,079 --> 00:17:52,599 a lot of users requesting your website at the same time, then you're going 199 00:17:52,680 --> 00:17:57,880 to have to think about cashing those pages, catching the rendered pages, or 200 00:17:59,160 --> 00:18:04,119 deciding if you want to really server side render all of the pages are just 201 00:18:04,200 --> 00:18:08,680 some of them. Maybe you can like pre render like the homepage or something 202 00:18:08,720 --> 00:18:11,680 like that, and then you can serve that, but the rest can just 203 00:18:11,799 --> 00:18:17,680 serve it and let the client render in the front end, so you can 204 00:18:17,799 --> 00:18:22,599 have a fine grain control if you choose so. But yeah, it's definitely 205 00:18:22,599 --> 00:18:30,920 gonna your server is definitely gonna take a hit. It's it's really awesome that 206 00:18:30,000 --> 00:18:36,039 you would mention that, because especially pre rendering, because the funny thing is 207 00:18:36,079 --> 00:18:41,240 that in Angular seventeen, well, now Angular universal is Gonne. We have 208 00:18:41,880 --> 00:18:49,599 a package called Angular slash SSR built in, and with Angular SSR we have 209 00:18:49,799 --> 00:18:56,680 pre rendering websgy sthetic side generation, and we have this pre rendering by default. 210 00:18:56,039 --> 00:19:03,039 Actually the default option is pre rendering. So what happens there is that 211 00:19:03,160 --> 00:19:07,759 when you build your application. I'm not talking about like serving it on a 212 00:19:07,839 --> 00:19:12,480 server where when you run an engine build, what angular SSR would do is 213 00:19:12,519 --> 00:19:18,799 it would go through your routing, find all the pages that are not parameterized, 214 00:19:18,960 --> 00:19:22,880 So all the routes that don't have like pas parameters. Okay, not 215 00:19:23,000 --> 00:19:27,400 the paths that have like slash id or what happened, just casual paths and 216 00:19:29,400 --> 00:19:33,680 pre render those pages. Okay, you can pre render those pages, and 217 00:19:34,240 --> 00:19:37,079 that agetme. Like if you have a homepage. You mentioned a great example. 218 00:19:37,240 --> 00:19:41,440 A homepage usually like looks the same, okay, and even if there 219 00:19:41,440 --> 00:19:45,759 are whatever differences, we can for example resolve them on the clients. We 220 00:19:45,920 --> 00:19:48,440 just want to serve the page immediately. Well, now you can have the 221 00:19:48,920 --> 00:19:55,200 homepage pre rendered. Even better than this if you have like a limited set 222 00:19:55,240 --> 00:20:00,240 of collections, like you have a parameterized route, okay, but you know 223 00:20:00,440 --> 00:20:04,920 that those parameters are predetermined, so not like a user idea that could be 224 00:20:06,000 --> 00:20:10,079 anything and you could have any number of users. But no, like you 225 00:20:10,160 --> 00:20:14,680 have some options that there are like four types of this parameter. You can 226 00:20:14,680 --> 00:20:18,599 have a category of blog. Yeah, exactly, like you have a I 227 00:20:18,640 --> 00:20:22,279 don't know a web store, and you have a category of I don't know 228 00:20:22,400 --> 00:20:26,799 closing items for example, and you know all your categories, you have like 229 00:20:26,839 --> 00:20:30,799 twenty two of them. Okay, you can just create a routes dot txt 230 00:20:30,960 --> 00:20:34,599 file and put all the available options there and Angular will now go and say, 231 00:20:34,599 --> 00:20:40,680 okay, I can now discover these route I can now pre render them, 232 00:20:40,920 --> 00:20:44,559 render the page for this category, that category, that category, whatever 233 00:20:44,759 --> 00:20:48,200 your parameter is, and pre rendering is actually by default so you don't even 234 00:20:48,200 --> 00:20:52,759 need to worry about it. You can if you build a static website, 235 00:20:52,799 --> 00:20:56,880 like if you're building a personal website, you can just SSG your application. 236 00:20:56,000 --> 00:21:00,720 You can just add angerssr build your app like usual Angler app, and then 237 00:21:00,799 --> 00:21:04,119 run engine build. Okay, you have a in the disc folder, You're 238 00:21:04,119 --> 00:21:08,440 gonna have a browser directory, and we'll just have all the stuff that you 239 00:21:08,480 --> 00:21:17,119 need to put in the server to serve for the potential clients. And this 240 00:21:17,319 --> 00:21:22,720 is really awesome because it solves all the problems that we kind of have with 241 00:21:23,079 --> 00:21:30,000 Like, look if we again with the clients side rendering. Obviously, yeah, 242 00:21:30,039 --> 00:21:36,960 server is only serving like static HTML that will now want the client resolves 243 00:21:37,039 --> 00:21:42,319 blah blah blah and do everything on the client. But your server is probably 244 00:21:44,240 --> 00:21:52,839 a more capable computer than whatever your users are running. Right, So if 245 00:21:52,880 --> 00:21:59,759 you free render, if you do all the optimizations and now only that really 246 00:22:00,240 --> 00:22:04,160 mixed stuff is left to render, as you said on Spot, then you 247 00:22:04,240 --> 00:22:08,920 have got yourself a very cool peal like your serve isn't gonna suffer dead much. 248 00:22:11,119 --> 00:22:17,200 Yeah, and again that also has some caveats. For example, if 249 00:22:17,240 --> 00:22:23,839 you pre render and you just return the cached pre rendered assets, then you 250 00:22:25,039 --> 00:22:33,039 can't serve different For example, okay, homepage, let's pre render that. 251 00:22:33,119 --> 00:22:37,200 Okay, but what if this homepage shows a widget that is specific to the 252 00:22:37,240 --> 00:22:44,559 authenticated user. Then you can't really do that because you're pre rendered. It's 253 00:22:44,599 --> 00:22:48,799 gonna it's gonna be like an unauthenticated pre rendered version of the page. So 254 00:22:49,599 --> 00:22:56,759 if you if you have major differences in case the users are authenticated or not, 255 00:22:56,400 --> 00:23:02,640 then you're definitely gonna still have to rely on that rendering. Uh, 256 00:23:03,359 --> 00:23:07,319 interesting that like each caveat you say, we just move one step to the 257 00:23:07,359 --> 00:23:12,279 next improvement to hav in SSR, we resolve that problem with the client side, 258 00:23:12,319 --> 00:23:19,240 and specifically client side hydration, and it's now way cheaper to solve that 259 00:23:19,480 --> 00:23:26,960 problem. Essentially, what like what you're saying is that obviously on the server 260 00:23:27,079 --> 00:23:34,079 we cannot render authenticating content right for example, well, who knows if the 261 00:23:34,200 --> 00:23:40,200 user is authenticated or not. What we can do we can use a combination 262 00:23:40,440 --> 00:23:45,200 of the functions that I mentioned. We could use a buoy and flag and 263 00:23:45,839 --> 00:23:49,960 only check for that stuff on the client side. Then we can use pre 264 00:23:49,960 --> 00:23:55,119 render to pre render the static parts of the page. And then on the 265 00:23:55,160 --> 00:24:03,400 client side we gotta we gotta enjoy the benefits of client side hydration, Okay, 266 00:24:03,400 --> 00:24:07,680 and we can be sure that this problem is going to be resolved as 267 00:24:07,759 --> 00:24:15,440 fast as possible. In the context of you know, miss a whole client 268 00:24:15,519 --> 00:24:22,400 side re rendering process, I feel like we need to start clarifying what client 269 00:24:22,400 --> 00:24:30,640 side adoration is. So the thing with like the main problem actually that we 270 00:24:30,720 --> 00:24:37,200 didn't touch that existed previously with SSR in Angular. What's the following So even 271 00:24:37,240 --> 00:24:42,039 if you build a server side application when the client gets the page, we 272 00:24:42,200 --> 00:24:47,519 still want them to enjoy all the benefits of client side Angular. We want 273 00:24:47,559 --> 00:24:51,519 the dynamic page. We want like if you click on the bottom, we 274 00:24:51,559 --> 00:24:55,119 want to pop up to come up, and the dialogues to works, and 275 00:24:55,200 --> 00:24:59,160 the single page navigation to work, and so on and so on and so 276 00:24:56,759 --> 00:25:03,680 on. So the thing is it wasn't really possible previous like it worked, 277 00:25:03,759 --> 00:25:08,279 but the way it worked wasn't very good. So what would happen is like 278 00:25:08,319 --> 00:25:14,440 if you have a client set application purely single pay job. What happens is 279 00:25:14,440 --> 00:25:18,160 that your templates that you create, they get translated to some JavaScript code that 280 00:25:18,240 --> 00:25:26,319 an Angle uses to actually render this UI that you have. And Angular checks 281 00:25:26,319 --> 00:25:30,480 for bindings. So we have bindings in our code, like we bind some 282 00:25:30,559 --> 00:25:38,599 HTML element properties to our class properties, like in components we do text interpolation 283 00:25:41,000 --> 00:25:42,839 and so on. There are different we do event bindings and so on and 284 00:25:42,880 --> 00:25:48,440 some. So when Angular on the client does the rendering, the bindings are 285 00:25:48,480 --> 00:25:52,079 really easy. We can just imagine that every time it encounters a binding in 286 00:25:52,119 --> 00:25:57,799 your let's say template, the JavaScript that got translated from a template. If 287 00:25:57,799 --> 00:26:02,599 all just let's say, I'm just saying it as an example. It's not 288 00:26:02,720 --> 00:26:04,880 exactly how it works, but let's say it just keeps the reference to this 289 00:26:06,000 --> 00:26:08,480 binding in an array. So next it can just go through that array and 290 00:26:08,559 --> 00:26:12,000 see, oh, okay, this binding changed, I need to show new 291 00:26:12,119 --> 00:26:17,480 UI. And that's how Angler is dynamic change detection and so on. And 292 00:26:17,519 --> 00:26:22,359 that again is easy because Angler already is rendering those dome elements in a browser. 293 00:26:23,039 --> 00:26:26,759 Okay, so it will just take the reference to the dom elements and 294 00:26:26,799 --> 00:26:30,079 say, okay, here's a binding. I will update this domb element when 295 00:26:30,519 --> 00:26:33,759 blah blah blah, something happens. But it's service side rendering. You've got 296 00:26:33,799 --> 00:26:38,039 to resolve a problem. You already have all those dom elements. Okay. 297 00:26:38,599 --> 00:26:42,079 So Angler is not rendering anything on the client side, So how is it 298 00:26:42,119 --> 00:26:45,440 going to bind to all the stuff? And now, okay, that button 299 00:26:45,480 --> 00:26:52,400 has an event listener. I've got to listen to its quick event. So 300 00:26:52,759 --> 00:26:59,440 turn it out. It couldn't so in order for the bindings to work, 301 00:27:00,279 --> 00:27:04,279 what would happen previously, prior to Angular v sixteen, what would happen is 302 00:27:04,319 --> 00:27:10,359 your application HTML would come from the server rendered. Okay, you have nice 303 00:27:10,640 --> 00:27:17,880 SEO, you have nice initial page load. But now Angular on the client 304 00:27:17,960 --> 00:27:22,519 side will be download the Angular code itself, and then it will just demolish 305 00:27:22,599 --> 00:27:30,039 the page essentially under the hood, and re render it again from scratch as 306 00:27:30,079 --> 00:27:36,400 it would in the client side scenario. Of course, it had optimization and 307 00:27:36,440 --> 00:27:40,720 so it wasn't that bad, but it still wasn't like the optimal scenario, 308 00:27:40,920 --> 00:27:45,039 like you have the HTML prepared, why would you want to throw it away 309 00:27:45,119 --> 00:27:51,799 and rerender it again now on the client side, And it of course worsened 310 00:27:52,039 --> 00:27:56,640 some other metrics like time to interact it. You would still wait for jaoship 311 00:27:56,720 --> 00:28:03,079 code to download. After that, you would wait for it to compile. 312 00:28:03,480 --> 00:28:08,119 You would wait for it to demolish the page, build it again and all 313 00:28:08,160 --> 00:28:14,400 the bindings and now it's interactive. So those other metrics improved, but these 314 00:28:14,440 --> 00:28:21,880 metrics actually got worse with what our setup with previously. So for that reason 315 00:28:22,319 --> 00:28:27,079 we now have what is called client side hydration. So what hydration does is 316 00:28:27,240 --> 00:28:33,319 essentially, instead of throwing away your application dome that you got from the server, 317 00:28:33,000 --> 00:28:38,799 there is a process that Angular uses. If it says that okay, 318 00:28:38,880 --> 00:28:44,960 I'm going to hydrate instead of throwing it away and re rendering it, will 319 00:28:45,440 --> 00:28:52,319 discover the bindings inside this template, I mean tablet inside the HTML, the 320 00:28:52,359 --> 00:28:56,799 prepared HTML that you got from the server. It will find the bindings and 321 00:28:56,160 --> 00:29:03,880 lagged onto it and continue working as if it had rendered those domb elements. 322 00:29:03,960 --> 00:29:08,680 Okay, and that's actually really cool thing. And the most awesome thing is 323 00:29:08,720 --> 00:29:12,519 that, like to enable it, you just need to add provide client hydration 324 00:29:14,119 --> 00:29:18,400 in your main ts file and that's it. You don't need to do anything 325 00:29:18,599 --> 00:29:23,880 like literally, you just add provide client side adoration and it works. And 326 00:29:23,920 --> 00:29:29,119 the good news is from Angular v seventeen, client addation is stable, so 327 00:29:29,160 --> 00:29:33,480 again feel free to use it in your production code. Basis API is not 328 00:29:33,559 --> 00:29:41,599 going to change anymore. So yeah, that's a really awesome addition because now 329 00:29:41,279 --> 00:29:45,559 not only you have the benefit of server side, but you have also like 330 00:29:47,039 --> 00:29:52,400 very decent time to interactive metric, very decent largest content FORUL paint metrics. 331 00:29:52,640 --> 00:29:56,799 So you're not gonna show pig image and throw it away. We render it 332 00:29:56,880 --> 00:30:00,240 again, show the pig image and in a case so like heavy website that 333 00:30:00,400 --> 00:30:06,960 have some flickering and whatever, all those problems are sold the plandside aderation and 334 00:30:07,160 --> 00:30:12,559 it goes even further right because it's not just reusing the ATML elements that were 335 00:30:12,640 --> 00:30:18,240 already there when the application was bootstrapped. Is more than that, it's also 336 00:30:18,519 --> 00:30:26,880 reusing the attP requests that were made in the server when it was being rendered 337 00:30:26,960 --> 00:30:33,359 on the server. So there's actually a way for us to enable attP caching. 338 00:30:33,440 --> 00:30:37,839 I think it's much easier now, but in previous versions, if you're 339 00:30:37,839 --> 00:30:42,640 still on previous versions, there's a state transfer module I think that's what it 340 00:30:42,839 --> 00:30:48,799 called. And basically what this does is it transfers the data that was made 341 00:30:49,559 --> 00:30:56,400 during the requests made in the service I rendering process into the front end so 342 00:30:56,559 --> 00:31:00,680 that when the front and loads, it can reuse the data that you the 343 00:31:00,799 --> 00:31:07,319 server got from these requests, so that the front end doesn't have to remake 344 00:31:07,480 --> 00:31:11,039 those requests because they were already done when it was being rendered on the server 345 00:31:11,200 --> 00:31:18,000 side. So yeah, that's basically like one step further into the hydration because 346 00:31:18,039 --> 00:31:25,119 it also kind of hydrates even the data itself, not just the snapshot of 347 00:31:25,279 --> 00:31:30,079 the elements. It's actually not even an option, like if you enable clients 348 00:31:30,119 --> 00:31:36,759 a client side hydration, you get HDP transfer cache by default. Actually, 349 00:31:36,759 --> 00:31:40,599 if you don't want it, you have to manually add like no cash. 350 00:31:41,400 --> 00:31:45,680 There is a weed transfer options function that you can add to your provide, 351 00:31:45,799 --> 00:31:53,559 provide clans, set hydration. Actually they're so like niche but really cool features. 352 00:31:55,279 --> 00:32:04,319 Pretty cool options there. For instance, you can you can add well 353 00:32:04,599 --> 00:32:13,759 by default it only catches get and options requests, right, So it makes 354 00:32:13,799 --> 00:32:17,039 sense because usually you make post requests, the lead requests and so on. 355 00:32:17,240 --> 00:32:22,319 You make those types of requests to modified data in the database, not to 356 00:32:22,480 --> 00:32:29,279 change something in your HTML. And it's the requests that are kind of the 357 00:32:29,400 --> 00:32:32,640 ones that are impacting your UI. But you if you are in a scenario 358 00:32:32,839 --> 00:32:39,319 we're using a post request to a post method request to get data actually, 359 00:32:39,920 --> 00:32:45,359 which is a scenario which feels odd but happens way more often than we might 360 00:32:45,480 --> 00:32:49,680 think. One reason, by the way for that is that if you're using 361 00:32:49,759 --> 00:32:52,759 query parameters, query parameters are limited in size, so if you have too 362 00:32:52,880 --> 00:32:58,119 many parameters for a get request, you just kind of have to convert into 363 00:32:58,240 --> 00:33:01,400 post requests instead of full body. So if you're in this scenario, you 364 00:33:01,480 --> 00:33:07,599 can just add cash HTP for how it called me. Yeah, you can. 365 00:33:08,319 --> 00:33:14,279 You can add the include post requests option. Just make it true and 366 00:33:14,440 --> 00:33:19,200 it will going to cash post requests. On top of that, the headers 367 00:33:19,279 --> 00:33:22,480 are not cased by default, but if you need the headers. Okay, 368 00:33:23,000 --> 00:33:28,960 I can see that Arman is having some connection issues. But yeah, let 369 00:33:29,000 --> 00:33:35,480 me just summarize this and try to bring another way to fixate this knowledge in 370 00:33:35,559 --> 00:33:43,559 your minds. So basically, hydration is imagine that your application is literally in 371 00:33:43,720 --> 00:33:49,079 the desert. Okay, so when you do servers are rendering, and you 372 00:33:49,279 --> 00:33:59,240 return all that already rendered HML to the client, all that all that HML 373 00:33:59,680 --> 00:34:07,200 is not not interactive yet, like it's not listening and handling client interactions. 374 00:34:07,839 --> 00:34:12,760 For example, let's say that you render from the server and then you return 375 00:34:12,840 --> 00:34:15,039 a buttom, if you try to click on the bottom, it's not going 376 00:34:15,119 --> 00:34:20,840 to do anything because the bottom element is being rendered, but it doesn't have 377 00:34:21,360 --> 00:34:28,679 a click event listener attached to it. So it's almost as if you have 378 00:34:28,960 --> 00:34:32,079 all the structures, but they are dead, almost as if they are dry. 379 00:34:32,400 --> 00:34:37,760 They are dehydrated, okay, and then the hydration process is kind of 380 00:34:37,840 --> 00:34:44,239 like bringing that back to life. So in the hydration process, you will 381 00:34:44,719 --> 00:34:47,559 it's almost as if you have a lot of plants and they're like super dry, 382 00:34:47,679 --> 00:34:52,559 and then you water them and they come back to life. So that's 383 00:34:52,599 --> 00:35:00,800 what Angler is doing, instead of of cutting down everything that is there and 384 00:35:00,840 --> 00:35:07,880 recreating everything, is keeping those structures there and just bringing them back to life, 385 00:35:08,519 --> 00:35:15,840 re adding the event listeners to them so that they can become so that 386 00:35:15,960 --> 00:35:22,679 they can become interactive again. So this is what client side hydration does. 387 00:35:22,199 --> 00:35:30,199 And then another benefit that we get from Angular specifically is that it not only 388 00:35:30,480 --> 00:35:35,719 hydrates the elements, meaning that you don't have to the browser doesn't have to 389 00:35:35,840 --> 00:35:40,920 recreate those elements, so it's faster, but it also caches all the attP 390 00:35:42,360 --> 00:35:50,079 responses not all, sorry, by default, it catches the get request responses 391 00:35:50,199 --> 00:35:55,599 that the server got during the server side rendering process and it transfers them to 392 00:35:55,760 --> 00:35:59,960 the front end so that the front end doesn't have to make those requests again. 393 00:36:00,599 --> 00:36:07,880 So this is what client side hydration does. And well, I think 394 00:36:07,920 --> 00:36:16,559 we can actually start wrapping up from here because most of the major points that 395 00:36:16,719 --> 00:36:21,880 we needed to cover in terms of service side rendering specifically with Angler, were 396 00:36:21,920 --> 00:36:28,000 already covered. So I don't think there's much else that we can go in 397 00:36:28,199 --> 00:36:32,119 here. But yeah, in general, so oh and Armen is back. 398 00:36:32,199 --> 00:36:37,760 But yeah, I was just trying to summarize everything that we discussed and try 399 00:36:37,800 --> 00:36:43,880 to give everyone kind of a guideline as to how to choose if they're going 400 00:36:43,960 --> 00:36:47,800 to implement service I rendering their applications or not. As Arman said, implementing 401 00:36:47,840 --> 00:36:53,800 service rendering has become much easier than it used to be, but it's still 402 00:36:54,960 --> 00:37:00,400 not a super easy process, and it's very important, for example, that 403 00:37:00,480 --> 00:37:02,519 the libraries that you're using, if you're using third party libraries, that they 404 00:37:06,079 --> 00:37:09,000 were made so that they can work in the browser and also on the server. 405 00:37:09,440 --> 00:37:14,880 Otherwise, if the libraries that you're relying on are trying to access browser 406 00:37:14,920 --> 00:37:20,119 APIs such as the Window Document, etc. Then they're going to fail and 407 00:37:20,199 --> 00:37:22,920 you won't be able to service side render. So if you're starting an application 408 00:37:23,039 --> 00:37:29,320 from scratch, I would recommend to enable it just because you get some performance 409 00:37:29,400 --> 00:37:36,800 benefits and then you already start with the most strict setting possible. But if 410 00:37:36,880 --> 00:37:40,239 you already have a big enough obligation that is not doing service side rendering, 411 00:37:40,719 --> 00:37:46,000 it's definitely not a very trivial process to convert to it. Unfortunately. I 412 00:37:46,119 --> 00:37:50,440 mean, to set up the initial structure is pretty easy, but to make 413 00:37:50,480 --> 00:37:57,400 sure that your entire code based works on the server. It's not that easy 414 00:37:57,519 --> 00:38:01,719 because maybe we're talking about years of developers working in the SCO based without having 415 00:38:01,800 --> 00:38:07,639 to worry about wrapping around their calls to document in window APIs, which, 416 00:38:07,719 --> 00:38:10,840 by the way, you can't access. That's one important distinction that I don't 417 00:38:10,840 --> 00:38:15,440 think we made ARMEN. You can still access the document the window, et 418 00:38:15,519 --> 00:38:21,880 cetera. You just first you either do it in the way that I would 419 00:38:22,000 --> 00:38:25,880 recommend as a best practice, which is you can inject the document from Angular 420 00:38:27,000 --> 00:38:30,119 Core and that way, if you're on the server side, then you're going 421 00:38:30,199 --> 00:38:38,239 to get not like the native browser document, but an object that simulates the 422 00:38:38,320 --> 00:38:44,760 document on the server. Or if you really only want to access it in 423 00:38:44,880 --> 00:38:47,639 the browser and you don't care about accessing it in the server, then you 424 00:38:47,719 --> 00:38:53,000 can either use the life cycle hoops the arm discussed the Armen mentioned before, 425 00:38:53,199 --> 00:38:58,960 or you can inject the platform i D. So in your constructor you can 426 00:38:59,039 --> 00:39:04,599 inject the platform and then you can call function from angler which is platform browser 427 00:39:04,880 --> 00:39:07,119 and you pass the platform i D and then if you're running on the browser 428 00:39:07,239 --> 00:39:10,320 is going to return true. So you can just wrap it in this if 429 00:39:10,480 --> 00:39:15,840 statement and then you can own you can have part of your code that is 430 00:39:15,920 --> 00:39:22,599 only going to run in the browser. So that's that's actually very common to 431 00:39:22,760 --> 00:39:25,679 be done, even if you're doing service are rendering, because there are things 432 00:39:25,719 --> 00:39:30,039 that you only want to do in the browser. For example, I have 433 00:39:30,360 --> 00:39:34,840 four or four pages that they have a timer to redirect the user to the 434 00:39:34,880 --> 00:39:37,000 homepage. So you go to the four or four page and then it has 435 00:39:37,119 --> 00:39:40,679 like a ten second timer and it shows, hey, we'll redirect you to 436 00:39:40,760 --> 00:39:45,679 the home in ten nine. Hey I can't do that on the server because 437 00:39:45,880 --> 00:39:51,119 if I do, every request takes ten seconds because it's like waiting for your 438 00:39:51,119 --> 00:39:54,440 observable to end, and then it always returns the homepage instead of the four 439 00:39:54,519 --> 00:39:58,960 or four So that's the kind of thing that you want to only run in 440 00:39:59,079 --> 00:40:05,519 the browser. So you can always do those things, but it's definitely something 441 00:40:05,599 --> 00:40:08,320 else that you have to keep in mind, and it also increases a bit 442 00:40:08,400 --> 00:40:13,960 the complexity and understanding of your cod base by the other developers. So it's 443 00:40:14,039 --> 00:40:21,880 definitely not a trade off that we can easily discard. I think it needs 444 00:40:21,920 --> 00:40:29,199 to be to be considered, but I would definitely recommend service side rendering your 445 00:40:29,239 --> 00:40:34,400 applications if possible. I think the same. Actually, if you are, 446 00:40:37,039 --> 00:40:43,559 especially if you're working on your own product, it always could be beneficial to 447 00:40:44,079 --> 00:40:49,679 keep service rendering in mind. I mean, obviously, if you know that 448 00:40:49,800 --> 00:40:54,280 the solution is not intended for public cues, if you don't really care about 449 00:40:54,320 --> 00:40:59,840 the metrics, then probably you don't need to worry about it. The cool 450 00:41:00,000 --> 00:41:04,679 think is just now also easy to add services side rendering to an existing project. 451 00:41:05,159 --> 00:41:07,159 Well, in the sense that you can't just run a JADA and your 452 00:41:07,239 --> 00:41:12,559 RECESSR. It will generate the stututnit service side. Then you can sort of 453 00:41:12,760 --> 00:41:22,159 address the things that you need maybe to change or migrate a bit to work 454 00:41:22,679 --> 00:41:27,000 better with as a star I guess scenario you mentioned. Of course, it's 455 00:41:27,000 --> 00:41:31,239 always gonna have problems in some part of your application. You probably have something 456 00:41:31,320 --> 00:41:36,679 that isn't really tailored to work on the service side, so you've gotta be 457 00:41:36,760 --> 00:41:39,440 careful about that. But the process of adding and then getting to the actual 458 00:41:39,519 --> 00:41:45,480 starbut F is quite easy now. Yeah, yep, I agree. Okay, 459 00:41:46,599 --> 00:41:52,119 I think that that Arman. Do you think there's anything else that we 460 00:41:52,239 --> 00:41:58,039 need to cover before we finish this episode? I would just mention, uh, 461 00:41:58,800 --> 00:42:04,320 the other things that probably are on the horizon for clients for SSR in 462 00:42:04,440 --> 00:42:12,519 general. So the client side hydration that we mentioned is a full hydration, 463 00:42:12,920 --> 00:42:16,639 So the entire app that you have, all the bindings are going to get 464 00:42:16,719 --> 00:42:22,760 rehydrated, which isn't bad, it makes sense, but you could get even 465 00:42:22,960 --> 00:42:28,639 better time to interactive metric if you do like partial hydration, for example, 466 00:42:29,039 --> 00:42:32,320 hydrate only the bindings that are in the viewpoint and continue hydrating in rest and 467 00:42:32,440 --> 00:42:38,039 stuff in some other scenario strategy. And probably I'm not I'm not sure when 468 00:42:38,239 --> 00:42:44,079 or how, but it is possible. It's probably a goal of the team 469 00:42:44,119 --> 00:42:49,400 that is working on the SSR package to get us also partial client side hydration, 470 00:42:49,559 --> 00:42:54,159 and I will be going to further improvement in all of this SSR thing. 471 00:42:54,519 --> 00:43:01,840 Yep, that's really interesting. Okay, all right, let's go into 472 00:43:02,079 --> 00:43:07,199 promos. So my promo is just going to be Onvoid, so it's u 473 00:43:07,400 --> 00:43:14,559 N void dot com. If you're interested in staff augmentation or just fully outsourcing 474 00:43:14,639 --> 00:43:17,920 our project, Void can do that in a performance basis, So clients are 475 00:43:19,000 --> 00:43:23,800 only going to pay after the tasks are delivered and approved. So if you 476 00:43:23,920 --> 00:43:29,559 don't appreciate the quality of the work that was delivered, you don't have to 477 00:43:29,679 --> 00:43:36,119 pay, so you're completely protected as a client, which means that they're actually 478 00:43:36,199 --> 00:43:39,760 going to deliver that because if they weren't going to be able to delivered a 479 00:43:39,880 --> 00:43:45,239 good quality, why would they offer that guarantee? Right, So yeah, 480 00:43:45,239 --> 00:43:49,679 if you're interested in that, go check out Void dot com, U n 481 00:43:49,920 --> 00:43:54,119 v O I D dot com. How about you, Arman. I think 482 00:43:54,400 --> 00:43:57,920 in a week or two, I'm going to have a pretty big announcement, 483 00:43:58,440 --> 00:44:04,719 especially for people who listened to this podcast and are stuck on some earlier Angular 484 00:44:04,880 --> 00:44:08,599 versions. I wonder how to upgrad what new stuff is going on Angular. 485 00:44:09,079 --> 00:44:15,199 There is some cool stuff that is coming your way and I'm gonna I'm gonna 486 00:44:15,280 --> 00:44:19,880 have a link to that great stuff and after that I will make the announcement. 487 00:44:20,519 --> 00:44:24,559 So hopefully maybe next week or the other one. But it's a pretty 488 00:44:24,599 --> 00:44:30,920 big thing, so you know, stay tuned. Nice, Nice, I've 489 00:44:30,960 --> 00:44:35,320 been waiting for that for a while. Okay, I want to break the 490 00:44:35,400 --> 00:44:39,239 news to everyone. Okay, okay, y wait a little bit longer, 491 00:44:39,400 --> 00:44:44,920 Armen. Okay, again, thank you so much for being on the show, 492 00:44:45,000 --> 00:44:47,000 Man. I appreciate every time that you can join. You always bring 493 00:44:47,079 --> 00:44:53,119 a lot of a lot of content for us. Yeah, it's always great 494 00:44:53,119 --> 00:44:57,079 to have you on the show. Oh, no words, It is always 495 00:44:57,119 --> 00:45:01,760 a pleasure, all right, Thanks everyone and until the next one.