Architecture Overview

[00:00:00]
>> When we look at this reducer, it's for courses. And so my initial course is state, and then I'm handling a bunch of different actions. So you can see here, well, what are these actions? Well, the course is actions, and they're doing corsi things like load course, create course, etc.

[00:00:23]
Well, you may not realize this, but I just switched the slide. And how you would know this is if I just go back, one is for courses, one is for lessons. And if I hold these side by side, what's different? The only thing that is different is the fact that we are dealing with two separate domain models.

[00:00:51]
This is good convention, and this is why good architecture is so powerful. And so I wanna take you on a quick horizontal tour. So instead of saying, let's talk about an application, let's talk about the features. We have the courses feature, we have the users feature, we have the lessons feature.

[00:01:12]
And this is going to set the stage for us to start to get into code. So horizontal tour. And this is around NGRX or really Redux is very, very conventional in this way as well. When you are writing your state layer using any NGRX or Redux, you have your actions.

[00:01:38]
Well, these are so simple, we don't even write test for them, but you have selectors. They're very simple, they're very conventional. You have entities, simple, conventional, reducers, simple, conventional, facade. Now, this is a hot topic, but I am profacades because it decouples the component layer from the rest of the application.

[00:02:03]
In other words, I don't believe your component layer should be coupled to the implementation details of how you manage state, different course, different workshop. But I will say this, it should be simple as it's a delegation layer. Effects, well, these are complex as it contains asynchronous business logic.

[00:02:26]
And then your initial wiring. So this is semi complex as it is initially tedious. When we start talking about CLIs, you'll see this as being the case. But think about this before I go into the next kind of version of this, where we extend this. If you have two airlines, and I know this because I've actually built an application for an airline, you have two airlines, and they have mobile apps.

[00:03:01]
What is going to change from one app to the other? For the most part, the domain models are identical because the infrastructure is the same. Guess what, they're flying airplanes into airports, and they have passengers and pilots and tickets and reservations, and so their domain models are the same.

[00:03:25]
What changes from one application to another? Two things, in my opinion, so put my thumb down. One, UI UX and your business domain logic. So for instance, Southwest has different business rules for travelers versus American Airlines. The domain models are the same, the business logic is different, the user experience is different.

[00:03:57]
For the most part, everything else is identical. The things that change from application to application is typically your UI UX and your business logic. And I propose that this is where you should spend 90% of your time in the software development lifecycle is one, nailing your UI UX.

[00:04:23]
And then building rock solid logic around your business layer. Everything else find a way to automate it, be rapid about it. Be rad about it so you can focus on the things that matter, your business logic and your UI UX. So, I'm gonna just flip through these real quick.

[00:04:47]
But what I want you to notice is that these are very, very small basic pieces of code. So actions, they're conventional. Selectors, they're conventional. Entities, these are very conventional. Reducers, conventional. And what's interesting about this is that when NGRX implemented entities, they basically borrowed directly from the Redux how they are handling it.

[00:05:18]
So, the code is very simple or similar. So entities, reducers, all together. This is, again, notice that these are very small pieces of code that are put together, a conventional facade. And so, I will point out at the top, we are executing a query on the store, so you have a clearly segmented section for your queries.

[00:05:48]
And underneath of it, we are just patching actions, which is a clear separation for your command. So command query or separation is, I think really important. And then our effects, so this is where the complexity comes in. And this can be very complex, but this is where you should spend most of your time.

[00:06:10]
Wiring, so this is typically for me that I prefer to take all of my state slices, and then put them into a single reducer that I then register with my application. So this is angular and NGRX, but these are the little things that they take a little bit of time, but they can be automated.

[00:06:31]
So in terms of a basic front end project, same thing. HTTP services, simple conventional, your container components, conventional. I like to do a list presentation component, conventional, details component, conventional. Your basic shell, well, now, we're back into UI UX. So this is semi complex. Styling, this can become very complex.

[00:06:59]
Project generation, simple and conventional. So, just blowing through these real quick, this is what an HTTP service looks like in Angular. It looks even simpler using Axios in React, which we'll see a little bit later. Container component, simple. Here is the component itself. Notice, the one thing I wanna point out is I flip through these.

[00:07:22]
Notice how small my functions are, they are fine grained single purpose functions. The reason being is that I am reducing the potential for code variants at each individual layer. This component, list component, I mean, this is beauty. I think this type of a presentation component is one of the prettiest things in the world.

[00:07:52]
I would take this home to meet my mother, that's how much I like it. Details component, Simple, so this is where things get a little interesting. So if you're building an application, it's kind of the shell of do we want something on the side, a menu? You have to start to think about those things.

[00:08:12]
And so once we start to get into the UI UX portion of it, you have to start making decisions. And rightly, so because this is what's going to delineate or distinguish your application from every other application in the world. And I think it's ironic when you are using a framework, let's say material, they'll allows you to get up and running very quickly.

[00:08:42]
The problem is that everything looks the same, and so what are you gonna do? You're going to spend and invest some time into changing that user experience into something that is a little bit more congruent with your stakeholders vision or whoever that may be. To kind of summarize this with a landing, let me stick it, that I flipped through a bunch of code.

[00:09:07]
And a lot of this is very, very small, fine grained pieces of code. And this allows us, this is the architecture that we need, is that we need to think about things horizontally, we need to write very small single purpose code. And every good architecture book in the world agrees with me on this.

[00:09:32]
And when you start to go through this horizontally, is that I could swap out just little foreshadowing. That if in this case I swapped out course with lesson, you think this would work? Would suddenly this become a lessons detail component? Think about it, you're gonna have to come back in six months for season two for me to get you off this cliffhanger, totally kidding.

[00:10:03]
But Horizontal not vertical, this approach opens up a world of possibilities.