What's The Difference Between Observable and Promise in Angular: When To Use One over the Other?

What's The Difference Between Observable and Promise in Angular: When To Use One over the Other?

They both handle asynchronous calls in JavaScript, they both promise to “rescue us from the callback async hell”, so... it's only but logical to ask yourself: “What's the difference between observable and promise in Angular then?” When exactly should you be using one over the other? And why?

And there are, indeed, clear differences in the way that these 2 “abstractions” handle asynchronous functionalities. Differences determining each one's specific use cases.

But let's not sink even deeper into confusion and find some answers instead regarding:

  1. the core differences between promises and observables (stemming from your legitimate question: “What are promises and observables in Angular anyway?”)
  2. the specific use cases for each one 
     

1. So, What Are Promises in AngularJS More Precisely? 

A succinct, yet comprehensive definition of “promise” in Angular would go something like this:

A promise handles a single event corresponding to a completed asynchronous operation:
  1. a single value (the promise resolves, for instance)
  2. an error message 

Word of caution: the most important aspect to keep in mind when using a Promise in your web-based Angular app is that you can't cancel it once triggered!

And this is, by far, the main difference between Observable and Promise in Angular! Since once initiated, your promise request can no longer get canceled, expect it — let's say it's a search on keyup that you'll initiate — to get triggered each and every time that you press the key!

… it will keep calling the success or failed callback even when this information is no longer relevant to you.
 

2. In that Case: Do Promises Still Have Their Uses Cases? 

Definitely! Don't think that, since they're “uncancelable”, you should favor Observable over Promise for all “asynchronous matters” in your Angular app.

Use Promise if/when:

  1. you're 101% sure that the request that you're about to initiate shouldn't (ever) get canceled anyway
  2. it's flat code that you need, requiring a single event (no need to complicate things)
  3. you want to leverage Promise's async/away functionality to write your asynchronous code 
     

3. AngularJS Promises: Key Features to Keep in Mind 

Now let me run a little inventory of the essential Promise features that you should bear in mind:

  • they're not cancellable
  • they return a single value only (a Promise has a single pipeline)
  • they provide more readable flat code (thanks to their try/catch and async/await functionality)

In other words: if it's just simple business logic that your Angular app contains and it's based on UI interaction code, then you should consider sticking to the simplicity and transparency of the async/await functionality that Promise provides.

You might just not want/need to get yourself tangled up in reactive extensions in this case.


4. And What's the Problem(s) With Promises?

Since we also have Observable as an abstraction for handling asynchronous behaviors in our Angular projects now, then... there must have been some problems with using Promises in the first place, right?

There are a few downsides, that's for sure. Allow me to point out the main ones:

  • as your web app grows, Promises will grow harder to manage
  • a Promise is defined where the data is created — at the source — and not where it's being consumed
  • a promise can't be retried, it can't access the original function that initiated it, and you don't want to go back to “callback hell” again, now do you?
     

5. Handling Asynchronicity with... Reactive and Functional Programming

“Wait, what? Functional programming in JavaScript?”

That's right, the functional reactive programming paradigm — FRP — is the solution for handling asynchronous data and data changes.

Let me explain now what kind of challenges asynchronicity in Javascript started to present:

  • you'd have data coming from all different sources into your Angular web app 
  • … to the point where you'd no longer have full control (or no control at all) over when this data gets sent through your app

Therefore, a more functional paradigm for software development was needed in order to make Angular apps more... predictable. So you can regain total control over the entire process where data's being transferred from third-party sources —  web sockets, user-triggered events, APIs — into your app.

And it was then that Promises stepped in, “promising” to get us out of callback hell and solve pretty much all the issues that we had been experiencing with XHRs
 

6. Understanding Observables in Angular 

Now, in order to get some straight answers to the “What's the difference between Observable and Promise?” dilemma, it would be only logical to try and define Observables first, right?

An observable is a stream —  array or sequence of events or data flow, whichever term suits you best — dealing with asynchronous behaviors.

Now the key difference in a promise vs Rxjs observable comparison is that:

An Observable is cancellable!

Also, an important feature to outline here is that Observables have at least 2 participants:

  1. the data source itself (or the “creator)
  2. the subscriber ( where the data is being consumed)

Moreover, being functional programming-based, an Observable supports lots of useful operators, right out-of-the-box:

  • flat map
  • reduce
  • filter
  • zip
  • forEach

Why do developers prefer Observable over Promise? For several strong reasons:

  1. first of all, for all the operators that it supports, by default 
  2. it enables you to use the same API, even if you want it to handle a single or multiple events
  3. it's cancelable (its biggest advantage): when you no longer need the results of an HTTP request, you can just unsubscribe
     

7. Observables in Angular: Key Features to Keep in Mind

Now let's sum up Observables' core features, which also stand for the differences between these abstractions and Promises in AngularJS:

  • they're cancelable
  • they're retriable
  • they come already “packed” with a myriad of useful functions that I've already listed here
  • they can be initiated from other data sources, as well, such as events
  • they're streams, therefore they handle multiple values (streaming data in multiple pipelines over time)
     

8. So The Main Difference Between Observable and Promise in Angular Is...

There are several “main” differences, in fact, to bear in mind, so you know when it's best to use one over the other:

  • both abstractions help you run functions asynchronously, but they return values differently
  • … Promises use their return values exclusively when executed, whereas Observables use them multiple times, in a stream (or sequence of asynchronous events)
  • an Observable provides all the features that Promise provides, plus a few more 
  • Promises are values revolving in asynchronous ways (e.g HTTP calls), whereas Observables handle arrays of events

In short: you can handle multiple events using Observables, but only a single event using Promise in AngularJS.

The END! This is my attempt (successful or not quite, I leave it to you to judge) at answering your question:

“What's the difference between Observable and Promise in Angular? Aren't they both geared at helping me work with asynchronous functionalities?”