The new Adventures in Angular panel dives into the ins and outs of using NGXS and Firebase to build rich applications with Angular and these technologies.

Welcome to Adventures in Angular, the largest and most popular podcast in the world about web development with Angular. This show is brought to you by Envoy and Top End Devs. Envoy provides high quality design and software development services on a client friendly business model. Unlike all other agencies, Envoy allows clients to only pay after the work is delivered and approved. Visit envoyd.com to learn more and reach out if you know a company that needs more professionals to help with design and software development.

That's unvoidd.com. And Top End Devs helps you stay up to date with cutting edge technologies like JavaScript, Ruby, Elixir, and AI. Visit topenddevs.com to join their AI Dev Boot Camp, weekly community meetups, and access expert tutorials. I'm Lucas Paganini, founder of Envoy and host of this podcast. Thank you for tuning in.

Let's jump into the episode. Hey, everybody, and welcome back to another adventures in Angular. This week on our panel, we have 2 new panelists. We have Richard Citorle. Hey.

Hey. Hey. Do you wanna remind people who you are because we haven't had you on for a few weeks? Yeah. My name is Richard.

I am a front end, lead developer, for a company called Optimal Systems. I am based in Berlin, Germany, originally from Johannesburg, South Africa. And, yeah, I'm really loving the show. I'm a big fan of Angular, Adventures in Angular, and, yeah, I'm happy to be back again. Alright.

And just to keep it multinational, we also have another new panelist. We have and you can tell me if I say your name wrong too. It's Subrat Nishra. Yeah. Yeah.

It's correct. And hi, guys. Do you wanna remind people who you are? It's been a few months since you've been on. Yep.

Yep. Yep. So I'm as I told, I am Subhad Mishra. I'm from India, and currently, I'm in Bangalore. And I'm a full stack developer.

Currently, I'm working in in society general. And I think once in that last year, I was in the show at the at the guest. And now I'm very happy to be as a panelist. So it's there. It will be a wonderful experience.

And I had a I have a YouTube channel that is on basically on Angular, and that is fun of heuristic. So everything is going on together. Awesome. I'm Charles Max Wood, from dev chat dot TV. Maybe I should do a little intro too.

So I started the show with a bunch of friends of mine, what, like 7 years ago or something. And, yeah, we've been doing this show for a while. I kinda handed it off to some other folks, wound up taking it back over January time frame. Shay and I were doing it for a while. I interviewed a few folks like Richard, And, yeah, I wanted to bring some more people back in.

And so, yeah, I'm excited to be talking to some new friends. And, yeah, we have a a guest today. That's Joaquin. Is it seed? Yep.

Yep. Yeah. That's good. That's good. That's good.

That's good. That means I said it wrong. Joaquin, why don't you go ahead and introduce yourself, and we'll we'll dive into our topic here in a minute. Okay. Yeah.

So I'm a full stack developer. I'm currently working as a freelance. I'm from Rosario, Argentina, and I'm currently living, in Buenos Aires. And, yeah, I've been writing a couple of articles around NGXS Firebase, which I've also been working on for the last few years. And last year, I wrote a a plug in plug in with the help the with the NGXS team, a plug in that connects NGXS and Firebase.

And, yeah, happy to be here. Yeah. Hopefully, this will help everybody who's listening. Alright. Well, I'm gonna start real basic for some of our newer listeners, newer to Angular and and the ecosystem, and then we can just go as deep as we want.

Do you wanna just explain real quick what NGXS is and what Firebase is, and then we can just go for it? Okay. Yes. So first, I'll I'll start with Firebase, which is a back end plat it's a, yeah, it's a platform which helps you or provides you with mainly a database for you to build apps, but not only a a a database. It also provides you authorization, serverless functions, or, yeah, ability, capability to run serverless code.

And it also has a a lot of other tools that makes, yeah, makes everything you need to build an app very easy and very accessible. So you can spin up an an app really, really simple and really quick with Firebase. NGXS, on the other hand, it's it's a library state management library that fits within the Angular ecosystem. It is based on on the Redux pattern, so it's kinda similar to NGRX, but it's not like NGRX. It has.

It's different. And yeah. So it basically allows you to manage the state in in your application in a more structured way. It allows you to organize how you handle the the state with actions and and stuff like that. And, yeah, basically, when when you're starting when you're building apps, you'll normally get to a point when when you're going to need to use a state management library as your app grows.

And, well, NGSS is one of the options out there. It's the one that I prefer. Yeah. I don't know if that kinda gives an idea to about Firebase and NGSS. Yeah.

What I think whatever what I got there, I think it's for the everyone as well. It's little new newer in market, I guess, and it's, kind of a similar concept as NGRX as you told. Right. But it has what I'm just seeing here, it has some less components, so less less to code. That's a good thing.

Yeah. Yeah. One one of the differences or, I guess, the yeah. The main difference between NGSS and NGRX is that it was built to keep simplicity, like, with simplicity as the first thing, in mind. So and, also, the other idea on about NGSS is that it was or it it feels that it's similar to everything else that that you do in Angular.

So in Angular, you have classes and components. And in NGSS, you have your state, which is also a class, and you decorate it with a state decorator. And you have your actions, which are also functions that you decorate with with an an action decorator. And then within your state class, you can inject other services the same way that you inject services in your components. So it's basically pretty you you feel that you're writing similar code to everything else you you you're writing your angular applications.

And the other main difference with n g r x is that since you can have async functions as a first citizen of NGXS, you don't need what in NGRIX Rx, they call effects, which are things that you have to connect, like, in a separate file or yeah. You have to configure it in in an when when you have when you call an API and all that. So in NGSS, you can directly inject your API in a state class, for example, and then create an action that it's actually a promise or unservable. So that means that it's asynchronous. And the the library would all handle that synchronous for you.

So you don't have to worry to subs with subscribing and all that. So the library will do that for you. And, yeah, that for me, that that's that's something that also it makes things easier because you can have all that in the same action, so it's easier to understand the code and all that. So Mhmm. Yeah.

Thanks. I think that's a very good comparison, and I'm very glad that we we addressed the elephant in the room, because I think I had one of those questions lined up as well. And it would be remiss if we didn't ask that question. But you also mentioned some very key differences there. But my question would be, based on your experience and your humble opinion, and I presume you've used NGRx as well, even though you're a core member of the NGXS team, would you, what would be a good use case for using, this stack that you you wrote an article about?

So using Firebase and NGXS. So, yeah. So basically, this this plug in came out came out as an idea for me because I was I started working on a project, and we started working with Firebase, right, as a back end, which also Firebase, another cool feature is that allows you to build reactive apps. Right? Since Firebase lets you connect with a query to to the back end database, every change that occurs in the database is pushed to their clients that are connected without clients needing to pull for every time they want new the new latest data, let's say, or the latest value.

So all the all the new new changes or the new values that happen in in the database are pushed to the to the clients that are connected to them. So I started working on on a project with Firebase. I, initially started, using just the the Firebase library, which is a service that you can inject in your components. And then as as my app grew, I had to start doing something with the about the the state in the app because it's becoming too cumbersome to understand how everything was connected and and all that. And at that point, I made a research, which were the the different libraries that I could use to to manage state.

And so the the 3 that I I liked more were NGREX, which it was the the most popular one, NGXS, which actually a friend of mine told me about that one, and then the other one was Akita. So what I did is I I created the same feature with with the 3 libraries, And I I ended up deciding for for NGSS because that was the one that I liked the most and I that I felt that was the simpler and the one that would help me better in in my project. I mean, if right now or actually, after that, I wrote the plug in, which also improved further or make things easier even even easier between NGXS and Firebase. I don't know if there's something such a connector between NGRX and Firebase. I honestly didn't made a research on that.

But definitely, if if your Angular application has Firebase, if you want me if you need to to implement or to add some state management in your application, I would say give this plug in a try because, definitely, you're going to feel that things get easier for you. Yeah. You have you have some you have a you will have a learning curve until you figure out because once once you start using a a state management library like NGSS, but most of them are similar in that way, You start dispatching actions to get things done. You modify the state on the in the in the state class or in the reducers in case of NGREX, And then you select slices of of state. Right?

That that is the one that you present to to your components that or that you use in your components. So once you have once you learn that, the thing about this plan is that makes everything feel in the same way or work in the same way that you would normally use your NG access state. So you can use or you can combine data from different APIs or even the state that you have in in in your app with the one that is coming from Firebase. And merging that data is super easy because everything is in NG access. So you can combine that data very easily.

Yeah. That's kind of the main the main advantage of using this plan. So I guess what I'm trying to figure out is and I apologize if you cover this in your article and I just missed it or if it's covered in the documentation for your plugin. But so if I have data that I just want to live in my app and I have data that I want to live in Firebase, is there a way to differentiate that, and how does that work? So, basically, when you use Firebase may maybe I should have start I should have start there.

So when you use Firebase, you need the the service that, the Angular Fire Library has or provides. And with that, you connect to the database. So when you could create a connection to the database is when Firebase starts sending you data with the from the query that you you wrote. Right? And then you can make updates or create new documents, and that will be, of course, that that will be synced into the back end database.

So, essentially, if you're making the query, you want the that data to live in your app. If you want that data to to be in your app, it's and you're using a state management, it's better to keep in in your state management library or along with all the other app data. Right? Because most most of the times, you're going to need to make connections or merge make merge sheets between those that that data. So let's say you have a form or you have, I don't know, some some UI data or something like that.

You keep it in your state in in NG access, and then you bring data from Firebase with, for some for example, a list of users or whatever. Let's say you have a filter and the list of users. So filtering that, it's super easy because you have all the data in NGSS, and you can then make that filter with the in the same dataset. You don't have to make complicated connections between the AngularFire service and the the data that you have in your store. Because, I mean, you can do that.

You can do that. Mhmm. But it's more complicated. You have to start using a lot of r g RxJS operators. You have to start doing a lot of other things that well, it's more complicated, I guess.

Yeah. I think you answered my question when you said that you first set things up with AngularFire, and then you use this plug in to kinda connect. Right. And you pull everything into n NGXS, and then NGXS just looks at it all as data. Right.

Exactly. Exactly. That that makes sense to me. That that seems simpler too. Perfect.

Yeah. Yeah. So, basically, what this the plug in does and, yeah, following the same concept on how you use Firebase if you don't use if you don't use NGSS. So you have a query. So what what this planning does is fits that query into the NGXS model.

So Mhmm. On NG on NGXS, in order to do something, you have to dispatch an action. Right? So what what you do with this plan is that you connect an action with a query, and the results of that query, you you connect those with your store, the state. Right?

So, basically, what will happen is that you will configure in your state class that when you dispatch an next action, a action whatever, or let let's say we call it load users, that action, when you start that action, you're going to query the collection users from Firebase. Right? And when that query starts a meeting results, and we have to remember that those results are going to be a stream. So it's not a one only thing. It's going to be constantly emitting as changes occur in the database.

Every time a new emission happens, you're going to grab those results and insert them in your in your sort. The planning is going to do that for you. So you you don't have to worry. So that's that's kind of the magic that happens is Okay. You don't have to worry about updating the state every time.

You just configure the which action is going to start the query and how you're going to update the your store with the results. Everything else is handled by by the by the library. That's cool. That's cool. Yeah.

I I think there was one thing that I picked out out of what you mentioned now. Well, several things, but the one that really stuck out for me was you mentioned that just, like, just like we have in in NGRIX, you we've got the effects or the concept of effects. And you said this is not necessary in NGXS. And I'm just wondering, how do you ensure that oh, first of all, where do you handle your async, code and your side effects? And how do you ensure that your stay remains your store remains immutable?

Right. So, well, when an energy exists, actions can can be asynchronous. Right? So that means, or the the way that you do that is that you from that action, you return either a promise or an observable. So the state is going to be immutable because when you write the the action, there's a context that gets passed to that action, which is the one that you use to patch the state or to make modifications to the state.

Right? And those changes are going to be immutable, and that's it. That is something that that context that gets passed or injected to you in the action ensures. I don't know if that answers your question, but but, basically, the the state is immutable and the asynchronous thing about NGSS is just that if if we compare with, NGRX is that it includes the effect in the same action. We we can maybe we can imagine it like that because you can have an observable or a promise, and the library is going to handle that for you.

So it's going to wait or or to subscribe to an observable or it's going to dot then to a promise, let's say, and run the the next the the subsequent code for you. But the the the way that you patch the state or that you make modifications, it's always immutable. Yep. Yeah. That's that's very neat.

Sounds very, very neat. Yeah. Yeah. So we need. Yeah.

Go ahead. Go ahead. Sorry. No. No.

So the other thing about having at the or having the the the feature of asynchronous actions is that actions have a life cycle. So actions get dispatched and actions then are completed or canceled, and they can be completed with an error or or or successful. So the and an error can occur within the action. So you have, like, different events that will occur during the action life cycle, and you can have different states have the action can can finish. And that's also very, very interesting because with that, you can then know when an action has started and when an action has finished, and that's super helpful.

Actually, there there's another plug in on NGXA that it's also very, very nice that you can subscribe to know when an action is being executed. So let's this is the the famous or the, yeah, the very common, the loading the loading Spinner. Feature. Right? Right?

Your spinner. So, basically, you always want to put a loading or a spinner when, when an action or something is is going on. Right? So with that, life cycle, NGSS makes it super easy for you because you can track when the action is dispatched and starts spinning. And when the action has completed, you stop.

So you don't NGSS will handle that state for you. So you you just query when the action has started and when it has ended. And I think that in NGINX, you cannot do that. You have to manually, like, start a a loader before an action is dispatched. And so you have to do another thing, right, in order to to do that.

Yeah. I'm actually giggling because, yeah, that's exactly I I remember my own experience, with my team a couple of years back. We were using with an Angular shop, and we use NGRX, and exactly the scenario that you've just described now. Yeah. You had to jump through certain hooks to to manage that what appears to be a very straightforward and simple scenario.

But, yeah, it's very interesting to hear that that is, managed internally with within the library. It's pretty cool. Yeah. I I have a question. Like like, I I think you have just explained that one.

So I'm just want to clarify what I got is correct. So we basically make call make API calls inside our state once the accident is dispatched and update the state itself inside the state. Like, in in the case of NGRX, we use reducer and on sorry. Effects and reducer. So here, everything will happen in inside the state.

Is that correct? Exactly. All all the code lives in that state class. So you can have, like, the the comparison to the reducer in in NGSS. It's an action.

And within the action, you can call an API, for example, in Firebase or whatever API you you you you want to call, and then you can patch or make the modification to the state. So you have both things in the same, like yeah. It's it's called the action, the same code block, let's say. Yep. Yep.

So I have one more question. So if you check-in NGRX, so your store, it's mapped with your reducer to change the state of your of your application. Like, suppose I have, 2, 3 so one user model and one supports some items, then I, if I want to update user, I'll use the user reducer and to update item, I'll update the use the item reducer. But how it maps here, that will be best to know. Right.

So when when you want to change something, you create an action. The action can receive a payload. So let's say yeah. If it's you can dispatch when you dispatch an action, you can pass a parameter with values, and you receive that in the action block, actual code block. Mhmm.

And so as I mentioned earlier, so there's a a context. So I think in NGX, you have to return the new value. Right? You you just return, in the reducer, you you so in NG access, it's a bit more imperative. So you get a context injected in in the action.

It comes as a parameter in the action. And then with that context, you have a method that is called patch state. Mhmm. And that patch state is the one that you have to pass the new value that you want the state to have. So you can perform whatever operation you need or and when when that patch state is executed, the the the store gets updated in in a in middle way.

And all the selectors that depend on that data will push the the new date new values to all the components Mhmm. Yeah. That are connected to that, selector. Right? So the selector is basically CMAT, so what's in NGINX?

Yes. Yes. It's it's the same. So I have to ask this because I have this guy that touches, like, every line of code that I write, and he's a complete idiot. And his name is Chuck from yesterday.

All right. And the only way that I can keep this guy in line is to write tests. Okay. I mean, Chuck from today, he's fine. But Chuck from yesterday, the guy's moron.

Okay. And he screws stuff up, but I find his mistakes in the code that I write. Right. Cause I have to go back and I have to fix them. And so, but if I write tests, then a lot of times, I'll I can avoid writing some of these bugs in my code.

Not that I ever write bugs in my code, but how do I test this stuff? Right? How do I how do I make sure that I'm not writing bugs in my in my, in my stuff? Right. So NGSS, I mean, for for testing the actions and all that, there there's so if you go to the docs, there there is some documentation on how to to make tests.

We with Firebase, the the plug ins so you're basically you will have to mock the query. Right? Because Mhmm. What what you're doing is that the library is connecting the query with an action. So what what you have to mock is the the results that the query is going to emit and how the the and given that, the the store is going to get changes updated or inserted in the store.

So that's kinda what what you would want to test, how the the mock, the the results of the query that are going to get immediate and what will happen after that. Right. The thing so yeah. Honestly, there I think there are a lot of libraries to to mock observables. You can even create an object behavior subject, for example, and use that as the mock, which is what I do sometimes.

If I have to be completely honest, I mostly use or I try to use more Cypress to make tests sometimes. Right. Not a lot of not a lot of unit tests. And so one of the things about using or the the way that I like to use this plug in and that I try to keep the code in my applications, even though sometimes it's not very easy, is to try to keep it as simple as possible. Right?

So because that is less error error prone, and it also it's more maintainable. So this library helps you with that. So and the way that you should or that I try to use it is to try to to be the the less complicated as possible. I mean, the the common the most common operations that you would need to do in your application is bring a list of items from the database or a specific item from the database. And so, basically, your state is going to typically typically look like have a couple of a couple of connections.

So one to get at least or all of the items and one to get a specific item. Right? And those the result is going to be stored in that state, in that state class. Let's call it users, for example, want to get all the users, want to get a specific user, and they're all going to live in that state is as an array. Right?

And then you have the the selectors to to get active users, to get users that have signed in in the last day. And so, yeah, that that's what I try to keep the state or or yeah. The how to to write the code most of the times. Right? Of course, there are some times that things get complicated because it it is what it is.

Right? And for that situations, you you'll probably need to to make some tests. Also, one one cool feature about NG access is that the selectors are written as functions, as as pure functions. So Mhmm. It's very easy to to create tests around the selectors.

So this is different from from the library. Right? But you can you can easily inject so you basically provide the function, the set of results that is going to be your mock, and then you you expect something and you just write, execute that function. So it's it's super easy to to test selectors in that way. Yeah.

So I hope hopefully, that that helps. No. It makes sense. And, I mean, the it was mostly the Angular part of it or not Angular part. I was hoping to mock the Angular part of it.

Yeah. That that's genius, Chuck. Thanks. No. It was the Firebase part of it that I was trying to figure out.

Yeah. If there was a way to mock that just because you can kind of see yeah. I'm like, can I reliably get the right data back and have it come into my state the right way? And and, yeah, the more I think about that, the more Cypress kind of feels like the right level to be testing that at. Because, essentially then, yeah.

What I want to know is maybe at the component level, if I, if I have, if I trigger some kind of action, yeah. Is it going to follow through the system, make the query on the back end? But I don't want it to make a query because I don't wanna go do an end run out to Google. And then is it gonna update is it gonna make the proper updates on the other end, right, depending on what data it gets back? So I just need to mock that data out.

So that makes sense. Yeah. I'm Right. I've I've got a very so I I'm sorry. I suppose there's someone out there listening to this podcast and and wondering like, woah.

Okay. NGXA sounds super cool. You know, they can't wait to jump right in and and get started. I guess my question would be, like, what are the common pitfalls people fall into when starting out with NGXS, and what advice would you give them to avoid them? Right.

So, yeah, that's that's an interesting question. So my experience, I think or yeah. My experience and from what I've seen in in the Slack community that NGSS has, which by the way is very active and, yeah, people ask about for best practices and all that. Yeah. Some of us reply or even, people that are there.

So that's that's very cool. So I think that basically or what most often happens is that you start writing the your your NGSS code or your state code with a lot of how to say it? It's it's I don't want to say complicated, but because it's it's like you start doing it very specific to your to your your use case. And over time, you start noticing that you have to keep your state as generic as possible. So, like, in the in in your app life cycle, you would probably start because maybe your app requires in some place that you display a product, let's say, a product detail.

Right? And so with that in mind, you probably create some state for just that product, and stuff like that. Right? And then you then quickly realize that you're going to have to keep, the product available for other places, for other pages, and you're most likely going to have to load a lot of products. Right?

That that's kind of what what happened to me and what I I've seen in in the in the community asking. Right? So with that in mind, you would probably start your designing your state to keep one product leading in your application. Right? And then you realize that you have it's better to keep it as a as an array and and create selectors that reflect what each component needs.

Right? Right. So so, basically, I would say that that's one of one of the main thing. It's not designing your state with the needs of your components, so let the selectors do that for you because they are super flexible and very easy to change and try to keep your state as generic and as raw as possible. So meaning, if you're if you're going to if you have products or if you have users or if you have, I don't know, yeah, invoices, whatever, so try to keep them as raw as possible in the state and then let the selectors make the specific give the specificity for each component that you need in your application.

So that's yeah. I would say that that's one of the the main things. The the other main thing is is asynchronous actions. So I think that sometimes because people is used to use NGRX, they, usually follow the pattern of having a low action and the success or fail action of that load. Mhmm.

And that's in in NGRX, that is glued together with with the effects. Right? So in NGRXS, you don't need that. You can just have the load, and when the load finishes, you will get the result in the same block of code and make something, or or you you would fail in the same block of code and you can do something about it. So the patterns about that is also something that frequently, I see it, in in that people that people ask asked a lot about.

So in my experience, for what we most mostly recommend is that you should in NGSS, you should go out from the or not use that pattern of the three actions for loading something. Mhmm. You would prefer just keeping a load action and keep everything within that block of code, which also makes more a lot more sense when you need to start fixing things or you need to change because everything is going to live in a single place. Right. Yeah.

That makes a whole lot of sense. Yeah. Keep your state as generic as possible and use your selectors to, you know, to to get a slice of the data that you're interested in. Right. It's pretty cool.

Chuck, I don't know about you, but I've I'm very I'm itching to hear how you came about how he managed to become a core member of NGXS. You know, how did you join the team, and what was your journey like? Well, that's that's a very, very good question. So, yeah. So it it all started last year with the pandemic.

So that that was one good thing that the pandemic brought, for me. Actually, yeah. So since I started using NGSS, in my project, I started, participating on Slack, the community a lot. I have a couple of, yeah, questions and suggestions, and the the team, it was very yeah. So they received my my suggestions very well.

There there was a point, I think, that I I came out with the idea of of writing this this plug in. And at that point, when the the core, the the team lead of the of the core team, yeah, asked me if if I wanted to to join to join the team. So we we kind of, work together on on this plug in. And, yeah, I've I've been participating on on the on the team, meetings and all that since then. But, basically, it was I started, actively, contributing in Slack.

I, yeah, I think that there were a couple of issues that came out on on the on the NGX system. I collaborate as well to fix those. And and then I I started suggesting, yeah, these kind of plugins or making a couple of changes. Yeah, they they they liked the the ideas that I had. So in the end, they they they proposed being part of the team.

Wow. That's that's a very interesting story. So how so how many, yeah, so how many days it took you to finish? I think it's seeing a lot of code in pandemic. Yeah.

I think it it's it was around, I don't know, 2, 3 months. So the thing is that or at least in the the process for me was that I came up with the idea. I wrote, like, the first version of it, which was completely different from the the one that it's out there now. And I I demonstrated that one to the team lead with which is called, Mark Whitfeld. He really liked it.

He liked the idea, and he suggested changes to make it more ergonomic and easier to use. And, yeah, since then, I yeah. It was a second version. So I think that the whole process was around 2, 3 months, but it it was not, like, all the time working on it. It was a lot of time spent thinking about it, how how it should work.

Mhmm. And then when I finally did the first version, and that something it it was possible and it was helpful, then, you know, I was trying to polish it and make it better and easier to to use. Cool. So do you have any numbers in terms of usage of the plug in? Do do are you aware of how it's being used out in the wild, so to speak?

No. To be honest, no. I know that I know that I know that it has been used. I mean, so it has I have been a a lot there have been a lot of questions coming to the to the GitHub repository. So that's a way of knowing that someone is is using it.

The other day, we also did a an Angular session with, and so there was I I participated there as well. And there there were a couple of questions about the plug in, so that also at least shows interest about about it. But, yeah, if I had to be honest, I wouldn't know how many how many people are using it. I guess that I could look at the the downloads, but I don't know if that's that reflects completely the the usage. Yeah.

That's usually projects, not necessarily people. Right. So I know that the the NGSS team lead uses this used it in one of their projects. So yeah. Yeah.

That's great. Yeah. That's good. That's good. So one question I was, like, having, like, if I use this one in my project.

So I think you may have covered it, but I haven't gone through the your plug in. So I'm just asking, like, suppose if I make a call to a server and somehow my date state got updated, but, like, means, mom, my data got updated, but the state is not. And and at that moment, somehow the connection failed, or how it manage the state? Like, is it, will fire where Firebase will meet it again if you're if you're without any changes? So you're asking what happens when when the connection fails or you have you're out of connection with with Firebase, something like that?

Yeah. But scenario is, like, suppose your database is updated, but while, getting a response, your connection failed due to Internet connection. So that it's handled here, like, kind of because that is Yeah. Yours we are not able to state, and now we can add one more. But yeah.

Right. How? Right. So that that's that's the beauty that's the beauty of of Firebase. And the the good thing about using this this plug in is that it doesn't interfere with Firebase already does for you, which, by the way, it's it's a lot, and it it handles it very well.

So the way that Firebase works is that they initially update the in the client side locally, and then it tries to sync sync with the server. And it's going to retry until it it works. Mhmm. So, basically basically, you don't have to worry about that because Firebase is is taking care of that for you. You can get confirmations when the it actually has updated the the the database, but most of the times, it's going to you you're not going to need that because your Firebase is working on a is working, like, in a local, site first.

You're you're always going to be updated, in in in the in your application. Yeah. Yeah. So so it's like when you make an update, for example, you will see it reflecting in your in your application instantly. Right?

And then it's going to to update it in the back end, which which also that model, it's very, very good to for reactivity in your application because and and that's something that I haven't mentioned, and I think it's very important thing. So with NGXS and Firebase, you can make and you will make your application reactive from from the front end to the back end because NGXS, it's also a reactive it's a reactive state management library. And every time something changes in the store, all the components get synced with the new with the new value. And in Firebase, every time something changes in the in the database, all changes are are pushed to the connected clients right away. So you don't have when it every time or after you create a connection or a query, you don't have to worry anymore about pulling data.

And Yeah. Like, you have, like, a two way data to fetch data. Right? It's already connected, and data is flowing through the the connections all the time. So buyback to all the get calls?

Sorry? So we can say buy buyback to all the get calls. So in normal application, we used to make a get call then a good Right. Updates. And again, we'll get so we can Right.

Right. Exactly. Goodbye. Exactly. Exactly.

Exactly. Thing for me. Yeah. That's, yeah, that's very interesting. I mean, I've had the the pleasure of working with Firebase, in the past, I think, a couple of years back, and I'm sure a whole lot of things have changed, since then.

But, I mean, it's as a platform, I think it's it's it's great. I mean, you can literally pull together simple something that is typically not so easy to do by hand, for example, handling authentication. You've got that, Firestore database, real time database, storage, hosting, and functions, and so forth. And I've had a pleasure to to to play around with all of those, for one of my previous customers, and I absolutely love it. I think all the points that you've mentioned today, it's it's, yeah, it's all valid, and I would urge people out there to to to give it a try.

But for me, I'm I'm always very curious, like, when someone mentions something that sounds so good, like you have today, I'm always thinking about maintenance. Right? How easy is it to debug apps that are built with NG access? Do you have, something similar like Redux dev tools, for example? Yes.

Yes. You do. And I would say yeah. I mean, for me, of course, you'll always you'll always have to learn, the right to in order to to use your to use your your new library. There there's going to be some learning curve there, but in NGXS so since the since all the async actions or async is allowed in your actions, you can place debuggers within your block of code.

So it's going to stop there, and that that makes it easier to debug. And as far as changes in your store or how their their their the state is changing or after actions are executed, you can hook yeah. You can use the the Redux dev tools. It's the same the same plug in the Chrome plug in, and you will see changes that happen in your store after each action. So you can debug the debug that way as well.

Cool. Yeah. Alright. Great stuff. Now I wanna go play with it.

So we've already burned an hour on this, and now we're gonna go burn more. Right? Yeah. Yeah. But, yeah, before we do that, I'm gonna push this over to picks because, yeah, we're kinda getting toward time.

Wanna make sure that, yeah, we wrap this up before people have to run off and do other stuff. So, yeah, let's go ahead and do picks. I'm pretty sure everybody here has done it before except maybe Joaquin. So, yeah, let's let's go ahead and have Richard do it first. Richard, do you have some picks for us today?

Yes. I've I've got 2 today. The first one is, if you remember, Chuck, I we spoke a couple of weeks ago about my pending trip, to Crete in Greece. I yeah. I had a pleasure to yeah.

It was, small little town called Chania, as the locals call it, but it's just picturesque. It's so beautiful and tranquil. Yeah. And I had a chance to to go and recharge my batteries, so to speak. Came back feeling super refreshed and ready to to rock and roll again.

So, yeah, if you do get an opportunity to travel, I would definitely pick that up. Let me know if you want to know where all the cool beaches are at. I'll be making sure of that. And then the other one is, so the the funny thing is the company that I work for, we all the different teams have names of birds. And my teams the name of our team is called Dodo.

If you know of this extinct bird called Dodo. But, yeah, I just wanna send a shout out to my team. They are they're fantastic. They're great bunch of boys and girls, and we work great together. So, yeah, I just wanna say shout out to them.

Awesome. Suburath, you have some picks for us? Yeah. Yeah. Yeah.

So first one will be tech technical picks, and that I recently came across a back end framework for Node. Js. It's a Nest. Js. It's not Next, but I I was also little confused at the beginning.

So it's Nest. Js. And the the true cool thing is it's, like, you can say 70 to 80% similar as Angular. You we have, services. We have modules.

We have everything. So it's a pretty gift for Angular developer to develop, the back end. And every every angle Angular developer should check it once because they can be full stack developer with that. And, and the second one will be a Netflix city that I think everybody knows is Lucifer. I am watching that right now, and that's all I guess for me this week.

Awesome. Yeah. And if you could put, links to your picks in the chat, then we'll make sure we get them in the show notes. So I'll throw in my picks here real quick. Now I've picked this on, like, every show because it's still bending my brain.

I am, so I listened to the book. Now I'm reading the book. I probably listening to it again here soon. It's called Who Not How. It is very much more of a business book, I guess, than a technical book, but I'm finding it applicable in a whole bunch of areas of my life.

So if you're trying to get more done in life, then this is the book for you. Okay. And, let me just give you the rundown real quick. So for me, I'm working a full time job. I'm trying to run a podcast network.

I have 5 kids. I trained for a marathon that I did not run on Saturday because my nephew got me sick. I will spare you the gory details because it's kind of gross how some of this stuff manifests. But anyway, so, yeah, you know, I have all this stuff going on in life and I was trying to do everything myself. And to a certain degree, I still am, but I started reading this book and I realized that I don't have to do everything myself.

So I've started bringing people in to do more of the stuff. And yeah, some of it, I feel like, oh, it's not going to get done the way that I want or exactly how I want or as good as I would do it. But holy crap. I cannot do it all myself. And the other thing is is the more I free up myself from doing the things that I don't have to do, the more I can spend time working on the things that I do have to do, and especially the things that allow me to pay the bills at home and pay the bills for the people that are working for me here in the podcast network and stuff like that.

If you hear my kids screaming, I'm really sorry. So anyway, you get the idea. That's kind of how it opens up. So there are 4 sections. The first one is freedom of money.

The second one's freedom of time. I might've gotten those backwards. The third one's freedom of relationships, and the 4th one is freedom of purpose. And those are the 4 sections. So the first one the first two talk about freedom of time, freedom of money.

Right? And so the idea is is you start bringing up your time. And then once you have time to focus on the right things, then you start to free up money. Right? Because you start focusing on the things that make you more money.

And then you can start focusing on the relationships that matter both in your business and in life, and then you can start focusing on actually working on the things that help build your purpose in life. And so, anyway, it completely blew me away to the point where I just immediately started working through the book the second time. Loved it. So I'm gonna pick that. Another book that I listened to that I also really enjoyed because I do listen when I'm out and about, but I wanted to actually read the physical book.

So this book is called, sorry. My brain just went blank on it, but it was recommended to me by my friend, Manny, and it's one of his favorite books. Oh, what's it called? I can pull it up on Audible. As a Man Thinketh by James Allen.

And it's funny because it's an older book. Like the newer books of this genre, they tend to tell stories and illustrate their points and stuff like that. But the older ones like Napoleon Hill's Think and Grow Rich, You've got what's the other one? The, the Carnegie book. Win Friends and Influence People, a lot of those, they have less of the story and less of the narrative, and they more just kinda just tell you their ideas and just flesh them out.

And so this is one of those. Right? And so I like the stories, and so it was a little bit harder for me to kinda get through, and there's a lot to unpack there. So it's very dense, but there is so much there that is just so, there's just so much there that you can just get so much out of. And so I encourage you to go take a minute to go listen to it because I mean, just just quality stuff.

But the flip side is, is that, yeah, just be aware that you might have to go back through it in order to get all mine all the gold out of it. But, yeah, terrific book there as well. So, those are my 2 picks. I'm gonna pick those 2 books. And then, of course, devinfluencers.com/podcast is the podcast I've been doing every day.

There you go. Alright. Joaquin, what are your picks? Okay. So I would say my pick is Nielsalvoise.

Actually, it's it's just a shout out to my football team I'm a fan of. We're not in the in the best, shape right now, but hopefully next season will be will be better for us. And That's a true fan. I love my football team. Not the best year for us, but I'm there for you guys.

Yeah. And so NGXS, of course. The the other thing I I wanted to mention is a TV show. I recently watched a Mirror of Instown, which was very, very, very cool for me. Very good.

And, yeah, those are my picks. Awesome. And then if people wanna get a hold of you online, you know, say GitHub, Twitter, that kind of stuff, where where do they find you? So, yeah, I'm in Twitter. My account is joaqcid.

I'm going to send a link there if you want to post it. But it's basically a couple of letters of my name and my my last name. Yeah. I'm in Twitter. I'm in on me, and we have the same account name, so you can find me there.

Awesome. Alright. Well, thanks for coming. This was awesome. And until next time, folks.

Max out.