Wrapping Up

[00:00:00]
>> It's no question at all. I'm a fan of NgRx. But do I have any alternate recommendations for maybe a smaller team? I've heard good things about Akita. I think, philosophically, it's a little bit different, but the idea is the same. I also believe that if you understand how Redux works, it's a very, very simple pattern that you can create your own version of it in about 15 minutes.

[00:00:37]
And I've done it. Look, if I was doing a service with a subject, it would very quickly turn into just a version of NgRx. And so, I would say off the top of my head, I think Akita is really the other kind of major player. One thing that's interesting to me, and this is more on the react side, but state machine.

[00:01:00]
And there's some really interesting things around state management via the state machine, and I know Frontend Masters, we've had a couple of workshops around that.
>> Yeah, we have up here at State 1, which works across all frameworks.
>> Yeah, so, I would also say if you're looking to experiment, check out the X state project and there is a, conveniently, a workshop on that in Frontend Masters.

[00:01:31]
So, to me, that's pretty compelling. I believe the question is that, is it appropriate to use the service with a subject in the current architecture, which I presume is what we've been talking about all day? And if that is the question, then I'm prepared to answer it. Service with a subject is, I believe, it is a solution that works at a certain scale.

[00:02:00]
Once you start to increase your application in terms of complexity, size, moving pieces, that pattern would just fall down. It will become unwieldy. And even the individuals that I know that are really pro service with a subject, that they will concede that eventually you need a proper state management library such as NgRx or Akita.

[00:02:26]
Their point is that it should not be your default state management option, if you don't need it, and certainly if you don't understand it. And to that I can say, I pretty much philosophically agree with you. And I think that makes sense. So, I think in terms of state management, that depending on the lifecycle of your application, is it a proof of concept, is it an MVP, is it an enterprise application that has to support hundreds of thousands of users?

[00:03:03]
That's going to affect how soon you adopt a library like NgRx right out of the gates. But, in terms of control flow, I will use a subject or a service with a subject for a lot of other things outside of state management, such as notifications. Global notifications within an application.

[00:03:28]
It is a notification service that has a subject under the hood, is very efficient, and it works. So, the answer is, if you're building anything trivial, you need to take state management seriously, which means that you're going to outgrow a service with a subject. A service with a subject as a lot of other uses outside of straight application state management.

[00:03:59]
But if you're in that transition period, where you're either converting to NgRx, or you're learning NgRx, or your app is very small and it may not get any bigger, then you have all of my blessing to start there. It's a really good starting place. I don't think it's a great finishing place depending on what the destination is.

[00:04:19]
The question is, why is it called a pessimistic update? Allow me to provide some context. So, I'm gonna go to effects. And what you're gonna see here is In the loadWidgets, nothing. It's just a standard call. But then, if you go into update, create, even delete, notice that the run block is wrapped in a pessimistic update function call.

[00:05:02]
Very astute, dear student. What this does, and so this is created by the wonderful folks at Nrwl. I love them to pieces. And what this does is, so, the converse of that is fetch. So you have fetch, pessimistic update, and optimistic update. I'm just stringing out the cliffhanger as long as I can, cuz I know I have your attention.

[00:05:30]
It determines how you're going to dispatch the action. And more so, how you're going to allow your state to be updated. So, in an asynchronous environment, you can update your local state and then hope that you remote state catches up. Or you can say, look, I'm gonna make sure it works at the server, before I update my local state.

[00:05:57]
So, if you're on a mobile device and you want that change to happen immediately, you're saying I'm pretty optimistic about the result of this. So, I'm gonna go ahead and update local state and them I'm gonna wait for, essentially, the remote state to catch up. And if something happens, well then I just have to kind of unwind it.

[00:06:21]
And so this is kind of the whole nature of offline web workers, and PWA's. Pessimistic update, which is typically what I default to because it's safest, is I'm saying, I'm pessimistic about the outcome. So, I'm going to wait for the remote server to successfully respond before I allow my local state to be updated.

[00:06:44]
Hopefully that made sense, but, it really depends on how fast you wanna update your UI and your local state. Do it immediately, and then hope that the server works. That's optimistic. Or, wait for the server to actually come through for once before you do something. That's pessimistic. So, as we bring this wonderful workshop to a conclusion, there's just a couple resources that I would like to point out.

[00:07:14]
I will augment this inside of the repository, within the read me, so that anything that, maybe I remember at midnight that I should have added or I should have said, I'll go ahead and add that. So, whenever you are watching this video, make sure that you check that because it'll certainly be longer than what I'm going to mention here.

[00:07:35]
But I would like to call out a couple of very specific people in terms of the content that they are creating, the resources that they're creating, that I have found to be incredibly helpful. So, the first one is my friend and his name is Minko. And he is a, like a senior engineer at Google.

[00:08:00]
And he's worked specifically on the Angular team. And he is very, very, very good. And there's a couple things that he's done here that I think are really, really interesting. The one that I want to call out, as, I believe, pretty much just a pot of gold is his Angular Performance Checklist.

[00:08:23]
And so he goes through and he just talks about all the things that you can do to improve your performance. And so, bundling, minification, tree-shaking, and on, and on, and on. And so, there's a lot of really good information here around how to optimize Angular. And he works on the Angular team.

[00:08:46]
So, he is very, very good with that. So, I've had the opportunity and the privilege of working with Minko on a number of things, including the latest Angular roadmap. So, in terms of a community initiative, him and I are collaborating on that, and he just has a lot of really good ideas about performance.

[00:09:04]
Another individual that I wanna call out is Michael Hladky. And If I lived in Europe, I was way more handsome, and more talented, I would be Michael Hladky. And even if you look at this pinned tweet right here, that this, and I've heard him talk about this, is phenomenal, this project.

[00:09:23]
So, if we go over here, and hopefully there's a screenshot. He had it in his post, but he is building some tooling around RxJs and Angular, to dramatically improve the performance of Angular. And so I would definitely put him on the radar. And I'm presuming the top is Angular.

[00:09:47]
The second one here is the performance piece. So Minko, Michael, and then, last but not least, in terms of DevOps, this is a site ran by my friend Stephen Kuenzli. And he has a lot of really good ideas around security, putting things into production. And a lot of what I know about cloud infrastructure, comes from him.

[00:10:16]
So, he's super into serverless, at the moment, a lot into security. And so I would definitely check out No Drama DevOps. And then, as well, always keep an eye on the Angular I/O website, as well as the NestJS website, cuz they are constantly doing a ton of good stuff.

[00:10:37]
And last but not least, the NX by Nrwl is, I highly recommend keeping an eye out on nx.dev because none of this would be possible without the work that they're doing around this model Repo. It's just a tool that I use all the time. I really, really, really, really, really love it.

[00:10:59]
I think it's excellent. And so, I believe across those couple of resources plus anything that I'll put into the read me, as soon as I think about it, I am certain that that will help you build higher quality, better Angular applications to put into production.