Amal Ayyash is a UX Designer and Front-end Developer. and her current main focus is Angular. She joins Chuck and Lucas to discuss her article, “RxJS-based state management in Angular”. She starts the show off by explaining the reason why she chose to use RxJS to create state management instead of using NgRX. She also gives advice to other developers, encouraging them to use their own frameworks or codes rather than third-party solutions.

 

Hey there, and welcome to another episode of Adventures in Angular. This week on our panel, we have Lucas Paganini.

 

Hello Chuck,

 

I'm,

 

good to be here again.

 

yeah, yeah, always happy to have you back. I'm Charles Max Wood from Top End Devs. And this week we have a special guest. It's Amal Ayash. Did I say your name right? I should have asked before

 

Yep,

 

the show.

 

that's right, that's perfect, thank you.

 

So, you know, you're calling in from Jordan, which is cool. I love talking to people from all over the world. Do you want to just introduce yourself real quick, let people know who you are and what you do?

 

Hi. Basically, I was working in web development and web technology for the past 22 years. Maybe even I started at the time of the university. The past 10 years, I was focusing on creating MVPs or minimum viable applications for startups. So it's been like freelance all the way. And for the past year, I was focusing on a little bit into creating content. So I'm looking into creating more content. Maybe sometime down the road I will do my own video. Who knows? So that's basically what I do. And I have really touched base on a lot of technologies in web. My last interest was Angular, and I like it. I'm stuck with it for a while, for now.

 

stuck with it, yeah.

 

Yeah.

 

That's how I talk about the stuff I love too. So anyway, yeah. Well, it's good to have you. Now you wrote

 

Thank

 

this

 

you.

 

article about an RxJS based state management. And

 

Yes.

 

what I think is interesting about this is that, yeah, usually you see people use like NTRX or MobX or, you know, pick your, you know, heavyweight state library. And it looks like you're just doing this with RxJS and the observables that it provides, which I found very interesting. So do you want to explain to people what, what

 

Why?

 

you did? And then we can all ask our questions. Like, why didn't you just use NGRX?

 

Okay, so because, as I said, I create MVPs, the key value of creating a very simple application for a startup, especially for a startup that doesn't have anything, it's from scratch, is that I always look for solutions that do not take a lot of space and do not have a huge boilerplate, basically. So whatever I do, I usually, I mean, Angular itself as itself is a huge third party, you can say, but it's something that adds a lot of value. So... Whatever I do, I usually stick away from third parties and just try to do it locally. So I tried NGRX once and it turned out that the boilerplate, the added code to the code base was so huge, the value was so small that I decided, you know what, we can do it myself. It doesn't have to be that big. So I decided, you know what, the scenarios that I wanted to create. is one basic scenario because when you have an application, a small scale application, what you need to do is control state for a single user, really. The main thing that we wanted to create state for was a transaction list, for example, something that comes from the server as a list. And then you update that list by adding something to it, removing something out of it and updating an item. And later on we want to create a little bit more space for ourselves. What if we want to have a single item state? And what if we want to have multiple states, what if we want to have more states and so on? So that was the way I went through the article that I wrote. I started first with the list, which is the most used part, and then went to the other parts of having a single item and tried a few things around adding multiple. properties, making the list as an internal property of the state and whatnot. And then came back and realized, this is the class that I want to use. It's a very simple class that I can create as many states as I want to. It's very simple. It returns an observable. It's based on RxJS, which is already a huge boilerplate. Why not use it? It comes with Angular, so why just not use it? So that's basically the idea. So do we want to go through what I did from the beginning of the article? Do I go through the details of it?

 

Um, well, let's just stop. Do you have any questions at this point, Lucas, or do you want to keep going?

 

I do have a few more regarding when to, because I always try to abstract the things they were recommending so that I can try to think about how the deeper concept applies to other scenarios. So we could dive more into when it's a good idea to create something yourself and when it's a good idea to just use a solution that already exists, which is, can be a good idea. a long discussion

 

Yeah.

 

in itself. We could also just talk about that specifically to the case of NGRX versus a custom solution because one thing that I also think about in terms of creating your own data store management or versus using NGRX or any other solution is that NGRX is really good, but I agree that it's too many things. And sometimes it can become more complex than necessary to do a simple thing. So I completely agree with the fact that if you're going to do something simple, it's going to introduce too much complexity. But I also know, because I had to use that in a co-base, that NGRX provides a simpler interface that makes it much easier to create... crude, simple crude data stores in NGRX. And I think they should very well update their docs and make it easier to know about that because there's a particular library inside of NGRX called NGRX data. And using NGRX data, you can massively simplify how you construct data stores if you're just going to do CRUD. And I myself went through the route of creating a data store once. And at the end, I... I chose to go back and use NGRX data. So I would actually like to extend this, this things that I'm thinking about to Ayaash and ask her, do you think that there's value in us diving more into that or would you rather dive more into your solution and how it differentiates from NGRX? Because I think this is, we could go. in either direction and the audience would see value from it either way. So since you

 

Mm.

 

were the author of the series, I'd like to ask you which direction you want to go.

 

Yeah, well, as I specified, I read this article, which states, yeah, you can have multiple ways to manage state, right? So it's not really about whether you should go RxJS or NGRx, because they both are valid solutions. The question is when do you use that and when do you use the other one? And to be honest, I would always go with the homemade, but that's because I create MVPs. And when I say, A homemade does not necessarily have to be something that I do now and I have to repeat in every project. Once I have my own library, I can reuse, but the good thing about it is the seed. It's not a library. So the seed, you can always like dig in and change and fix and every new project you can handle it manually. You don't have to have layers of abstraction. Okay, so maybe if you ask me if you want to go down the road of talking about RXJS solution itself versus why not NGRX instead? I think they're both valid ways to discuss it. So I'll just leave this up to you. Which way we want to go. We're going to go, let's talk about just RXJS and leave off the NGRX. Or would you say?

 

I'm going to jump in and I'm going to push us down the road of how you implemented this with RxJS and how that worked. And then we can kind of, we can circle back. I think once we see the solution and the thought process behind it, we can circle back to, okay, so then at what point, yeah, does it make sense to use your own homegrown thing versus using something that's out there and, you know, built, maintained and embraced by the community?

 

Okay.

 

So yeah.

 

All right. So we'll then talk about the, let me just open the article just to keep it. I have also a stack of bits, by the way. It will make things

 

I love

 

a bit

 

stack

 

easier

 

blitz.

 

for everyone. Yeah. Sometimes it's good. Sometimes it's not. All right.

 

I'll tell Eric you said that.

 

I will tell Eric is the person responsible for creating the stack bits. Can I?

 

Yeah, Eric and Albert.

 

Yeah, I'll just pass my notes then.

 

Yeah, there you go.

 

All right. RXJS-based state management. Now, the idea, as I said, is to have locally created state management so that we do not have to run into NGRX too soon. The problem. is known. We want to have state management in a simple application. Small scale, medium scale is more like it. Because at the beginning of the project, it's always either small scale or medium scale. The solution based on our XJSP is it has a pattern, using a pattern that we have used multiple times in Angular, which is creating an internal behavior subject and then listening to that subject and returning it as an observable or wrapping it in an observable. So the class, we already know that this is the pattern that we're going to be using. Behavior subject and return in and observable of it. Now we're gonna run from the front end and backwards towards our class. We wanna create the end product is a class that we want to reuse to create multiple states. So one scenario that we want to fix is that we have a list of, for example, projects coming from the server. We want to set the initial state. You want to be able to edit an item, delete an item, and add a new item. And probably down the road, we want to nullify the list somehow. So those are the basic four functions, setState, addItem, deleteItem, and updateItem. The thing that I think NGRX and other ready-made solutions do is that they let you have a toolkit and you go ahead and use it as you wish. So when you have a select, when you select something from the store, gives you back or when you set something to the store, you set the list and then you deal with the list as you see fit. Like for example, I think it's in a reducer. You have to clone the item first, for example. I'm trying to come up with a way that we don't have to do that. Just put it away in a class because I know all the time that I need to clone the item, for example. So the first element to that class, let's call it state service or list state service. So we want to differentiate it from a single state service. The state service has set list. I'm stuttering a little bit too much, I know.

 

Oh, you're fine.

 

Well, okay. We have the first function is set list. which is the function that gets the list from the database immediately and sets it into the first next item. Let's use the next as a verb. Let's next things into something. So we next our observable or behavior subject. We will next our behavior subject into this new list. And then we have another one called add item, another one, edit item and remove item. The difference is that the item, all it does is just clones the current list and adds a new item. The remove item naturally just next into filtering the current item without a specific item. And the edit item clones first, then adds it to the list. The challenges that we are going to face, for one thing, is that we need to have an ID, a property, that makes this item, that we can remove it or find it and update it. So. All we have to do is create a model, a model that we later extend from it. So our state list, if we think about it, is a state list of a generic. And that generic needs to extend or inherit a model. And the model has at least ID, a property ID. So we can use the ID to clone, to find, and remove, and whatnot. And that's basically what we're going to do. It's just the bottom of it. I mean, besides that, the other things that I ran into are when do we find the item, looking at the code. The append list for example at one point you need to append a list instead of just adding one item at a time Let's create an append list. Why not? Let's create a prepend list. Why not? Let's empty the list because it's ours, right? Because

 

Mm-hmm.

 

it's our list. So after adding all these items It was very simple just set list when you have new Incoming data from the server and If you click on a button to edit list Find the item by ID edit clone it and return it. Of course, you have to remember to clone properly using something like the low-prop

 

Mm-hmm.

 

library Because if you do not clone all the way to the bottom of little bit details, it's gonna be a mess so you have to remember always to clone properly and This is it really this is the basic of it when it comes to listings The next stage is to create multiple services. And I tried out a few things by what if I want to have a little more than just a list? What if I want to keep state of parameters, like the total number of returned items? What if I want to keep state of the filtration, the page number and whatnot? So the next stage was to create a state list. a state service, which is a single state service. It looks pretty much like the list state service, except that it deals with a single item. It has a generic as well. It extends the same model, which has an ID. As a matter of fact, I don't think you need that one in a list item. And in a single state item, you don't need an ID. So the generic does not have to inherit anything in the state. You have properties, they have main functions, set item, for the initial state of the item, and update item, and probably remove item, we just need to nullify the item at one point. Very basic, and then I created some scenarios here and there, pagination, for example, the continuous pagination is a well-known example, the loading, the filtration, and whatnot. Do you have any like specific questions about them?

 

So for most of these, you're just using observables to manage the lists.

 

Exactly. It's the internal. When I created the class, we have two properties. One of them is an internal behavior subject. The other one is the observable as observable. Because if you say dot as observable of the behavior subject, then you have an observable. And every time you create setlist, you return the observable so that you can pipe on it. So edit, yeah, exactly. So it's the setlist and the append list and whatnot. You return the observable for easier handling, piping and so on. So yes, it is observables. I mean, I heard someone say before that, it's just not right to have too many observables in your state management. But I say why not? Because it sounds like a pretty neat solution, very simple one. It can create multiple states. as well, you can stop injecting in root because if it's an injectable provided in root, then you have one instance, right? But if you have, if you do not inject it in root, like in the parameters, for example, I need a way to control the page listing. I need a way to filter it. I need a way to pass a certain filter to that list so that the user, when they click, I mean, I'm giving

 

Mm-hmm.

 

you an example of when you need state, really, when you need state management. If you have a page that lists the item of projects, and clicking somewhere opens a dialog box, and that dialog box manipulates the project, that's when you need state. But if you move from one page to the other using a route, that comes down to the simplicity of the solution. You really don't need state if you switch from one route to the other. So yeah, I mean, it's a good idea. It came down to the simple class that I created on stackplates. And there were a lot of challenges along the way that I fixed one at a time. It came down to that.

 

Um,

 

That's cool.

 

one, yeah, yeah. This is really cool. I particularly think that any developer that is using data management in Angular or any other front-end framework, or even no framework, just vanilla, I think that building something like this is gonna be valuable at any point because it gives you such a solid foundation of how things work internally. that even if you do decide to use a library later on, you will know what was the top process that went behind creating it. So I still think that this is a super valid solution. I still have my regards

 

Well,

 

about it, but yeah. Yeah.

 

we can argue on why not NGRX, for example. But again, there's a difference between a mindset of a library

 

Yeah.

 

versus a seed. And

 

Yes.

 

the seed, the good thing about a seed is that it doesn't layer up abstractions. Now, in NGRX, they have to deal with a whole lot of people. So they have to write code for millions of people, right? If

 

Yes.

 

not, thousands is millions. So every time somebody has an issue, they're going to log an issue and they're going to make a feature out of it. That creates a lot more code than necessarily needs to be. If you have a small project, small scale, I mean, imagine a small scale application that has one screen that has a list of, for example, transactions that you can add and edit. I have an application like that, small application. I keep track of my transactions, my daily transactions. Imagine if I add NGRX to it. It's gonna like triple in size at the end of the day. Because there's nothing there. It's just a simple page with a lot of edit and delete and whatnot. So that's when you have to stop and think, okay, do I add NGRX now or do I add it later? I'm not saying you should not be adding NGRX or something like that. But is it now or later? And the problem is that when you are a freelancer working on the inception of all projects, It's always later and later I'm not really present. I'm usually at the beginning of the project. So every time I come in, I create it. The next project, I already have it. And I just add to it. I spice it up a bit and go on from one project to the other until I reach the point where really this is what I keep using over and over again. So I might just as well share with the public. But I don't mean it to be a solution as a third party. I mean it to be. Something that you add to your code, source code, and you manipulate it as you see will fit. It's very important that you, for example, this ID. I have a generic with the extends an ID. What if you have a key instead of ID? Would be like a bit of a mess there, right? So this is meant to be a seed, not

 

Gotcha.

 

really a library.

 

Gotcha. How do you balance that from the relearning process later? Because for example, let me give you one example of a client that I have for my company. So I run a software company. We have this client, still active. And when they started out as many startups, they had just... one person to do the frontend at the beginning. And

 

Thanks

 

they

 

for watching!

 

needed a solution fast so that they could actually show that it could work. Like that they could pivot or pivot no, but iterate over it later. So they needed just something functional to show. So this developer is not that he wasn't... It's not that he didn't knew about NGRX. It's even deeper. Like... I think it was the first time that he had used Angular in

 

Hmm.

 

the front end. So he was learning a lot of things at the same time. And when it came to data management, he started with a simple solution. So at the beginning, he didn't even need it. RxJS, he was just saving things into a service, saving the data that needed to be reused in many pages so that it would avoid network requests. Later on... the system added more features and then he had to transform that into a more abstract solution. And it actually got very, very close to the solution that you presented. Your solution is much more organized. It went through multiple iterations until you got to this, into the organized way that you did. But in his case, he was having to push a lot of other features and also keep updating that and adding more features, so he didn't really have time to refactor that. And that became a very huge problem later. My team was actually tasked with one of the major goals that we had in that particular codebase was moving all the data stores that were using the custom solution to NGRX after we got into a proof of concept for NGRX. major steps. The first is how can we use NGRX with the minimal amount of boilerplate possible, because we do not want to write reducers and actions and effects for everything. And then we had to learn about NGRX data, we had to really play with it because unfortunately there are not many docs about it.

 

Yeah.

 

And then when we finally found a good solution for one module, then we went to the next big step, which was applying... the same solution to all the data stores. And at this point, the thing that started three years ago when it was just one developer in the front end, at this point, it was more than 20 data stores and they were mutating the state in such a way that it wasn't a clean replacement. For us to replace that with a functional data store that would treat data as immutable. and replicate that in the most performant way possible. It was not just switching the stores and changing the syntax a little bit. It actually became a much bigger monster

 

Miss

 

and it took literally months.

 

Yeah.

 

I'm talking like four months of work to refactor all of them and it costs a lot to the client itself, to the company later. So one thing that... They, at the time when I started talking about the fact that we were in a point where refactoring that was necessary because the code was so messy that we couldn't add more features. At the time, they still had the thought that, oh yeah, we understand, but it was the right call at the time because we needed to go fast. And even I agreed. But then more recently, their thought is now we should have researched more so that we wouldn't have to refactor so much later on. So

 

Hmm.

 

that's something that as you were talking about the projects that you get, immediately came to my mind. It's like that is the context that... provides reasons for those seed projects to emerge is when you are in an MVP, you have to create something fast, you have to be able to change things. It makes sense that you want to start with something easy. But the other side is later on it becomes a problem. But then you could say, yeah, but then later on the company is already running, they already have

 

Yeah.

 

an MVP, so they're in a better position, especially financially.

 

Yeah.

 

So now they can... put the investment to that. True.

 

Yeah.

 

But the other side is, what is really the cost of adding NGRX or any other big library earlier on? You may say it's got to triple the size of the application. Yes, but in terms of the time that it's going to take to execute or to download the initial bundle, even if it... multiplies by five the bundle size just because the app is so small that even like one library makes it multiply by five it may still be really small so the time that it takes to download and execute might still be short.

 

Hmm. Yeah.

 

So I wanted your view on that like when does it really make sense to avoid increasing the bundle size and adding this tech depth that would need to be changed later on in the application.

 

All right, well, going back to your example of a company that is hiring a single person to do something then figuring out later that they should have researched more. Probably they should have had a better developer as well. Because you see, I mean, that is part of the decision, right? When you create a new project, part of the decision is who's gonna make it? Are we going to have a small solution? Or are we gonna have a huge solution? Who's gonna make that? call that this is a small solution or a large solution. Who can decide that later on we need NGRX down the road? Because it is an art in itself, knowing ahead of time what you need later. And it's not something a junior developer or someone who doesn't have enough knowledge in that to figure out what to do now in order for later things to go smooth. But what I say, MVPs. Most of my projects that I work on are small scale and I know they never go beyond medium scale. But it's really a thing that I want to encourage more developers to pick up on, which is create seeds along the way, even if later on you need to transfer that. Because very, very simple, our subtle difference between having an NGRX everybody knows about versus having your own internal code. Your own internal code at the end of the day is something that you can manipulate. fix and do whatever you want with it. You can, I mean, when I say triple the size, I mean, if you look at the NGRX, the RxJS state management, just one file, just one file that I use for all the states, really. So you cannot really compare that to the NGRX library, you know, the whole mountain of files. The other thing is that when you have a huge library like NGRX, you have third party people to dictate how you should do things. You never know what happens the next version. telling me about what goes down the road in this version. So you imagine next version, what's gonna happen when they upgrade. The technical debts they used, you thought you had when you used NGRX, when you used RJX or homegrown application. Wait to see it when NGRX updates. Really, because I've seen this happen a lot when it comes to like, for example, Bootstrap. I don't use Bootstrap. I also use a homegrown framework, a framework that I'm used to. And I document it well for my clients, but I expect them to remove it and add their own stuff. That's fine. I use the same syntax as much as I possibly can. But when I used Bootstrap 3 at one point, by the time the project ended and started to pick up and had new projects and go down the road and have production, Bootstrap 4 was in the market. So whatever you know about Boost Chapter 3, you have to go back and fix it. It's now old. You have to upgrade. And that happens because it's not yours. It's simply not yours. So I just want to encourage more people to, all right, it's good to have Fair Party. And it's good to have people gathering together to create libraries and share their opinions and have issues and whatnot. But it's also a good habit to rely on your own stuff. Then of the road because it helps you just grow at least technically so next time you have a new project You can tell or you know, maybe we should hold off in your X for now Knowing that we're going to be using it like six months from now. So let's let's Start now with something simple knowing where to fix or what need what we were just create stubs You know you create stubs and you know that you're gonna stop in GRX in these points That's a better way to think about it. Even simple solutions like CSS. I mean, since when do we need a library for CSS? It's just been recent, you know, when Twitter came up with Bootstrap.

 

Yes.

 

But CSS is pretty simple and straightforward. You don't need a library for that.

 

Yep.

 

You know, I always keep saying that Bootstrap, the problem with Bootstrap is that it made developers think that they are good designers, you know, at

 

Mm-hmm.

 

one point.

 

Bootstrap

 

So

 

is

 

I.

 

beautiful.

 

Yeah, it is beautiful for developers who are colorblind, probably. Yeah, the problem is that you have so many websites now, they all look alike because

 

Yes.

 

they all use Bootstrap and that's what I'm digressing right now. So let's get back to the topic.

 

You said

 

The idea

 

many.

 

is that when... So I think with our knowledge year after year, we're building our technical knowledge. It becomes easy to figure out at one point that yes, let's use, I mean, I used to, for example, never use material out of the box, the material product, CDK, I never used it out of the box, except for the date control. Because I know the date control is something I don't want to do myself. It has a lot of features, so I just get it out of the CDK. Then HTML progressed, and then the date control is now built in. So I don't have to use it at all. I still see people using stuff from material that they don't need to use from material. They can do it in native HTML. So it's just a mindset. I'm trying to encourage that mindset of just try your best to be native. Let's say, I mean, Angular itself is not native. But yeah, try at least to use Angular before you jump into a bigger solution, knowing that, yes, you might need a third party solution down the road. There's nothing wrong with using an NGRX, but know when to use it and when how to prepare for it, you know

 

I think you said many, many interesting things that we could dive deeper. One thing that I'd like to point out is you said that besides the problem with the bundle size, you have a maybe even bigger problem with control. With having something in your codebase that can change the API at any point, it can change. how it works not just internally, not just as a black box, but how you interact with it could change. And even when you're talking about Bootstrap, that's even bigger because it can change the actual visual results, not just for you, the developer, but for what your users are going to see. So maybe you don't even want the changes that a new version of a CSS framework applies to your overall design, which is one of the reasons why I never use... CSS frameworks, but again, I'm not going to digress on that. But talking about control over third parties, there's something that me and all teams that I have in my company, we are instructed to do this whenever we add a third party solution that is going to be reused in many parts of the application. And the instruction is always to add a layer of abstraction on top of it. So for example, when we use NGRX, we don't interact with the NGRX store directly. We always create facades, which is a class that interacts with NGRX internally, but you just interact with the facade. And the idea is sometimes you're not going to need NGRX. If you just need a very, very... We have... some models that cannot be updated, deleted, or created. They're just hard-coded list, either

 

Mm.

 

hard-coded

 

Hmm.

 

in the front-end or hard-coded in the back-end and the back-end gives to you. So there's no reason for us to have a full NGRX store for that. So in those cases, we still have the facade with the same API of all the other facades. So it implements the same interface. It has the same method names, the same signature, but internally, it doesn't necessarily use NGRX.

 

Hmm.

 

It can be a facade that internally just directly saves the data into a behavior subject, or maybe even uses another datastore entirely. And this is something that we apply not just to datastore. So datastore management is one example, but another is... what solution you use to run your HTTP server. So for example,

 

Mm.

 

we wouldn't run Express directly. We would create an abstraction that uses Express internally, and then if we ever decide to change to Fastify, for example, it would be fine because

 

Yeah.

 

our code is not directly getting in contact with Express, is getting in contact with interface which we are adapting for Express. And then we have all the features and we can easily switch the internal solution. And we can also add, we can also make changes to it without waiting on this third-party library to apply those changes and adding those features, especially because sometimes it doesn't make sense to them to add those features. Sometimes

 

Mm.

 

it's just too specific. Most times I would say it's... The changes that you need from a library are too specific to your business logic. And then

 

Mm,

 

if you

 

yeah.

 

have this layer of abstraction, you can still reuse everything that this library already provides to you, all that structure, but you still have control to make all the necessary changes that you need for your specific

 

Yeah.

 

use case.

 

Yeah, well, I would, I mean, that's all cool, but I would like to challenge you with this. Now that you have added a layer abstraction, and we all do that. I mean, even when I create a call to the database, I have to make it go through my facade to make sure that the data model that comes from the server does not affect my work in the UI. This is understood, but. Imagine that this is a layer of abstraction in my code. The number of layer of abstractions inside of NGRX itself, and then the layers of abstractions inside of Angular itself. So not only are you adding to Angular and then NGRX, you're adding your own layer of abstraction. In a huge website, in a huge application, I understand that in an enterprise application with multiple teams and multiple features, That kind of is understood because you have teams dedicated to making sure that the bundle sizes are in place, the performance is working fine and whatnot. Right? But when you have a small scale application that does very little things, you are always aware of what layer of abstraction you're adding. Because you are already like way ahead in layers. The more you can remove, the better. So that's why, for example, I would actually just go for 11T sometimes, because it generates pure HTML. Sometimes that is the solution. Doesn't have to be a fully SPA. The problem with SPA anyway, that when SPA came into existence, they kind of changed them, they had a paradigm shift that developers did not adopt. It used to be the whole business logic was on the service side, PHP and ASP. And then this, this pad out HTML ready made HTML, the font and developer takes that HTML as a few PHP tags here and there to produce the HTML, right? Then Ajax came along, but even with Ajax, we used to return HTML. But now with SPA, the whole business logic turned from the backend, ASP.net or whatnot into the front end, into Angular. And that in itself is, is a huge challenge. For someone who's used to creating front-end development, front-end controls and HTML pages, they probably don't know how to deal with that, how to deal with it for layer abstraction, for example, creating facades is something pretty challenging for them. And as we go along, I mean, that's true, we're talking about 2011, as we moved forward from then, people started to understand better that front-end developers have to have this knowledge, they have to create this. But in order for that to happen, you also have to understand that there's a huge amount of layers of abstraction going on the client side. You have to be careful. It used to be an ASP.NET, it used to be on the server. Now it's on the client side. So you have to be a bit aware of what you add and when to add it. So yeah, understand that the facade is something you have to live with. That layer of abstraction is something you cannot live without. But in order to add it... You're paying a small cost there, you know, an extra cost, right?

 

Yeah, you brought excellent points in. I completely agree that this is a conceptual decision. I don't think that either route is the right one. I even

 

There's

 

have,

 

no right or yeah,

 

yes, exactly.

 

there are multiple solutions to the same problem, you know.

 

Yeah, I myself

 

No, doing it my way

 

even.

 

is the right way.

 

But

 

Yeah,

 

Chuck,

 

okay, we're gonna do it the child's way.

 

That's

 

just

 

right.

 

to be sure, your way is also my way, right? Just checking.

 

Yeah, I'm not sure.

 

How much you gonna pay me?

 

But yeah, I haven't talked about that before, I think, besides internally with my team, but we even have a problem which is, well, could not be a problem, could just be a lack of synergy and then we have to look for people and companies that have synergy with our thought process which is... most startups cannot, it doesn't make sense to them to hire us. Just because the way that we think about software, even starting from scratch, is always thinking about how it's going to grow and keeping the same level of speed in the development cycle all the time. So doing it in a way that tech debt doesn't accumulate. such

 

Mm-hmm.

 

that our velocity decreases dramatically over time. So when needed, for example, we're super close to a release and we need to release something and we only have two weeks, there's not enough time to do the best code ever. Okay, we may get some tech depth there, but we will be sure to refactor that before we go on to other features afterwards. But we always have this care about how it's going to scale later. And... To many companies, this is just not the most valuable thing to them. To some companies,

 

Yeah.

 

you actually need to move faster. Like, even besides that, the whole approach that my company has, which is really try to understand your brand, which most startups don't even have a brand defined yet, so we would have to help them define that. Better understand your business strategy, which some startups need that just because... for them to go after investors. They need to have some kind of business strategy, but sometimes it's not that well developed. So we try to gather all that information so that we make sure that the product that we create actually gets users to the startup, actually gives them what they need, actually makes them compete with the alternatives instead of just coding without

 

Hmm.

 

considering the whole scenario. But we ran into a problem which is, that's not the language of most... startup

 

Yeah,

 

founders,

 

business

 

right?

 

people.

 

The language is go fast.

 

Different.

 

If you want to go fast

 

Hahaha.

 

and iterate super fast, there's no... I mean, do you want me to do a brand strategy that is going to take two to even four, maybe more months to do it completely? You're crazy, you know?

 

Yeah.

 

So,

 

No, look, this is Benton

 

yeah.

 

now. So how many people in your company exactly?

 

Right now we are at almost 20 people, so I can't

 

20

 

say

 

people.

 

the

 

So

 

exact

 

when you

 

number.

 

approach, yeah, so the developers, they all developers that work on certain projects, right?

 

not just

 

Do you

 

developers.

 

approach, do you approach your front end, your startups saying that we have 20 developers work on it?

 

Oh, no, no, no. I mean, the sizes of those companies that have this issue with going faster, it's usually like less than 10. Sometimes as the founder, maybe they are even starting to consider the first

 

Yeah.

 

front-end developer. So they want to hire us so that we can do the front-end development to them and maybe they don't even have anyone because our specialty is front-end development.

 

Hmm.

 

So sometimes they don't even have anyone in front of them. So they talk

 

Mm.

 

to somebody, to a freelancer or any other company that promised a faster MVP. And then what we say is, no, I don't think that just a functional

 

Maybe

 

MVP is gonna,

 

the

 

yeah.

 

thing is maybe you should approach them as a freelance company. Like you can say that we have one person to work on it and he's gonna do, because I mean, come to think about it, one of the major reasons of slow development is communication really. I have two or three people, I lose time by just communicating between myself and the other guy. If I usually when I create MVPs, it's myself on the front end and the business analysis and the UX and the design. And then the guy is the API. I sometimes even give him the API signature, tell him this is the API, just develop it. This way it's much faster.

 

much faster.

 

So if you approach your clients saying, this is what we're gonna have, we're gonna have a single person doing it, the problem would buy it because at the end of the day, business owners, they don't understand technology. They don't understand that down the road, they're gonna have to have a technical, they don't understand the whole term of technical debt. You have to give it to them in terms of numbers. You have to tell them like, we can create a tomato today. For example, I'm trying to come up with an example at the top of my head. We can create a tomato today. And later on turn it into a sauce and it's not gonna taste so good, for example. Or we can juice the tomato now, but it's gonna take a little longer, but it's gonna end up as a tomato sauce. So you see,

 

When

 

so

 

you said

 

for them.

 

tomato, I thought there's not a chance that a good analogy is going to come but that was actually a good one. I wasn't expecting that.

 

I just come up with something, just came up with something. But the thing is, yeah, you just, you have to, I mean, I've dealt with a lot of startups and they're all business people and they all want something done yesterday.

 

Yes.

 

They just have to negotiate with them, you know, come down to their level and tell them, you know what, these things that you're asking for is going to take four weeks. If they ever ask, say, well, I want them in two weeks, I have

 

Ha

 

a deadline.

 

ha!

 

You don't tell them,

 

Hahaha

 

well, I can do it in two weeks. What you say is that I can cut half of the features and deliver in two weeks. So at the end of the day, they're gonna say, no, I'll just find someone. And it happened to me a lot, by the way. I will find someone faster. Six months or a year later, they come back to me saying the project is crap, please redo it. It happened a lot of times to me.

 

This is what

 

So

 

It's

 

you're

 

I

 

happened

 

don't

 

gonna

 

to

 

have

 

like.

 

me

 

a little

 

too.

 

bit of patience. It's a story of our lives, right? But yeah,

 

Yeah.

 

I mean, when it comes to business people, they just don't understand these terms. You have to make it simpler to them, I guess.

 

Yeah, I was freelancing for like six years and

 

Yeah.

 

usually it wasn't, I want all these features done in this timeframe. It was just, you are really dang expensive, right? And so they'd

 

No.

 

go find somebody on

 

Yeah.

 

a pork or something. And then, yeah, they'd come back six months later. So it sort of works, but it's mostly a complete disaster, you know.

 

Yeah, I don't know how to fix that. Is there a way to fix that? It's like maybe we should give them examples of look this guy did the same mistake they... I mean now he's

 

Yeah.

 

crying, please don't do what he's doing. Yeah,

 

I don't think that would

 

Yeah.

 

work because

 

maybe that would not work.

 

there's always this feeling that, oh, nobody will work with me, it's going to be different. I think that even

 

Ah!

 

though we have this problem, you know who has it even stronger is designers. Oh man, it's so hard, so hard.

 

Yeah.

 

And

 

Yeah.

 

as soon as we... Because we offer front-end and due to offering front-end, our specialty being front-end, we also do design. So design is even harder because you just cannot say yes to many things that the client wants. Just

 

Mmm.

 

for the sake of everybody. Like if you say yes to what they want and it's a bad decision in terms of UX and UI, first, you won't put that in your portfolio later because you will just want to forget that this ever happened.

 

Right.

 

Yeah.

 

Second, it's... it's not going to provide them value. They're going to like it, which is something that people think is good, but it's actually a mistake in my conception because what you need is for the client of your client to like it. And so

 

Mm-hmm.

 

the difficulty that we have is always to communicate that to the client, which is you're hiring us not to do this for you, but to do

 

Mm.

 

this for your clients. So the goal of what we do is for your target audience. You are not the target audience. And then we lose a lot of clients with that, but I also feel that the clients that we do get are the ones that appreciate the same things that we appreciate. So it's not a constant conflict. I wasn't able to do that earlier in my career. In the beginning, you just got to accept the things that come to you because... I mean, you need money to survive,

 

Mmm.

 

but I definitely recommend to all the developers and designers listening this. If you are unhappy with the quality of clients and projects that you're taking, I would say make it clear to the client what is the problem. And if you are in a good financial situation, don't take the project if you don't agree because... If you are already in a senior position, you are allowed to do that because you will eventually find a project that either they are making good decisions or they trust that you can make

 

Hmm.

 

better decisions than the ones that they are

 

Mm-hmm.

 

making.

 

So, go ahead. No, go ahead.

 

We have a saying in Arabic that goes like this. It goes, tie the donkey where its owner wants it to be tied. And they used

 

Uh

 

to

 

huh.

 

tell me that when I used to design at the beginning of my career as a freelancer. And I keep arguing that this is not the right way. They would say, just tie the donkey where its owner wants it to be tied. And I said, well, if he wants it donkey-tie-er, you should go find someone cheaper than I am, because I am not that cheap.

 

Right.

 

So eventually, yeah, I mean, you have to learn. When I was starting out, I was freelancing on the side. So I did turn a lot of jobs that way. People keep telling me, I want it that way. No, this is not the right way. I want it that way or you're fired. Well, fine, I'm fired. That's it. But as

 

Yeah.

 

I grew up, I was a bit more opinionated. My clients know me. They know that when I say, this is the way it should be done, they cannot trust me, I think.

 

Yeah. I think now is a good time to mention that I am actually planning to bring back the freelancer show

 

Oh really?

 

in January.

 

Yeah.

 

Yeah. So, we had a freelancing show that ran for like six or seven years and then the hosts all moved on and we put it on hiatus, but I'm looking to bring it back and I'm looking to add some content for freelancers to top end devs membership. So

 

Yeah? Keep me, keep

 

keep

 

me...

 

an eye out for that. But yeah.

 

Yeah?

 

Oh,

 

Alright?

 

you already

 

Cool.

 

restarted that, that was episode one. So we're back.

 

Okay. Yeah.

 

Well, if I restart Freelancer Show, I think I'm episode 398, something

 

Wow,

 

like that.

 

398, 400, 400

 

We

 

Yeah,

 

gotta

 

almost

 

episodes.

 

do

 

400

 

at least two.

 

episodes of that show.

 

Yeah.

 

Yeah. I gotta go

 

So,

 

fetch it. Is it on podcast?

 

yep,

 

Is it on Google

 

yeah.

 

podcast? Yeah, I'll go fetch it.

 

Yeah, you should. There's a lot of stuff

 

I should,

 

there.

 

yeah.

 

I'm going to kind of push us toward wrapping up, but before we do that, is there anything else that we wanted to discuss as far as the state management stuff goes?

 

Well, there's one thing that I want to mention, which you kept raising, which is about the data storage. And again, state management is not about data storage. State management is when you have a lot of things on the screen and you have a lot of listeners and a lot of data pool in the middle that controls

 

Mm-hmm.

 

all those listeners. And

 

Right.

 

that problem came up with the SPA along with the SPA. But it doesn't do data storage. manage data on the client, not even in NGRX. You have to create your own solution. So the state management is not about data storage. That's the one point that I needed to mention.

 

Now that makes sense.

 

I like the phrase that you sent to us before the podcast so that we could prepare. So I am just paraphrasing Ayash here. This is not my statement. She wrote this beautiful phrase, which is, state management is not about multiple users seeing immediate updates.

 

Exactly,

 

It's about

 

yeah.

 

a single user with many screens and a pool of data. I think this is...

 

Yeah.

 

great thing to keep in mind because people do forget as soon as you start talking about, oh, this is going to make your application more reactive, it's going to be like real-time. You say that and they visualize Google Docs and people editing at the same time. So this is not

 

Mm-hmm.

 

Exactly.

 

necessarily that. It is necessary if you want to have that. I cannot imagine you writing a good... application that multiple users can edit real-time without a good state management. So I think it is a requirement for that, but it's not what is going to give you that necessarily. So it's a step towards that direction.

 

Yeah. Yeah. So, just one example to just to put that into perspective. If you talk about the WhatsApp threads, for example, if you have a message between two people talking on the same window, you don't need state management because the screen is right there. You just keep appending messages. But because you have multiple threads, things happening behind the scenes, threads are being appended to you. You're not watching, as a user you're not looking at the same thread. That's when you need state management because now you need to jump from one thread to the other and threads have to be aware of what's happening without you watching. That's state management. But the fact that two users are talking at the same time with an open socket, that has nothing to do with state management. That's a different solution. It's like another solution that plugs into the state management. So yeah, I just keep that example because I sometimes confuse. open sockets with the state management. The WhatsApp example is one good example for that. Alright, so I think I just mentioned

 

Yeah.

 

everything I want to mention. Is there anything

 

Alright, good

 

else

 

deal.

 

we can talk about?

 

Oh well, I think the most important one now is, how can people hire you, Hayash? Ha ha.

 

Hmm.

 

Oh yeah.

 

Oh my God, the story of my life. You know, the last year was a bit slow, to be honest. I've been trying to get freelance work. I have a LinkedIn profile, I have a website, ayash.tech. And I put up my portfolio, you know, because I am the designer, you can expect that the design of my design is not so good, so I don't keep up with it, you know? I have, so if anybody wants to speak to me about any idea, has got an idea in his head, Ayash the tech, is my website. I have my phone number there, my email, all my contact details and all the information that a person needs to just contact me. Let's talk, I mean talk is free,

 

Yeah.

 

let's talk, yeah. Yeah.

 

And that's Iash, that's A-Y-Y-A-S-H dot tech, right?

 

Yep, yep, that's it.

 

Okay. We'll also

 

Perfect.

 

put a link in the show notes just so that if you drive in and you can't jot it down,

 

Thanks.

 

right,

 

Thank you.

 

you just click through. All right, well, yeah, are there other places that people can just, you know, do you tweet or post to a Facebook

 

I do

 

page

 

and it's

 

or something

 

all there.

 

with your stuff? Oh,

 

Yeah, it's all there

 

it's

 

on

 

all.

 

Iajda Tech, but mainly I keep a blog on garage.sikrab.com, S-E-K-R-A-B. And my Twitter is Sikrabbin. So two B's there, Sikrabbin. So I'm going to go to the next one. I'm going to go to the next one.

 

Okay, if you can put all of the links to this stuff in the collaboration forum, we'll make

 

Okay.

 

sure it ends up in the show notes.

 

Alright,

 

Yes.

 

thanks.

 

I'm gonna push us toward picks, but Lucas and I were talking after the last episode and we decided that we're gonna add a promo segment, right? So this is the stuff that we're working on, right? Because I always blend it into the picks and then I ramble on for 20 minutes. And so

 

Ha ha ha

 

I'm gonna try and keep it real short and just let you know what's coming up, if that makes sense.

 

Are

 

Lucas,

 

you?

 

do you want to go first and just let people know

 

Sure,

 

what you've

 

thank

 

got

 

you.

 

going on and how they

 

Yeah,

 

can find you?

 

okay. Well, first off, just to add something to Ayesh, she has awesome posts on Medium. She has a lot of posts and she has very little audience there, which I think it's totally underrated. So if you are a Medium reader, go check out Ayesh on Medium. Be sure to follow her because she posts a lot about Angular. She has even... posts about SSR on Angular, great article. So make sure to follow her. Let's increase that following because she deserves that for the quality content. And also adding on what Aish said, if you want to hire me, so if you want the other side of the conceptual idea, which is you're starting a company and you want like a more robust idea. So... We always dedicate squads, so we are not individual developers. We are always going to dedicate a tech leader and a product designer just for your project. So this is the way that we organize things. This ensures that we can move faster and without eating too much tech depth along the lines. Even with that structure, which seems very expensive, we can still keep things accessible because we are in a different country with weaker currency so we can still keep that accessible for

 

Yeah, me too.

 

European and US markets. Awesome. So yeah, if you want to hire iAsh, you can go to iash.tech. If you want to hire my company, you can go to unvoid.com or if you want to see other content that I'm producing in terms of Angular or web development in general, you can do so on lucaspaganini.com. So yeah, I think those are the main things that I'm promoting. So rock on Chuck.

 

Nice. So today is the first call for the Top Endeavs membership. And I'm pretty excited about what we've got going. So I realize that you're listening to this after the fact. These meetups are already over with, but we're going to keep doing them. Right. So I'm just going to throw out the ones that we're doing this week and next week. And then we'll kind of roll from there. So this week we are doing one, it's a careers Q&A. I have a lot of people telling me they're stuck in their careers. So it's like, all right, show up, ask your question, we'll get you unstuck, right? Should be really quick, kind of rapid fire questions. I'll go into as much depth as I can in a few minutes. And yeah, at this point we have a handful of subscribers. So I may just be outlining some of my philosophy on how to stay current and adventure career. during that if there's time. This evening is the first book club. We're doing Clean Architecture with Uncle Bob Martin. He thought it started last week and he tried to get into the call and then texted me and said, I can't get in. So I'm pretty sure he's gonna be on most of these. And that's pretty exciting, but yeah, we're gonna be talking about Clean Architecture. And then on Friday, I'm doing resume reviews and walkthroughs. So I'll walk through my resume and I'll review yours. So yeah, if I have people send me their resumes, That's where we're kind of sitting. Next week, I'm doing a podcasting 101, and then the book club again next Wednesday. And I'm filling in the topics for the rest of the month. But that's where we're sitting. If you want the replays on any of these, just sign up for a Top End Devs membership and you can get access. And for the book club, you can sign up for the book club independently or it's part of the membership, so either way. And finally, if you want to get a copy of my resume, you can get a copy of my resume for free. Just go to topindevs.com slash resume.

 

Chuck, just to be sure if I heard that right. So Uncle Bob, Bob Martin himself is going to

 

Mm-hmm.

 

be in the meeting. And there

 

Probably

 

are

 

on most of them.

 

still people listening to this podcast. They're still trying to decide if they're going to pay for this or not. Interesting.

 

Hopefully they're jumping on, but yeah, it's topendevs.com slash book club is where you can sign up just for the book club. If you want the full membership and things that we're going to add in there are like premium versions of the podcast that adds. I'm going to throw in extras, you know, so things that we drop on the cutting room floor or, you know, I'm putting together some other content that's just going to be paid. That'll all be included in there as well. So and then you can sign up at topendevs.com slash sign up. But yeah, the book club is $17 a month and you get four or five, you know, because we just do it every Wednesday. And we're looking at having the authors come if we can. Um, the people who are in the book club now, I talked to them about books and we're looking at doing the domain driven design by Eric Evans next. And so I've reached out to Eric to see if he's interested in coming. So anyway, um, that that's. But yeah, that's what we got. And yeah, Bob is probably gonna be on these calls. So we've gotten to be pretty good friends over the last year or two. So yeah, anyway.

 

It's amazing. It's amazing.

 

Yeah. All right, well let's do picks. Unless, Ayash, do you have anything else you wanted to promote other than, hey, hire me, go here?

 

Ha

 

No promotion,

 

ha

 

no, that's it for me.

 

Okay.

 

Thank you guys.

 

All right. Uh, Lucas, what are your picks?

 

My pick is the webcam that I'm using now, which is a Logitech Brio. This webcam is a bit expensive. I don't know how much it costs in your country, but here it was $200. So kind of a bit too much for a webcam, but I got to say that I don't regret like even one cent that I spent on it. The level of detail and the HDR sensor that this camera has is amazing. And it really brings another level of professionalism, especially if you do a lot of client meetings, if you do remote work for life. So we were talking about freelancing life. If you are a remote developer, remote designer, you've got to invest in your image, because every single thing... amounts to the value that your clients see in you. So this might look like a small thing, but if you have a good lighting, a good setup, a good audio, a good camera, you speak well, you look directly in the eyes of your client or in the eyes of your camera when you're talking to them, this really creates a whole set of qualities that when you give your price, it all seems justified for the level of professionalism. So I really recommend for everyone working remotely is Logitech Brio. And Logitech is not even paying me anything, they should, because that was a great promo.

 

hahahaha

 

So Logitech, if you're hearing this, come on, like give me a referral code or something at least. But yeah.

 

Yeah. My webcam is a Logitech as well, but I think it's the C920 or something. Anyway, the Logitech Brio is $130 US on Amazon right now.

 

I have two picks by the way. I thought you want

 

Yeah,

 

to promote some of it.

 

go ahead.

 

Yeah, I have my own picks as well

 

Yeah.

 

I keep this book like next to me all the time. It's called the Peter principle I mean, I've probably told you about it. It's a book that was written in 1970, but everything is still holds valid It's very in simple terms. Every employee tends to rise to his level of incompetence They

 

Ha

 

he

 

ha ha

 

talks

 

ha!

 

about the hierarchy of a career path because that's something I always opposed. A career path. Every time I am like a good developer, they wanna promote me to become a team leader. But once you do that, you have to have a different skillset. And then they promote you a little further into becoming a manager and a completely different skillset. You're a great developer, you're a very bad manager. You're stuck there because they're not gonna promote you any further. That's it, you're stuck at the worst level you can be. That's the hierarchy. So that book is really good. I mean, it still holds. That's what I like about it. It still holds until today. The other book I wanted to talk about is because I like autobiographies. There is this writer named Alex. It's Veltana Alex, her name. She's a Russian writer or Ukrainian writer. She has a Nobel Prize in this genre. She has a book called Secondhand Time. And it's short stories or short autobiographies of hundreds of people who call themselves ex-Savvies. You know, the people who have run through the fall of the USSR. They were once Savvies. The next morning they were not. They were in different parts of the world. And she gives those small short narratives of each one of them. It's a great book. And I think she got a Nobel Prize for them. So that was, I wanted to share with you because I read this recently. It's one of my favorite books already. Yeah.

 

Awesome.

 

Thank you.

 

I love

 

Alright.

 

So,

 

a

 

all

 

phrase that

 

right.

 

resumes the Peter Principle. It's a great and funny phrase which is, people

 

Yeah.

 

get promoted to their highest level of incompetence.

 

So this is level of incompetence, you know? Ha

 

Yes.

 

ha

 

Yeah.

 

ha ha ha

 

Yep. You're

 

Yeah

 

good at this. We're going to promote you into a job that you're not good at.

 

Exactly.

 

Yep.

 

Yeah. I'm not gonna say more than that because I'll hurt people's feelings.

 

Ha ha ha

 

I'm gonna

 

ha

 

dive

 

ha

 

in with some of my picks here. The first one, I do a board game pick every week. And this week I'm gonna pick Camel Up. It's a, you basically, you bet on or own camels and you, or both, and you know, they're racing and it's dice rolling as to how the camels move. So sometimes your camel will be way ahead and then it's not, right? Because it just didn't get rolled. And you get bonuses if you roll camels that you mown and stuff like that. It's a lot of fun. I've only played the 2014 version. I haven't played the 2018 version. They do look like they are a little bit different. The 2014 version... is On board game geek it's rated at 1.47 so it's an easy game to pick up, easy game to play. 20 to 30 minutes you can play up to 8 players which is nice. I've probably played it with 6 or 7 people and it's fun. So yeah, I'm going to pick that. And then... or something else I was gonna pick and I can't remember what it was. My wife and I went and saw Wakanda Forever, which is the new Marvel movie. I have to say, we went and we were a little bit worried because we had gone and seen the Doctor Strange movie and we saw the Thor Love and Thunder movie and we didn't like them. We just didn't, they weren't great movies at all. And so we were like, okay, are they making crappy Marvel movies now? Wakanda Forever was good, right? It wasn't as good as Black Panther, but it was good. And so if you're looking for kind of a flick that you can go see and suspend disbelief and enjoy and whatever, I'm sorry, for all the Marvel movies, there's just suspension of disbelief and there are gonna be continuity issues. But if you can look past them, I enjoy the movie. So I'm gonna pick that as well. And then I'm excited for The Yellowstone, season five. But I haven't been able to watch any of it because I'm watching World Cup. So

 

Oh yeah.

 

yeah,

 

Brazil is gonna

 

Brazil,

 

win, right?

 

Thank

 

Brazil

 

you!

 

is kicking butt

 

Yes!

 

and taking names.

 

Yes! Ha ha!

 

Uh, the U S got eliminated unfortunately,

 

Yeah,

 

but,

 

Morocco

 

uh,

 

won yesterday, just a historical win yesterday.

 

Oh really?

 

Yeah, it was like

 

Yeah,

 

the first

 

I'm

 

time

 

a little bit

 

ever.

 

behind.

 

Yeah, it was unbelievable. They won over Spain, which was like

 

Oh wow!

 

unseen. Yeah.

 

Yeah, yeah.

 

So, Spain's out, Morocco's in. It's just unbelievable.

 

I'll have to watch that. Yeah, I know that France

 

Watch

 

and

 

only

 

England

 

the last...

 

are teed up to go at each other. That'll be fun.

 

Yeah, yeah. I'm looking forward for that one.

 

Yeah, yeah, those are two of

 

But

 

the

 

Brazil

 

teams that

 

is

 

I'm

 

gonna

 

rooting

 

win.

 

for.

 

Let's

 

So

 

just

 

yeah,

 

face it. Yeah. Let's just admit

 

Yes.

 

they

 

it.

 

have a terrific

 

Brazil

 

team.

 

is gonna take it. Yeah.

 

They trounced South Korea.

 

Oh,

 

And

 

that

 

we

 

was

 

even

 

like

 

played

 

a one time.

 

nice. We even played nice in the second time. So we just did

 

Yeah, yeah, exactly.

 

our goals

 

I

 

in

 

noticed

 

the first

 

that. It's

 

time and

 

like

 

we were like, that's enough, that's enough.

 

polite.

 

We

 

That

 

don't

 

was

 

want to

 

polite.

 

make enemies.

 

Yeah.

 

Uh-huh.

 

Let's stop here.

 

Yeah, it should have not stopped because Portugal yesterday had six goals. So you should have not stopped. Learn not to be polite.

 

That's right, beat em 10 nothing. Anyway.

 

Yeah. All right.

 

But yeah, so I'll shout out about that too. I've been telling people

 

Yeah.

 

this tip. The replays are free on the 2B app that's T-U-B-I. That's what I've been doing. So I've been watching replays. I haven't been watching any of the games live. Just cause I'm cheap and I'm not willing to pay for a subscription service for a month just so I can watch them when they're on.

 

You

 

Cause

 

are me

 

I

 

though.

 

usually can't watch them when they're on anyway.

 

Yeah.

 

But yeah. All right, well, thanks for coming, Ayash. This was

 

Thank

 

awesome.

 

you. Thank you for having me. Thank you. All right. Thank

 

And

 

you for having me.

 

to you Lucas. Okay.

 

Thank you, thank

 

Hang

 

you

 

tight

 

for...

 

for a second so we can get you uploaded.

 

Okay.