Transcript from the "Server Communication" Lesson
[00:00:00]
>> We've seen services, but ultimately, for something to move from being trivial to non-trivial, we need to be able to communicate with a remote server. So in the grand scheme of things, the question is, where is the single source of truth? Well, in a non trivial application that is not in your particular instance of a front end application.
[00:00:33] Is that ultimately the single source of truth is in your data layer at the server. And so we need to be able to communicate to the server and when we update something, it needs to go to the server or if something has been updated, we need to be able to fetch it.
[00:00:51] So we're able to do this with HTTP client, which comes within an HTTP client module. And the upside to this is that the API for this conveniently maps to restful verbs. And this is one of the reasons why I like Rest. It's certainly not perfect, but one of the things that I like about Rest is that it is very, very conventional.
[00:01:26] And you can through the verbs, communicate a lot of intents. So when we're looking at http client we can call Get, Post, Put, Delete which are typically the ones that I use but also Patch, Head request. And so they're essentially mapped to the Rest verbs. So if you wanted to get something it'd be http.get and so this is assuming that HTTP is an instance of HTTP client.
[00:02:02] If you wanted to create something I use Post, if you want to update something, typically I'll use Put or you can use Patch, or even Post if you want. I use Put but you can also then if you want to delete something, you can use Delete. And what's interesting about HTTP Client is that the response itself is an observable stream.
[00:02:32] And so we can finalize that by subscribing to it or we can pipe this right into our template using the AsyncPipe. So we can see here Get and so we're calling, let me just back this up, we're calling load items which has this http.get. And then we can unpack it in the component, which, for kind of a transition step or skill acquisition step, this is fine.
[00:03:06] But ultimately, what you will end up doing is more than likely piping this into your template via an AsyncPipe. A few things worth pointing out is that you have the ability to modify the headers of your request. This is pretty important when you are doing things like a big one is the authorization bearer or the token bearer.
[00:03:38] So if you have a authenticated against a remote server and they've given you a JavaScript web token that typically you will put this in to your header. And then pass that back so that it knows that your call is valid based on the token. But also not uncommon to set occasionally I've seen where servers the way that they're wired or they're set up you need to be very explicit about the content type.
[00:04:15] This is also interesting, in this particular, example I was using this to essentially upload a large file to s3. And this is why I have report progress and observe set to events so that I was able to kinda track the progress as it went along. Now, we can also use the catchError operator, well, to catch the error.
[00:04:49] Self documenting code for the win. And so typically kind of what I do is, I'll create like a general error handling method that processes the error internally while using or servicing a user friendly error like throwError. So, What this looks like is if you catch an error, you need to figure out what you're going to do with it.
[00:05:20] And what you definitely do not wanna do is just be like, we got this response from the server and then just make it available to anybody to see. That is, it's a really easy way to leak sensitive data as well as it can create a sub optimal user experience.
[00:05:45] So a lot of times if something goes wrong like a user doesn't need to see like a Stack Overflow. What they really wanna see is what happened in friendly terms, and then more so, what do I do about it? So, this is where if something goes wrong in a remote call, is that I'll use catchError to handle it, but then I'll decide, what am I going to do about it?
[00:06:15] Possibly even remote logging or something, but then I'll use throwError to essentially return an observable with a kind of a friendly user facing error message. So just a little bit of kind of some strategies therefore, you wanna catch something and ideally you handle it as close to the metal or the error origin.
[00:06:43] At the same time you need to surface something to the user that is appropriate depending on the situation. And so here you, can see I'm calling load items and we've caught an error, so we're going to handle it over here. And we're going to do something it kind of the local level, but then using throwError we're going to surface something that is user facing and friendly.
[00:07:16] All right, so before we get into component driven architecture, let's go ahead and let us see an example of what this looks like.