Observables vs Promises vs Iterators vs Functions

On this page, I found something I was searching for a long time: http://reactivex.io/rxjs/manual/overview.html#observable 

	Single	Multiple
Pull	Function	Iterator
Push	Promise	Observable

This is a summary of how Observables, Promises, Iterators and Functions are connected to each other.

I find it extremely helpful for people who are just getting familiar with Observables in general, because it helps you place the concepts in your current mind map.

So to sum it up it divides the access mechanism of data into 2 categories: Push and Pull. Pull means that the caller explicitly requests some data and awaits for it. This means that the one who's pulling knows when exactly it's going to be pulled (sequentiality). Pushing on the other hand means that one just listens to a certain channel and waits for data to be received. The advantage of that is that the provider of the data knows exactly what it's going to provide to it's listeners.

The other perspective to look at accessing data is how many times it can provide. It can be 1 time only (Single) and more times (Multiple).

These add up to the table you can see above, where every cell represents different concepts you're already familiar with.

It's pretty important to mention that one can jump around between different types - with obvious restrictions. For example one can create an Observable out of a Promise. It will be a specific Observable that it will fire once, and then it completes, but it is possible. One can do the other way around as well, but it's not going to be the exact same as one could expect. Because a Promise is a Single Push operation, this means that even if we cast somehow from an Observable to a Promise, it won't behave the same as an Observable, but will only fire once, as one could expect that from a Promise.

For the record, one can trick the system by creating a Promise that awaits for multiple sources, so in theory could mimic the behaviour of an Observable, but that would be very hacky, I'd not suggest to do that.