We're definitely making a good use of the Angular HttpClient--as would be expected from any decent server-side fed SPA. Although it's not advisable to waste too much space talking about it, we should definitely spend a few words on its new abstraction pattern based upon Observables. One of the most relevant differences with the previous approach is that Observables have a lazy behavior by design, meaning that they won't fire unless there is a valid subscription issued by a .subscribe() function call.

This is a major perspective switch from the AngularJS Promises, that will execute right off the bat, regardless of how the client code will use their result afterward. Another important difference involves the .subscribe() function, which will be fired upon completion of the add task of ItemService. In Angular, subscriptions are designed to work just like a standard .then() or .complete() function featured in most async-based JavaScript libraries (AngularJS/Promises, JQuery/AJAX, and so on), with the key difference that they are also bound to the Observable itself; this means that they won't just trigger once and resolve, but they will be executed each and every time the Observable completes its task(s) until it ceases to exist, unless they get cancelled by calling the .unsubscribe() function method on their Observable.

That said, we can easily note that the minimalistic HTTP requests we've been implementing are hardly a good example to demonstrate the advantages of this behavior as most of these Observables will fire only once; to better see the difference with the previous approaches, we will have to implement some truly reactive functionalities such as Search with Autocomplete, Websockets, Push Notifications, Instant Messaging, and similar stuff.