Data Modeling

[00:00:00]
>> So as we endeavor into making angular applications work, so we're in this make it work segment of the workshop. It's really important to talk about the angular CLI and nx workspaces and I'm operating under the assumption that everybody understands. What a COI is a command line interface that you're able to do meaningful units of work from the command line.

[00:00:28]
And in Angular c li, it's very good at generating a single application annex workspaces. Extends that and allows you to generate more than one application and organize that in way you can start to share a code. Across those applications and you can also leverage a number of kind of these custom, I would say super powers that they baked into- Annex.

[00:01:01]
And so we're going to see this in a moment as we start to, or as we create an application using NX and the angular CLI. But before we talk about, or before we get into the angular CLI and Ennis workspaces, we have to talk about Data Modeling. And this is incredibly important because I've seen even the best developers have their applications go off the rails.

[00:01:39]
Because they did not have consensus on the data model and when you understand the data model for the domain that you are working in. Then it is very easy for you to make inferences or assumptions or to know what the rest of the application is going to look like, for instance, if I showed you A.

[00:02:17]
One second here. For instance, if I showed you a data model for a user and the user had a first name. A last name an address and any number of things that you would attach to this user. Then you can have a pretty good idea of what the form is that what the form would look like for that particular data model.

[00:03:04]
And so let me go in here real quick and this will take just two seconds and I'm going to just up this font. As you know what, let's do this a little bit differently so abort we'll just go into VS code and I'm just going to create a new file.

[00:03:24]
So let's say I want to create an interface for a user and I'm just going to add a few properties to this. So user and we're going to go first name, string last name string and let's go title, string, description string and let's go active, which is gonna be Boolean.

[00:03:56]
All right so based on this code here we have a pretty good idea what the user interface is going to look like for manipulating this particular interface. Let's walk through this so first name we're going to have an input field last name input field title. Probably an input field description we might have a text area and then active what would that be?

[00:04:27]
Well, it would be probably a checkbox or a toggle button but when we look at this interface, we have a very, very good idea of what the UI. Is going to look like for this particular interface not only that is we have a pretty good idea of what the REST API is going to look like, as well.

[00:04:57]
So we go here we know that because we have a user interface, we're probably going to have a user's end point. And from here, we also know that we're going to be able to send a couple verbs down the pipeline to get things so. If you go get, and this is just freestyling here, we're going to get all of the users.

[00:05:25]
Or if we go get, and we have an ID, we're going to get a single user and if we go I'm like, delete same thing there we go again. And we understand what the API is going to look like and we can for instance, if we want to update something we can do put.

[00:06:03]
And then we can pass in the user we want to update not only that is we can understand what the rest API is going to look like. But we also understand what our HTTP service is going to like that's going to interact with that. And if you're using in grx, you know what the actions are going to look like what your reducer is going to look like.

[00:06:30]
You know what your effects are going to look like selectors and so on and so when we talk about building scalable production angular applications. And we talked about complexity being a major component for that we have to talk about and address that. If you understand the model, then you're going to understand the shape of the entire application.

[00:07:06]
From the user interface all the way down to the API and so what I want to challenge everybody that is participating in this workshop. Is he as you start to write angular features, start to pay attention to this slices a functionality that you have in your application. And how these patterns start to repeat themselves so, for instance, if we had a widgets service and we wanted to introduce an item's feature.

[00:07:47]
And we understood what the items interface look like well, we have a pretty good idea. What the items service is going to look like in relation to the widgets service and you can carry this pattern on and on. An on now, one of the reasons why I'm saying this is because one, it allows you to orient your application.

[00:08:15]
And stack it up correctly, and then you can stack your features up side by side correctly. But if you are working on a front end team and you have a back end team that is responsible for the API. And I've seen this many, times dozens of times, where you have a hard dependency.

[00:08:39]
On the back end team to produce the the API that you're going to consume. And so the front end team has done the API team is not normally this would be a blocker. Except if you have an agreement on the data model, then you can go ahead and mock out that API.

[00:09:01]
And because the model is the same that, you have broken that dependency, by mocking out that API. And you're able to develop your application, finish your future work and when the API is ready, you just switch, to, the new API. This is one of the reasons why I said state management, and server, communication should be decoupled, is because I have seen.

[00:09:27]
Applications that were on the verge of failing, because the back end and the front end team were so coupled together. And dependent on work that the back end team wasn't doing, because maybe they were overloaded or whatever. But when you can agree on the data model, and mock that API out, and you have proper separation from your server communication in your state management.

[00:09:47]
You drop in that mock API your application works. When you real apis done you point it to a new URL and more often than not it just works. Now third and final point before we take a break is that because we can infer a lot of information and the shape of an application based on the model.

[00:10:12]
This allows us to accelerate our development via the COI and nx and so this is what we're going to see is we're going to see today. We're gonna sit down, we're going to write an apa and it is going to, in a matter of a couple hours. I will do the amount of work that used to take me days to do how does this happen, how is this possible?

[00:10:40]
Well, it's because very clever developers have seen or noticed that when we understand certain, we understand the domain model. And we've established kind of the patterns around that we can automate all the heavy lifting via tools like the c li. So that we can focus on the most important things in an application that change every single time.

[00:11:04]
So where is the application or the complexity in an application, it's in the user interface and it's in the business logic. And I believe that 5% or that 95% of your time should be spent finishing that last 5% of your application. So with that said, does anybody have any questions about what I've just said about.

[00:11:33]
Domain models in the role that it plays in how we approach application development?
>> What techniques do you use when maybe you have to interface with a legacy API, maybe it doesn't Follow suit to newer API's.
>> So the question is, what techniques do I use when I need to integrate with like a legacy API that is possibly like incompatible of some sort.

[00:11:59]
Like there's an issue there with a, like a newer API and so basically what you have really in my opinion is you have like a data model and compatibility. If I'm not mistaken like I need to get some from a legacy API that does not match up with what I need over here.

[00:12:16]
And so there's kind of really two ways to approach that and one of the ways is, again, using kind of the facade pattern or a variation of that is the adapter pattern. And so if I need to, and this happens a lot, I'll give you another example I'm working on integrating a third party API.

[00:12:41]
And the data model from the third party API doesn't exactly match up with the data model that is in our main application and so what do you do? Well, what you essentially do is you insert a facade or an adapter in between that, that once that data comes in, then you essentially process it.

[00:13:08]
In a single place before you pass it along and so when we get this third party integration data in. What we'll do is we'll essentially loop over it, map it to the new data, and then send it in. Another good example of this is rest is awesome until it's not and by that a lot of times.

[00:13:27]
If you make a rest call, you're getting all of the data or as little of the data as defined by the API. And so there are times where I've just needed five properties off of an API. And because of the way that it was written, I get 50 properties, which in an Angular application.

[00:13:47]
If you're binding to these large, complex objects that can have performance implications. And so a lot of times what I'll do is I'll take that data model when it comes in. And I'll essentially parse it down, back to just the data that I need before allowing it into my application.

[00:14:08]
You could also even do that at the server level but to answer your question is that if you have an incompatible kind of a data set. Then typically you'll put like an adapter or a facade to kind of transform that before moving it on. And so you wanna really treat that like that that data model parity before allowing it to kinda progress.

[00:14:29]
And if you're integrating with third party API's, or whatever legacy systems you'll spend a lot of time doing that.