Democratizing event processing at all scales and platforms with Reactive Extensions
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Alternative Title |
| |
| Title of Series | ||
| Number of Parts | 170 | |
| Author | ||
| License | CC Attribution - NonCommercial - ShareAlike 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this | |
| Identifiers | 10.5446/50620 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
NDC Oslo 201479 / 170
2
3
5
6
8
11
12
16
21
22
23
27
31
35
37
42
43
45
47
48
49
50
52
54
56
57
58
61
65
66
67
71
74
77
80
81
83
84
85
87
88
89
90
91
94
95
96
97
98
100
102
107
108
112
114
115
116
118
120
121
122
123
126
127
128
130
133
135
137
138
139
140
141
142
143
144
145
147
148
149
150
153
155
156
157
158
159
160
161
162
163
166
169
170
00:00
Extension (kinesiology)Sanitary sewerData managementSocial softwareAbstractionComputer programmingMultiplication signSpacetimeNumberFunctional (mathematics)Green's functionTwitterSlide rulePlastikkarteForm (programming)Category of beingLevel (video gaming)Basis <Mathematik>AdditionProcess (computing)Real-time operating systemInformationAutomatic differentiationTheoryUniform resource locatorSinc functionDifferent (Kate Ryan album)Field extensionServer (computing)Formal languageShape (magazine)Term (mathematics)Streaming mediaDatabaseHypermediaPersonal digital assistantWindowPoint (geometry)CommutatorMonad (category theory)State observerVirtual machineEvent horizonParallel computingComputer animation
05:42
Range (statistics)Streaming mediaElectronic mailing listVideo game consoleEvent horizonCodePosition operatorComputer-generated imageryFunction (mathematics)Error messageComputer programmingSynchronizationFormal languageJava appletAlgebraic closureCore dumpTask (computing)CodecSystem programmingComponent-based software engineeringDependent and independent variablesScalabilityFocus (optics)Level (video gaming)Endliche ModelltheorieMechanism designPropagatorVisualization (computer graphics)Formal languageSystem callQuicksortField extensionPosition operatorWeightSingle-precision floating-point formatTouchscreenProgrammer (hardware)Structural loadCodeBit rateBasis <Mathematik>Demo (music)Parallel computingComputer clusterPower (physics)Task (computing)Normal (geometry)Event horizonDisk read-and-write headDifferent (Kate Ryan album)Ultraviolet photoelectron spectroscopyReal numberException handlingDrag (physics)Web serviceLink (knot theory)Computing platformComputer programmingRight angleInformationCore dumpLogicScaling (geometry)SynchronizationTransport Layer SecurityScripting languageRow (database)MultiplicationDependent and independent variablesValue-added networkData dictionaryJava appletMathematicsAdditionElectronic mailing listAlgebraic closureComputer animation
11:24
Cartesian coordinate systemBasis <Mathematik>Demo (music)Dependent and independent variablesSummierbarkeitRight angle
12:21
Maxima and minimaRule of inferenceServer (computing)Boom (sailing)Simultaneous localization and mappingTwin primeFunction (mathematics)Data bufferVelocityGame theoryDrum memorySummierbarkeitDependent and independent variablesDemo (music)Game theorySoftware frameworkField extensionCartesian coordinate systemFacebookLoop (music)Alphabet (computer science)Computer animation
13:45
Data miningLevel (video gaming)Alphabet (computer science)Simulated annealingSummierbarkeitRule of inferenceGame theoryCartesian coordinate systemPower (physics)Revision controlTerm (mathematics)Query languageField extensionLogicReal-time operating systemLimit (category theory)Adaptive behaviorComputer animation
15:00
Quantum field theoryGraphic designDrag (physics)Drop (liquid)Twin primeDrag (physics)Drop (liquid)Game theoryComputer animation
15:53
Interactive televisionComputer programmingException handlingPattern languageSoftwareObject (grammar)Lie groupState observerPay televisionSystem callResource allocationSequenceEvent horizonFormal grammarRadical (chemistry)Variable (mathematics)Data structureParameter (computer programming)Run time (program lifecycle phase)Independence (probability theory)Query languageSoftware testingFreewareLibrary (computing)Fluid staticsOvalSynchronizationVideo game consoleState observerPattern languageCASE <Informatik>Social classFormal languageProgrammschleifeMereologyObject (grammar)Event horizonServer (computing)Software design patternComputer networkMappingPay televisionComplete metric spaceSystem callPhysical systemComputing platformDependent and independent variablesScripting languageTorusPoint (geometry)Survival analysisComputer programmingSoftware testingException handlingRadical (chemistry)LeakFormal grammarError messageInfinityProcess (computing)Forcing (mathematics)Task (computing)Ultraviolet photoelectron spectroscopyPower (physics)WeightDrag (physics)Core dumpCodeInteractive televisionIterationComputer animation
21:41
SynchronizationOvalVideo game consoleCountingFormal languageData modelState observerJava appletWeightComplete metric spaceBounded variationLevel (video gaming)Algebraic closureQuery languageOperations researchDigital filterDuality (mathematics)Exception handlingSymbol tableDiagramoutputFunction (mathematics)Loop (music)Link (knot theory)Food energyQuicksortOperator (mathematics)Java appletComputing platformException handlingDiagramDot productQuery languageMathematicsServer (computing)Term (mathematics)Series (mathematics)Streaming mediaFormal languageDuality (mathematics)Scheduling (computing)Context awarenessTriangleWeightMereologyFundamental theorem of algebraNormal (geometry)Level (video gaming)Set (mathematics)Enumerated typeDifferent (Kate Ryan album)WindowVulnerability (computing)WordImplementationBitProjective planeCASE <Informatik>Reduction of orderMappingCodeTask (computing)Line (geometry)Matching (graph theory)State observerComplete metric spacePoint (geometry)ProgrammschleifeMultiplication signSystem call2 (number)Order (biology)Web serviceDivisorCircleSinc functionField extensionType theoryMultitier architectureLogicFlock (web browser)Right angleObject (grammar)Error messageFunctional (mathematics)Numeral (linguistics)1 (number)Open setProcess (computing)Algebraic closureIntelligent NetworkScripting languageSurvival analysisGroup actionPower (physics)outputComputer animation
27:22
Symbol tableLevel (video gaming)Computer programmingDrag (physics)Drop (liquid)Event horizonClient (computing)String (computer science)Data dictionaryWeb pageArray data structureoutputFunction (mathematics)Server (computing)String (computer science)Level (video gaming)QuicksortResultantDrag (physics)Object (grammar)2 (number)Task (computing)Type theoryState of matterRepresentation (politics)Multiplication signCuboidMereologyKeyboard shortcutParallel computingDependent and independent variablesComputer iconLeakBitCoordinate systemWeb serviceFormal languageRight angleKey (cryptography)Event horizonTouchscreenShooting methodDifferential (mechanical device)outputCodeScripting languageAreaComplete metric spaceScaling (geometry)Direction (geometry)Goodness of fitWeb 2.0MathematicsDivisorProcess (computing)Order (biology)System callWeightArrow of timeOptical disc driveWordJava appletComputer animation
33:04
Event horizonLevel (video gaming)outputFunction (mathematics)WeightAlpha (investment)Drop (liquid)Sample (statistics)CodeFile formatInformation overloadKeyboard shortcutProgrammable read-only memoryQuery languageData dictionaryProper mapMultiplication signChaos (cosmogony)Data dictionaryComputer animation
33:51
Open setWeightAsynchronous Transfer ModeMusical ensembleElectronic mailing listStreaming mediaRegulärer Ausdruck <Textverarbeitung>Query languagePressureDistribution (mathematics)Physical systemComputer networkBefehlsprozessorVirtual machineStandard deviationVolumeSource codeOperations researchDigital filterType theoryConcurrency (computer science)Formal languageData modelState observerExtension (kinesiology)Complex (psychology)Computer fileBitException handlingStreaming mediaPressureSoftware testingConcurrency (computer science)Core dumpMachine visionFundamental theorem of algebraPower (physics)Level (video gaming)CodeQuicksortWeightPhysical systemJava appletScheduling (computing)Open setOperator (mathematics)AdditionRight angleInternet service providerState observerSynchronizationFormal languageMultiplication signServer (computing)Implementation1 (number)Bit rateForestNetwork topologyNumberEvent horizonPoint (geometry)Software development kitOpen sourceOptical disc driveVideo game consoleUser interfaceScaling (geometry)Programming paradigmMobile WebTerm (mathematics)Quantum stateScripting languageSoftwareReal-time operating systemSoftware developerWindowProcess (computing)Object (grammar)Speech synthesisSingle-precision floating-point formatView (database)VirtualizationSemiconductor memoryTraffic reportingKeyboard shortcutVirtual machineInformationWeb pageMoment (mathematics)Library (computing)Flow separationLengthSyntaxbaumDifferent (Kate Ryan album)Video gameRow (database)Software frameworkComputing platformRevision controlDirected graphElectric generatorExecution unitMereologyWebsiteDirection (geometry)Thread (computing)Figurate numberField extensionComplex (psychology)Military baseComputer programmingAddress spaceComputer hardwareAnalogyClient (computing)Demo (music)Structural loadKey (cryptography)Point cloudCASE <Informatik>Parameter (computer programming)Unit testingQuery languageParallel computingEndliche ModelltheorieBoom (sailing)WhiteboardWeb serviceRepresentation (politics)Sinc functionGame theoryBasis <Mathematik>Complete metric spaceUbiquitous computingComputer animation
Transcript: English(auto-generated)
00:01
Beautiful, beautiful. All right, everyone, we are here for an Rx talk. I know everybody's excited about any time Rx comes up, so I thought I'd kind of be the one to give this particular talk. So we're actually living in a very exciting time now
00:20
with reactive being a thing, where people are talking consistently about reactive programming, functional reactive programming. It's a very, very interesting space to be in right now. So I am Matt Podwysocki. I'm from a very small company called Microsoft, and I am also an Rx pusher.
00:44
You can also find us on Twitter at reactivex, and if you want to follow along with slides, examples, and what have you, we have everything up on GitHub. So what this talk could also have been is how I really stopped worrying about asynchronous programming
01:04
and learned to love the observable. I could have gotten the hat, but, you know, I tried to fit that in my luggage. It just wouldn't work, so, oh, well. Basically, this is not going to be another monad tutorial. There's going to be no category theory here.
01:22
I know if you've seen a lot of Eric Meyer talks before on the reactive extensions, you'll usually find monads and category theory. None of that will be done here, and no animals will be harmed either.
01:40
So what we're really here to talk about is stream processing, because stream processing is a really, really interesting topic. And since we're living in a different world today, I would say that real time is everywhere. Now, it could be in any number of shapes. It could be stock tickers, RSS, GPS, Twitter,
02:01
social media, and so forth. Your phone is literally inundated on an hourly and minute basis with an amount of information, your geolocation, anything regarding any particular sensors in this. All of this doesn't sit there and continuously poll in the background.
02:21
They get pushed information. Now, each of these things, the UI, the server, and everything else kind of talk in a different language in terms of how exactly they communicate. But wouldn't it be nice to actually have a single unified way of speaking about all of these the same way, that the phone is a database,
02:43
your mouse is a database, your servers are a database that you can actually query? And that's the idea and the key value behind the reactive extensions. So let's actually make it real. How many people have heard about Cortana and the Windows Phone?
03:02
A few people. All right, so it's the personal assistant for Windows Phone 8.1. And as you can see right here, I have it up here. And so what it does is it'll allow you to schedule some flights. It'll allow you to check on the weather, say, should I wear a jacket today,
03:21
any number of those kinds of things. And it's built right into the phone. So what I can say is, so for example, I can set a reminder that at the end of the session, you should all give me green cards because that's what I deserve. And so that's all powered here on the phone
03:42
by the reactive extensions. So all of this is that. All of it. And not only that, but when you look on your phone as well, your phone has the reactive extensions also built into it so that it's sitting on the bare metal
04:02
listening to every single little sensor that you have. So when you change your geolocation, when you fire an event of some form or fashion, it's being captured by the reactive extensions. In addition, we can now integrate with Bing as well.
04:23
So when we're integrating with Bing, so for example, I'm going to be traveling, say, to the airport. How long is it going to take? When am I supposed to leave? It knows because of my location where I am, and it can tell me about how long it's going to take me by commute
04:41
so that it'll remind me, do a push notification to me when I'm supposed to leave. So as you can see, all three places are powered by RX. Now we have the RX CPP or the RX for a C++ sitting on the phone, very, very small footprint, and for processing sensors at a very, very low latency.
05:03
Whereas on the server, what we have is we have managed code, but we've modified it in such a way not from the publicly available stuff, but we've modified it in such a way that we can spread it across machines very easily.
05:20
And so really, in all honesty, we're processing the world's data here. So now let's actually focus on what we actually came to talk about, the reactive extensions. So how many people use something like Netflix or watch movies online? So Netflix is a good number of you. So Netflix is one of our biggest partners
05:41
that we work with on a pretty constant basis. Now we can get the top-rated movies for any particular user by going and getting a user, looking at their lists, and inside of their lists, we're going to then start to filter based upon whether the rating is the best.
06:00
And then we're going to merge it all together into one list and call subscribe. So if you're used to link to objects in .NET, then this looks completely familiar to you. There is absolutely no difference between writing code in Rx and writing code for...
06:22
for querying and observables. So an IEnumerable and IObservable are both very, very much queriable. So what if I told you this? You can take that exact same piece of code and you can create a drag event with just about the same amount of code
06:40
that you had before. What would you say? All right, so let's do that. So let's call this getElementDrags, passing in an element, and somehow we have extension methods on here where we can get mouse downs and so forth. But once again, we're taking mouse downs, selecting it, taking mouse moves,
07:00
and then instead of this where, we'll say take until mouse ups happen. And then we can now subscribe to our observable and then update our position. Once again, between these two pieces of code, there is not much difference at all.
07:21
That's the beauty of Rx, is the fact that I can query this and this using the same code. So I don't know about you, but when I first thought about that, I was like, wow, that's kind of powerful. So did that grab your attention? That's really that the chances with link on .NET
07:44
and every other platform is just about infinite. And I don't know how many people here are JavaScript programmers and have to deal with something like this on a consistent basis. I know most node programmers do. And in fact, they actually actively hate promises.
08:01
So they have to live with this kind of model where you're trying to sit there and within all of these callbacks, you end up with some sort of weird cow head looking thing. So it kind of keeps walking off the screen and then walking all the way back. And then somehow the air propagation is somehow handling it.
08:22
It's really, really difficult to reason about it because you're always thinking about the callbacks instead of the actual logic. So let me just get this right out of the bat. Asynchronous programming is annoying. Why? Because each language that we're talking about
08:40
has really a different way of talking about asynchronous behavior, whether it's a single scaler value or multivalue. So in Java, they have futures. In JavaScript, they have promises or callbacks. Clojure has core.async. And .NET tasks are a different beast altogether.
09:01
So all of those are different things. And then when you're talking about the single value versus the multivalue, then really things start to get really hairy. Why don't I instead have one single concept where I can reason about both of them at once? So as I was saying, the whole reactive programming is becoming quite a big deal.
09:24
I don't know. How many people took the Coursera course on reactive programming? Anyone? Okay, how many people actually finished it? You finished it? Wow, that's amazing. I know there are a lot of people that got a little tired of it after a while,
09:41
but there's been a lot of big buzz about reactive programming. And when I thought about it at first, what does that exactly mean? Because if you actually look it up on the dictionary, you say, readily responds to a stimulus. Well, isn't that just normal programming? Everything just responds to normal stimulus, doesn't it? Now, well, really what we can distill it to
10:01
is a couple of things. First, reacting to events. So having a way of reacting to an event such as a mouse move, a geolocation change, anything like that. In addition, reacting to data load. So for example, if I have a service running on Azure and it's constantly getting inundated,
10:22
I need some sort of way to back it down and then speed it back up when I'm able to do that. And that's very reactive. Visual Studio is not reactive because when I put a lot of load on it, the screen turns white and I have to wait for a while. That's not reactive. Reactive failure is also another thing.
10:41
What happens when you're in a push-based model and something fails? That's a real problem because it's not like we can just do a try catch around events. That just doesn't work. We have to have some other mechanism to handle events. In addition, we have to be responsive and reactive to users.
11:02
We have to keep them from getting that white screen of death and saying you can't do anything until I come back with actual data. So it's really about respecting the users and giving them the right amount of information that they need to go. So let's actually take a look at a couple of reactive demos that I've cooked up for you
11:21
or I've taken from the general community. Of course, I would say the biggest reactive demo out there is probably an application you'd probably use on a daily basis. And guess what that's called? Excel. Although it's not really all that interesting,
11:42
but the idea behind that is it does indeed respond to a stimulus because if I say here equals sum of A1 and... Oh, whoa, whoa, whoa, sorry. All right. Why don't you see it?
12:03
Well, that's special. There we are. Yes? No? That is weird. It is not responding to me.
12:24
And that just kills it altogether. Cool. All right, there. Now you can see it. All right, so now if I can say sum A1 and B1 and enter,
12:42
so now I can say 42 and 42 and it responds that way. But that's not interesting. What you came here to see is a really cool demo, so why don't we do that? So let's... How many people like My Little Pony?
13:00
Come on, just... I... yes! All right, so there's this great little demo out here called Bootaloo, and it was done by Bootalstoki. And she did this at JSConf in which that she did a bunch of things with RxJS and React, the framework from Facebook,
13:23
in so much so that we can start playing a game using the reactive extensions here so we can start to jump and respond to users and so forth and we can avoid the trolls or we die.
13:42
There you go. Another one is simple games like Alphabet Invasion. These are very, very simple applications, but yet they follow all of the things that make a reactive application very interesting. You have timers, you have a game loop, you have timers, you have responding to events,
14:02
you have just about everything. And then I just get bored with playing this application and we can move on. All right, come on, fail, fail, fail. I got bored. Okay, moving on. Also, stock trading, for example.
14:21
So really kind of bringing this home in terms of business logic. What this is here is this is from a company called Adaptive Limited. And what this is is a dashboard, and they have this both in HTML5 version and a WPF click once version, which allows us to do kind of real-time currency trading.
14:43
All using the power of the reactive extension. So really being able to do really complex queries to determine whether you should buy or sell a given currency. So it's all really, really interesting on how many uses there are for the reactive extensions.
15:00
Another one is I can find, for example, I want to find all of the C-sharp people in Oslo. Let's see if I can find that. All of this stuff in particular here is also using Angular and Rx together. And sure enough, we found a few people. I don't know if they happen to be in the room or not,
15:21
but that would be kind of cool if they were. But anyways, all of this stuff here is also using Rx to not only query but also to respond to the users to make sure that when they actually enter in data, I'm going to go out and query and get it and bring it back to you. And so on and so forth.
15:41
So you'll find a lot of these really interesting games, even simple drag and drop, are very, very kind of the many things that you can do with Rx. So now that we kind of know what exactly we can do with it,
16:01
let's actually talk about something that's a little less interesting. Now, ordinary interactive programming is something that you and I both do every day. We somehow iterate through a collection and do something. Now, what that maps to is an onNext call. We handle or re-throw an exception,
16:21
and that's onError. And then finally, we do some cleanup. And so what we just see here, so we do something on the next value, something when an error happens and something went on completion. So what we just saw was the iterator pattern from the gang of four. I don't know how many people have that, but if you do, it's dating yourself
16:41
because that came out in 1994, and that's, God, how many years ago? Twenty? Ew. And so that was one of the interesting things that came out of it. It finally codified this iterator pattern. But what we also found from that particular book that there was also an interesting
17:00
other design pattern that wasn't very frequently used called the subject-observer pattern. Now, the subject-observer pattern, the idea behind that was to allow for people to kind of respond to push events. But the way that it was implemented in this particular book here kind of reminded me more of how we listen to events
17:21
in JavaScript or .NET and so forth, where you can subscribe and unsubscribe, but you have to kind of use the same handle to do both. But we didn't particularly like that design, especially as we were trying to create a system called Volta. And Volta was the idea is we could write our code once
17:41
and target as many platforms as we wanted to all through the power of .NET. So what we are going to do is going to take that iterator collection and make it push-based. So what we'll have here is an I-observable. So instead of this I-enumerable that we've had before, if you're used to C-sharp,
18:02
we have this I-observable of T. And then what we'll have is the listener that will receive the events as they come in, and that's called the observer. So on the onNext call, we can do something. On the onError, on the termination case, we can handle the error.
18:21
And finally, we can do cleanup through onCompleted. In some cases, that may never happen. You know, we may never hit an end, sort of like when we're continuously moving our mouse, it will never hit an end. So we really wanted something really as deeply decoupled as possible. So instead of saying that's adding an observer
18:43
and removing an observer directly, we said collection.subscribe passing in an observer. And this works for every single language that Rx has been ported to. And what that gives us back is this handle. Now, this handle that you can use, we call a subscription, is something that will be able to go up
19:02
and clean up all of your event handlers and everything else that it needs to do deterministically. So you no longer have to have this observable that you add and remove things from, is that it travels with you so that you can pass this subscription around anywhere and at any time. And what makes that great for is, for example,
19:21
going back to the mouse drag example, we can take mouse downs, mouse moves, and mouse ups into a single disposable or subscription, and then when we call dispose on it, all three of those handlers go away. They get released. There is no chance at all
19:40
for any particular event handler leaks. And that's a very important thing. And so we have a very explicit grammar about it. So we have onNext could have infinite calls. We could have a couple that happen and then an error happens. We also could have a termination after two.
20:05
But we can never have anything that overlaps, and we can certainly never have anything that happens after completion. There is a very strict way of dealing with this, and Rx enforces that at the very, very core of itself. What's really neat about this,
20:21
now that we have this IObservableObject, it's a forObservableObject no matter what your language is, Java, C Sharp, JavaScript, et cetera. It's a first-class object. So if you want mouse movements, I can hand you an object that contains all the mouse movements. If you want the stock ticker,
20:41
I can hand you an object which represents all the stock ticks coming in. That's not something that you can do with just normal events today. So that's why it's very, very interesting. And it's especially good for when you can pass it in and take it out of a method. So since it's kind of an object,
21:00
we can mock it, and it's really good for testing, for example. We can fake it out with any particular piece of data that we want, and that's a beautiful thing. We also, coming with .NET 4.5 and beyond, we also support those who are in the C Sharp
21:21
or the .NET camp. We also support observables being awaitable. So that's really kind of an important thing, is the fact that we also play a first-class part in the story of asynchronous behavior. So we can await an observable, and we can do stuff with it.
21:41
Now, some people have said, well, that's great, but why wouldn't I just use tasks for everything and then just use while loops to handle each one? Well, I'll tell you why. Take a look if what we're going to do instead is actually get some movies. Now, in order to have retry logic,
22:00
what would you normally do? You would have it in some sort of while loop and keep listening if there's a failure and have a try-catch block around there or something. But with Rx, we already have a lot of these things built right into it. So, for example, I can say retry three times, and if it still fails, then it fails. But all I said was .retry,
22:22
and suddenly I have the ability to retry it immediately. If it fails and if it succeeds, boom, I get the value, and we're good to go. Make sense? So really, what are the reactive extensions? Well, we first covered the first part,
22:40
which is the observer and the observable. The next part, what we're going to do is cover the query operations that we can use that make Rx very, very powerful. And then finally, we're going to cover the kind of interesting pieces of what makes Rx interesting in terms of schedulers as well.
23:00
So really, Rx is everywhere. And it's in .net, JavaScript, Java. So if you're a Java person, you like Scala, Groovy, Closure, we have stuff for that as well with our partners in Netflix. Objective-C, reactive cocoa. We have RxC++, as I mentioned, powering part of Cortana
23:21
and powering part of Windows Server. We also have Python and Ruby implementations that are in various degrees of completion. PHP and Dart, and I'm hoping at some point Swift, maybe, please. Someone will do it for me. I just don't have the time nor energy to do it, but I think it would be very cool
23:41
if someone could actually do it. So as you can see, it's a very language agnostic kind of platform we're talking about here. Their fundamentals can be transferred pretty much to any language at all. So let's talk a little bit about the query operations
24:03
that you can do on there, such as map, filter, and reduce. So what we have is we have the dual... What the observable is, it's a dual of the IEnumerable. So instead of calling for each, you call subscribe to get...
24:21
So instead of pulling values, we're pushing values, and then we match up moveNext to current, to onNext, we can also throw an exception, and finally return a value. So it's all very much a one-for-one match in terms of duality, so that I could write a stock service
24:43
that's an IEnumerable of stock data, and I could write one of IObservable of stock data using almost the exact same code, except for each turns into a subscribe, and that's the only change I had to make. That's the beauty of this all. So IEnumerable, IObservable,
25:02
really kind of duals of one another. And even if you're in the JavaScript world, Array is a very much an enumerable kind of object, and in ES6 and beyond, they'll have sets and weak maps and maps, et cetera. There will also be that kind of thing,
25:21
and then you'll have Rx and Observables be the dual, absolute dual of that as well. So let's actually write a little, what I like to call marble diagrams. So marble diagrams are a way of kind of communicating what exactly is happening in our collection.
25:40
So let's take a series of dots, and I can apply a filter function to it, or if you're in .NET Aware function, and I can say whether dot is orange. So if I take some dots, I take all the blue ones, I remove them, and I project down to a new stream of only orange dots.
26:04
Now, we can also talk about map in the very same way. Map or select is really kind of the same word. It just means a simple projection. So in this particular case, we can take our input, and we want to map our circles to triangles.
26:20
To do that, we can just transform an item calling map. So we go down here. We are now taking all of these particular dots and now transforming them into triangles. And then it stops like normal. But one thing that's different about Rx just because it's pushed, it also has a notion of time,
26:42
which is why those schedulers that I talked about are very, very important. Since they have a notion of time, I can call delay. So what delay will do is I can now say delay by a second in this particular case. And so each and every one along the line will be delayed in time and in place
27:04
by exactly one second. So that's really kind of a cool factor is the fact that you can start adding in these time-based operators into your link code as if it were just a normal thing to do. So let's actually talk about the landscape here.
27:23
So when we have normal synchronous values, it's just of type T or whatever it is. And when you have many values, you have IEnumerable of T. And let's see. And you also have, for example, here you have tasks
27:44
that you can await. In JavaScript, you have promises. And you also have futures and so forth in other languages. But it's still kind of the same thing. It's a scaler, one and done kind of value. And then where the observable sits is up here in the right corner and says,
28:02
well, you know what? I can deal with single values. I can deal with multiple values. But really, I'm dealing with collections. That's all I'm dealing with. Events are collections. Mouse movements are collections. Anything like that should be queryable. So let's actually do drag and drop.
28:22
Now, I showed you drag and drop a little earlier about dragging the icon around the screen. It's actually fairly simple to do. Now, if we take this and we say mouse drag a mouse drag is nothing more than a mouse down and select many if you're using C sharp.
28:42
We call flatMap, getting the offset. We take the mouse movements and map that to where we get the differential between the two. And then finally, we say take until mouse up. So what we've described here is exactly the intent that we're trying to get through.
29:03
Mouse down, mouse move, until mouse up. There really isn't much more to that. Now, if you were using normal events, you would have to have some sort of state sitting way up here as to whether the mouse was down or not, and then you would have to have the given coordinates. Well, I have all of this here in one single method
29:23
that I just call, not one single method, but one single object called mouse drag. So it takes all of that and puts it into one thing. And then not only that, but when I call subscribe, I get the handle, and when I call dispose, all three handles disappear, no leaks.
29:42
Now, let's actually make this a little bit more interesting. So events and promises. So, for example, in JavaScript, you deal with promises a lot, and in .NET, you deal with tasks a lot. So what if we want to do a simple example like an autocompletion scenario? How many people have actually handwritten
30:01
an autocomplete scenario? As you're typing, suggestions come down below you, and you can pick out which one that you want to do. How many people have actually done it well, or write, for example? That's the hardest part of it all. So you can sit there, and you can be the world's fastest typer, and the problem is that every single request
30:22
will go over to the web service. I don't think you want that, because your bill at the end of the month will be very huge, because there's all this data getting shoved at your server that you don't really care about. So you need some sort of, because time is money here, you need some sort of way to go over to the server and get that back, but without overloading it.
30:42
So once again, responding to load. And in turn, what that gives us back is an array of words, and that we somehow bind it to our UI. Simple, right? So let's actually go through actually what that code looks like,
31:00
and I'll show you an example, a working example here in just a second. So what we can do is we can take the key up and then get the input's value out of there, so that at all times, what I'm going to have is the string representation of what's inside that box. Now, since time is money here,
31:21
what we can do is say throttle it by half a second. So as soon as I stop typing for half a second, it goes, aha, all right, he's good. He stopped typing. We can send this over to the server and then get this back, but not so fast, because now we've added an additional thing called distinct until changed in the fact that I can keep on pressing
31:41
the left arrow, the right arrow, up, down, left, right, and that's still a key press. The problem with that is the fact that that's still counting as an actual key press. So distinct until changed says, no, no, no, no, no, no. The actual value of that particular box did not change. Therefore, I am not going to fire.
32:02
And now what we're going to deal with here is one of the hardest parts of asynchronous programming altogether. And what is that? Out-of-order responses. How many people have here been typing on a phone, go, duh, duh, duh? Oh, I found my... Oh, shoot. Now my answer just went away, because I typed one key too fast,
32:22
and now suddenly the old results are showing up. Well, that's a big problem when it comes to asynchronous programming. How do you ensure that all of the previous things are canceled and you only get the latest one? Well, with flatMap latest, or you can say select and switch in .NET,
32:41
we'll do all that for you automatically. So if the request hasn't even gone out yet, it will cancel it. If it doesn't, it will just drop it on the floor, and you're good to go. So this ensures that your UI is always responding to the right thing. And then we can take that and bind it directly to the UI.
33:03
Seems kind of easy, right? So if we take a look at our particular thing here, we have... Yes. Autocomplete. And... Oh, for gosh sakes. All right.
33:23
Okay, so it's not there again. All right, beautiful. All right, so let's do this again. And next time, I'll remember not to do this. All right, so a dictionary suggests... Did I not put that in here as to one of my demos?
33:45
I did not. All right, all right. Well, let's go back here and continue.
34:00
All right, so now let's talk about the schedulers. Now, the schedulers are a very interesting portion of Rx. And what that does is it kind of separates us from many other libraries out there, where this notion of time is allowed to be parameterized in any number of ways. So how do I actually run a timer?
34:21
Where do I run it? How am I going to execute it? Does it need to synchronize with anything? That's really an interesting question. And schedulers with Rx answer that question very simply. There are many operators, such as any of the creation operators,
34:40
that take this concurrency parameter. So now that I can say this happens on the thread pool, this happens over on the current thread, this one happens on the dispatcher thread, so that by the time when I'm rebinding to the user interface, I don't have all of these weird exceptions being thrown. It says, no, no, no, this is not the originating thread. Therefore, I'm going to throw an exception.
35:02
And not only that, but it also provides this testing benefit that's really, really nice is because now we can swap out this real time for this notion of virtual time. So the idea is that I can capture this time as it happens and tell you exactly when things happened, all synchronously.
35:22
So you can have many different implementations. You can have the same cancellation. So once again, all this cancellation slides right back down. And to make sure that we can do all of our work either synchronously or asynchronously is all done through schedulers. So really what this does is it makes testing concurrent code
35:42
really, really simple. So we can create a test scheduler, and then we can create an observable here. At 300 ticks, we'll have NDC, and at 400 ticks, we'll have Oslo, and at 500, we'll complete. Seems simple. What we can do then is run our scheduler,
36:03
do a map to get the length, and then, deterministically, at the end, I can say at 300, there's a length of 3, and at 400, there's a length of 4. There is not a single bit of asynchronous code in here at all. Even though there might have been in terms of the original intent of scheduling the system,
36:23
but this makes it perfectly testable, and we have well over 2,500 unit tests in .NET and about 1,800 in JavaScript and so forth to test all of our operators in this very style here.
36:42
So kind of what more about us is we open-sourced everything that we did back in 2012 through Microsoft Open Tech, which is a wholly-owned subsidiary of Microsoft, which deals with open-source software. Now, who uses it?
37:01
Well, pretty much a who's who, quite honestly. You have Windows, which is on the server itself. You have the phone, like I said, Cortana. You've got it also baked into the phone since Windows Phone 7 has been around. RX has been there since day one.
37:21
You also have SoundCloud. SoundCloud is using it. Xamarin. Splunk is as well. And so GitHub uses it for the reactive UI, so anytime you use the GitHub client, you're using the reactive extensions. If you're using it for the Mac, you're also using the reactive extensions but for Objective-C. Splunk uses it for their SDK, Octokit, and so forth.
37:45
Now, let's actually talk about some experiences that partners of ours have done when dealing the reactive extensions. So let's talk about scale again. So what they did is they... Netflix is a company, if you're not aware,
38:02
that streams movies to any particular device you have, whether it's your TV, game console, mobile device, et cetera. And in the U.S., it's one-third of the U.S. broadband traffic. I don't know how it is in terms of any other country, but that's a large amount. How do you scale something like that?
38:22
So two years ago, they started on this little journey. And this journey was a way to better manage their asynchronous code because it was just a mess. They didn't know how to scale it. They didn't speak the same language. The UI guys and the server guys did not speak a common language,
38:40
and there was a lot of different confusion. Everyone was hand-rolling their own frameworks. So everyone had a different platform and a different approach. Now, today, so Rx is used on the client and the server. So on Rx, Java is used directly on their server to make a lot of the different requests that they do.
39:01
So, for example, just to do a lot of the searches and so forth and a lot of the complex event processing that they do in terms of all of the eventing that they have to capture, all of that's done with Rx. They also have 30 developers in five different languages all using Rx.
39:21
That's why I'm saying that is, it democratizes asynchronous programming even though I might be a JavaScript developer or a .NET developer, and I can still speak to you who may be a Java developer, but really we're speaking the same language because we're speaking observables. So we have the same asynchronous model everywhere.
39:43
So let's actually talk a little bit about end-to-end. So how many people have actually looked at this particular user interface and wondered what it does? Okay, so what it is is I want to be able to take a look around on my list and see which movies I should be looking at.
40:04
Now, we don't want to pull every single little picture into memory because that's rather intensive. Instead what we're going to want to do is we're going to only want to pull in the information that we need for that particular time in that particular moment. Because as soon as it's off-screen,
40:21
it shouldn't matter to us at all. In fact, on these lower-end pieces of hardware, it's actually dangerous to keep that much information around. Your phone will get all hot and bad things will happen. So how do you really deal with that? Well, once again, Rx to the rescue here. So what you can do is you can listen
40:40
for the documents scrolling and determine while you're scrolling with a little bit of a throttle so that makes sure that there's a little bit of latency just in case you scroll back up and back real quickly. And then what you can do is determine whether your particular row is visible or not.
41:01
So if it's not, so you keep on at a small interval, keep on polling, polling, and polling. And while that row is in sight, you just keep on saying, okay, this row's still in sight, row's still in sight, row's still in sight. Okay, no longer in sight. Boom. It's deleted. All of the handlers were moved out of memory.
41:24
That's why this kind of programming paradigm is so powerful is that you can now determine on a deterministic basis when my particular things are in view and when they're not. And when they're not, get rid of them.
41:42
And on the server side, you can also speak the same language there as well. So for example, I want to get some social rows. Say I want to recommend you a movie. How do I do that? Well, because everything on the Netflix API is an observable, I can do a join to you in the fact that we are both friends
42:02
and we can have the same friend ID so I can now, so my ID is, I have a friend that is equal to your ID. I can now recommend you movies, all using Rx on the server. So Netflix actually uses Rx for a lot of things.
42:22
Data binding, data access, any of the animations that they do, and building the complex events that they do on the server. So really, that's really key is the fact it's really, it's pervasive among their 30 developers. It's a pervasive language that they all speak together.
42:46
Now, what is the future? What are we looking at next? Just because we're delivering on the phone and we're delivering on other platforms doesn't mean we've actually stopped doing additional work. There are many other challenges
43:00
that we're going to be facing in the next couple of years that we really want to kind of address in our programming model. And what are they? Well, the first one is this notion of back pressure. So the easiest analogy I've come to describe back pressure is imagine, for example, I've got a really chatty service
43:22
and one particular hose on all of the spigots is really, really small, so it can't keep up with the load that it's getting. How does it tell the producer, hey, hold on, or how is there an intermediary to tell me that I need to slow down a little bit?
43:42
We have a lot of those notions built into RxJS already, but we're not quite there yet in terms of where we're really happy with with a good medium of being able to have sort of check pointing where we can say at a certain point, okay, we can resume. I'll hand you chunks of data that you might have missed in the meantime.
44:04
In addition, what you saw with Cortana is the fact that these things, that the iObservables are distributed. Now, what we really want to do is we want to take this and we want to really scale it out so that you could have, for example,
44:22
each observable is a rest endpoint. And then what you could do is have a subscriber subscribe to that rest endpoint and have data thrown at it. And that's really kind of a powerful thing. So that's something that we're looking at on both .NET, C++, and JavaScript. So imagine if you could serialize what you're doing,
44:43
throw it over to a different server, and have it come back, that's really what we're looking at here. In addition, the expression tree stuff is something that I want to go deeper into, which is, for example, RxJS, I could now write an OData provider
45:00
or I could write some other provider that can use the map and the filter and so forth to query against OData, or query against MongoDB and all of those other things and transform the trees into some other representation. And we're working on that for a particular thing.
45:20
We're also working on looking at making things a little lighter so that you can get started with Rx as a tinier thing. And also our custom builds for RxJS. So I know that we ship quite a number of files, if you're familiar with that, and we just want to make that a little bit easier for you so that you can do like jQuery
45:43
and many others like underscore and lodash allow you to do today. Another thing is this notion of reactive streams. So the Scala and Akka people are really big on reactive streams, and they think that this data problem
46:02
of this back pressure is really a core fundamental problem. I personally don't think so, but we are working with them to ensure that the vision is kind of the same between us, that we have some sort of level of understanding between us in terms of their idea
46:20
of what a reactive stream should be versus what Rx reactive stream should be. And to kind of give you a glimpse into the future, what we're also looking at are things like the future of JavaScript. How does RxJS really fit into the future of JavaScript? And from here, what you can do,
46:42
since version 0.1.1 of Node.js, you should be able to use generators. And in the next version of Rx, you'll be able to basically async-await your way through using RxJS and generators, so it'll look exactly like
47:01
you're using async-await, but you're not. So finally, to kind of wrap things up here before I open it up to questions, what we've covered here is we've covered the three basic things that Rx is.
47:20
It's the observer and the observable, the two core objects, the query operators that we have, and we have quite a ton of them, which is why it gets kind of overwhelming if you take a look at some of our documentation in terms of how many operators we do support. But each of them have a particular goal in mind.
47:40
We were just sitting there whiteboarding and just throwing them up there just for the fun of it. And schedulers as well. So the idea that we can schedule historic data, virtual time, say on a particular thread or on a different machine, we can do that all through schedulers.
48:01
So with that, any questions? Oh, yes. Yes. Yes.
48:22
Okay, so the question is, with things like Knockout and Angular and so forth, is this a replacement or is this sort of an addition to? And I would easily say it's an addition to. So for example,
48:40
there's a couple of React demos that I have linked on here on this GitHub page that'll go and show you exactly how you would work React together with RxJS. And in particular, we also have ways of hooking into Angular directly.
49:00
We have an RxAngular library that you can use so that you can really start to attach to the scope directly using RxJS. And that's really a key part. In addition to that, you can use RxJS has a way of already knowing if Ember or Angular is already loaded so that if you want to use,
49:22
you can start to use the event system of Angular directly by using the JQ light or actually JQuery by just doing the from event and it uses native Angular or native JQuery or native Ember, whatever you happen to be using. So we kind of figure out what you're using
49:40
and go from there. Any other questions? Or are minds exploded here? All right, well, thank you very much.