Transcript from the "Challenge 9: Server Communication" Lesson
>> Lukas Ruebbelke: And so what I'd like everybody to do is build out their widgets service. So start with get, the collection, but then go ahead and do create, update, and delete. I think this will take,
>> Lukas Ruebbelke: I'll give everybody 20 minutes to do this. If somebody, when you get done, just go ahead and raise your hand.
[00:00:24] And if everybody's kinda done, then we'll just, we'll kinda move on. So use the ItemService as a reference and the items component. And let's built out this container component and the service. So Sebastian on headers, any best practices or tips to handle CORS errors? So, generally CORS is an issue with the server.
[00:00:50] And so your server has to be configured to accept your call. And so if there is a CORS error, I actually wanna know about that. And so that is something I try to catch in development. And sometimes I'm just hitting an endpoint that it hasn't been configured to accept my request from my call.
[00:01:14] And so sometimes it's just a matter of calling up IT and saying, hey, can you whitelist this IP? And so generally, in development, I want to surface all the errors. And so while I'm working in development mode, I wanna capture everything and I wanna know about it. I wanna see how many of these things can I actually fix?
[00:01:36] How many of these are solvable? From there, if there was some kind of a CORS error or something happened, more than likely what I would do is capture it at the stream level. Find some way to communicate that internally. So maybe send that, like log that error to a remote server and then find some user-friendly error to communicate to the user that hey, something has happened, either try again or contact support.
[00:02:08] And so obviously, you don't wanna surface any kind of sensitive data or information that doesn't make any sense to them. And so for me, the best approach to this is you wanna catch as much of this before you go onto production. But if it is going to happen, and it will, have a way to catch that at the stream level to communicate that to a kind of a remote server that you can then go back and see what happened.
[00:02:34] So kind of communicate it through the back door like hey, this is what really happened. And then come up with a scheme for communicating it to the user in a friendly way that actually makes sense. And so that's kinda the beauty of observables is that you can capture it where happens, and then figure out what you're going to do with it right at the source.
>> Speaker 2: Is there any built in login? Cuz I mean you send it right to remote server? Or are you just kinda handle it yourself?
>> Lukas Ruebbelke: So with AngularJS, there was a dollar log, which just give you kind of some better logging options. There's nothing into the framework for that.
[00:03:18] But there is some pretty good projects that are fairly full featured in terms of logging. But, I up for Airbrake is a pretty common service. And so to that end, before actually capturing the errors themselves, I would recommend hooking up a third party service for that. So Airbrake is the one that I've used in production.
[00:03:44] Like, hey, this thing went wrong. And then what you can do using an interceptor is actually automatically capture any of those errors and automatically just push them right out the Airbrake. And then you can even configure it if something goes wrong, send me an email. Or sometimes, you just don't wanna know, I'll just go look at it at the end of the day or the end of the week.
[00:04:03] But there are certain, during launch, we've had those running and pretty much as things are breaking, we're able to capture them, but Airbrake or some kind of third party service like that.