Check out a free preview of the full Enterprise Architecture Patterns course:
The "Streaming Values Over Time" Lesson is part of the full, Enterprise Architecture Patterns course featured in this preview video. Here's what you'd learn in this lesson:

Lukas compares observables and streaming values with promises. A promise is effective when managing a single asynchronous event. Observables coordinate multiple asynchronous events since streaming values are emitted over time.

Get Unlimited Access Now

Transcript from the "Streaming Values Over Time" Lesson

>> Observables is really the combination of two classic patterns so before we're talking about what I call the reducer pattern. Now we're talking about observables, which is the combination of two classic gang of four style patterns, which is the iterate pattern and the observer pattern. And so, the observer pattern gives you the ability to communicate that some event has happened at some indeterminate time.

[00:00:34] And so this is a way for like I'm going to observe this and you tell me when This is ready. So a lot of times I think of this as if you've ever went out to dinner and you go in and say, I have a table, I need a table for four.

[00:00:50] They're like, it's not ready, but here is a beeper or a pager and they give it to you and then you walk away. Well, that is kind of how that works and so it works a little better when you're talking about promises. But that is the idea is that something's going to happen in the future you wanna know about it, and so you're observing it.

[00:01:11] Then the iterator pattern allows you to reliably access state or data with in a collection. And so when you combine these two together, it allows you to communicate state over time Lo and behold flow control problem solved. And so how this works is that you have the stream of time and you have these events that happened.

[00:01:46] And as these events happen, they're communicated through the observable stream. And so we are somewhat familiar with getting values over time and the big one being promises so most developers have used a promise. And this is this is probably a better analogy for a beber at a restaurant that your table is ready.

[00:02:15] But it's an asynchronous resolution of a value and the problem with that is is that, well not the problem. But the limitations of that is that it is a single resolution is once you resolve a promise that is all it will ever be the difference is the, Observable or an observable will emit multiple values over time as new data is available, you will continue to receive that.

[00:02:52] So a really good example of that is I think if you are watching like a real time score board. As the score is incremented, you know about immediately. The difference is that functions enumerable that they are synchronous. But what we really care about is asynchronous so promises are single resolution observables allow for multiple resolution.

[00:03:19] Now, one thing that's interesting about this is think about how we consume the values from a promise observable versus a function or an enumerable. Well, when you consume a value from a function, you're essentially pulling that data to you. When you consume a promise or an observable, when that promise or observable resolves or has a like a next integration in it is pushing that value to you.

[00:04:00] And so I really want us to stop and think for just a second just mentally. Just make that note of like, when we call functions are pulling data to us. But when we're dealing with observables and by extension or we'll deal with promises and by extension observables data is being pushed to us.

[00:04:24] And so I've set the stage but anytime I start talking about observables typically the response is usually something like this. And I just coolly, calmly collectively just take a drink of my water, And I say well, You're probably right, you are mostly right, but, i would say observables are challenging.

[00:05:06] But, where I believe people get into trouble or in the weeds, is that they confuse. Observables with in this case are xjs and that 250 operators that that project ships with. And so just the sheer number of operators that come with that is like what does zip do?

[00:05:33] Flat map like all these different I mean they're even changing like I certainly don't know them all is that observables are challenging. But when you separate all of the operators and you focus on just the observable stream, suddenly this becomes a much more viable proposition. And again, reducing complexity is that we're going to take all the operators aside.

[00:06:02] And let's focus on the observable stream because when we understand the observable stream, then the stage is set. For us to put this back together in a way that allows us to build fully reactive, asynchronous high performance applications. But we can't do that until we understand what and how an observable stream works.

[00:06:31] And so I'm going to ask you to make a small paradigm shift this is all it takes. We are used to thinking and by default, we think of programming in these terms input and output I mean, I even own a few .io domains. It's just part of my brand image at this point, like we think of it just in programming is I give you some input, I get some output.

[00:07:04] But how does that work, well, it's a function call and we're pulling data to us. This is how we think about programming is that if I need something, I'm gonna ask for it. If I need something I'm gonna ask and eventually you're going to give it to me.

[00:07:24] In order to make sense of observable streams, I just need you to go from this to this that's it. Just flip the paradigm from input to output to output to input and what I mean by that is with anything. You have this basic sequence that looks like this.

[00:07:54] You have, an initial output and a final input. So we've inverted this but what that means is that you have an event that is producing an initial output. It's happening and it's pushing it to you, it's delivering it to you, it's streaming to you, everything is a stream, especially if we're talking about DOM events.

[00:08:19] What we have to decide is where do we wanna put it in our application, and what is the final form that we need it to be in? So, we have initial output, final input and then in the middle, we've got this magic sandwich. So what this looks like is you have an event, you have a subscribe block.

[00:08:50] So that's the event is we're getting on this train, the subscribe block is we're at our destination. And then the middle magic portion of the sandwich are just the operators and so let's look at a very, very basic sequence. And so this is in angular, don't let that get in the way, we could easily do this without.

[00:09:19] But when you're dealing with DOM, it's nice to have some framework to help smooth that out. But anytime that I'm dealing with an observable stream, the exercise that I go through is this. Where is the initial output? Where is the final input? And what's happening in between? And that's how I process every single observable stream.

[00:09:48] But the first thing that I do every single time is I figure out what the initial output is. And so in this case, if we look at this, this is the initial output. We're saying get this button, and when it clicks, communicate that down the stream. Initial output and then we have our final input.

[00:10:23] So the subscribe block, essentially terminates or finalizes the stream, you cannot modify the data within the stream at any point after that, because it's been delivered. And so now you're saying this is where I want to input it into my application, and this is the shape that I want it.

[00:10:45] Then what you can do is assemble yourself a nice Dagwood sandwich. And that you can say I want to take this event and I want to map it to something else so when life gives you lemons, you just map it to lemonade. So somebody could just make an Inspirational poster out of that I approve of it.

[00:11:12] But all we're doing is saying I don't like this I don't like your lemons I'm mapping it to lemonade. And then you can start to stack them because your methods and your operators are pure immutable functions with no side effects. Which means that you take a data structure, you pass it in, you get a new data structure.

[00:11:37] It goes into the next thing, into the next thing, into the next thing, until it comes out the bottom. And so at a high level this is the basic observable string. You have your initial output, your final input, and then any number of things that can happen in between.