11

Essentially, what the title says, is there any reason to use an observable over a promise for the purposes of making http calls? Seems like needless overcomplication, since all the call will do is succeed or fail, and there is no real reason to cancel it, virtually ever. Asking this for the typical use-case, not for the typical observables sales-pitch of debounce (which, ironically, ng-debounce does just fine anyway, without making useless calls).

Community
  • 1
  • 1
VSO
  • 11,546
  • 25
  • 99
  • 187

2 Answers2

9

There is a huge advantage of observables that is quite relevant here.

Observable supports cancellation while Promise doesn't.

Using subscribe() and map(), instead of then() doesn't seem to add much complication to me. You can also use toPromise() to get a Promise if that is what you need.

See also Angular - Promise vs Observable for more details.

Also if FRP style of programming is used it's handy to get an observable everywhere. If that is not desired just using toPromise() gives a Promise and the slightly simpler API.

Community
  • 1
  • 1
Günter Zöchbauer
  • 623,577
  • 216
  • 2,003
  • 1,567
  • 3
    agree, but once you subscribed to the stream you can't chain any async function to add a behaviour after the resolution. To my mind, the observable aren't the best choice for http calls, they lead to boilerplate creation when a simple promise is enough and can be chained. – Polochon Nov 02 '16 at 13:18
  • Just use `map()` instead of `subscribe()`. You also can use `toPromise()` and then you get `then()`. With observables you just get everything while with `Promise` you only get parts for no noteable benefit (IMHO). – Günter Zöchbauer Nov 02 '16 at 13:22
  • 1
    Also building in some resilience by [retrying](https://github.com/Reactive-Extensions/RxJS/blob/master/doc/api/core/operators/retry.md) failed requests is much easier. – JayChase Nov 02 '16 at 13:25
  • @GünterZöchbauer Why don't you juse use a promise, if you call toPromise? – VSO Nov 02 '16 at 13:28
  • By using toPromise you're using a promise ^^. I never said that you should'nt give up the observable, just transform them into a promise for an http usage. It's really more valuable. Btw, with a map you can't handle clearly an error. – Polochon Nov 02 '16 at 13:30
  • For error handling you have `catch()` and `finally()`. – Günter Zöchbauer Nov 02 '16 at 13:31
  • 1
    Promises, at least from reasonable libraries are cancellable. Not to mention promises were cancellation-aware in Angular 1. – Benjamin Gruenbaum Jan 15 '17 at 16:29
  • Any reference to more information? https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/Promise doesn't mention cancellation. – Günter Zöchbauer Jan 15 '17 at 16:30
  • Sure, for example: http://bluebirdjs.com/docs/api/cancellation.html . I'd argue the correct primitive for this task is actually an async iterator (pull based, actually lazy and awaitable). – Benjamin Gruenbaum Jan 15 '17 at 16:32
3

The very basic difference between promise and observable is Observable module will not work if no functionality subscribed to it. Hence less burden to your server.

Where as in promise, whether you are truly utilising the response or not, it will send you a promise object after pinging your server with your request and payload; Which sometime undesirable.

The funda is to decrease the load of node or other server.

Jyotirmay
  • 1,533
  • 3
  • 21
  • 41
  • 1
    In what instance are you setting up an angular http call without using a response? That doesn't make any sense to me. I understand lazy loading, but not how it's applicable here. Not trying to be rude, just really don't see why people bring this up as an argument. – VSO Nov 02 '16 at 13:27
  • 2
    This doesn't mean that the request will be sent but the response ignored. You can have a chain of different methods that build an observable with `map()`, `filter()`, `replay()`, `flatMap()` and whatnot, but you might for whatever reason decide, that you don't want to make the request at all or sometimes later when some condition is met. This is like an SQL query that you can prepare and build in advance and send only on demand or repeatedly. – Günter Zöchbauer Nov 02 '16 at 13:38
  • If two ifferent clients subscribed to it - it will work twice, and it will defer the call until you actually need it. – Benjamin Gruenbaum Jan 15 '17 at 16:27