Springone2gx 2015 Reactive Options for Groovy

Editor's Notes

• #2: My name is Steve, and I work for a startup in Boston, MA. Welcome to ‘Reactive Options for Groovy’ Let’s talk about asynchronous data. I should start out by saying that I’m by no means an expert here, but rather a big fan of Reactive.
• #3: So let’s begin. When we say ‘Reactive’, what exactly do we mean? There’s several definitions all with varying meanings. You may have heard about Reactive Streams, or RX, or reactive applications, etc, etc. To me, when I hear the term ‘reactive’ I think of 3 possible definitions or interpretations:
• #4: first, ‘reactive programming’
• #5: Reactive Programming is different from Imperative programming. In Imperative… In reactive… We’ve been working with Reactive programming for years now, even if you don’t know it.
• #6: especially if you work at all with User Interfaces (e.g. Javascript). UIs are all about reacting to user input. those of us that have been building Interfaces with Javascript have (likely) been building Reactive applications all along… assuming that is, that you’ve been Javascripting correctly.
• #7: Furthermore, recently, the JS kids have been flocking towards tools that allow them to build reactive apps and towards reactive functional programming… which is what I really want to talk about today. On the server side, on the JVM, we have the tools - vastly more powerful tools - to bring some of these approaches to the server side
• #8: Moving on… As you might guess, my Second definition: Reactive Systems.
• #9: Third: Reactive Streams or Reactive Extensions
• #10: today is about reactive systems and RX I think these concepts are the most exciting and they’re gathering quite a bit of traction
• #11: agenda for today: talk about reactive systems and what makes a system ‘reactive’ Mostly, though, we’ll be talking about Reactive Streams or Reactive Extensions Will also cover a short list of options available to us in the Groovy ecosystem First up, Reactive Systems and why they’re important.
• #12: * So first up, Reactive Systems. In this definition, Reactive is a pattern for building applications to handle modern demands, and was popularized by an online document called the ‘Reactive Manifesto’.
• #13: The source of reactive systems can be traced to a document known as the reactive manifesto, which has gone through several revisions over the past few years… most recent edition is from this past september * The term was popularized, I believe, by a company currently known as TypeSafe. They maintain the Manifesto. * I think the best way to understand Reactive is to first talk about the problem it aims to solve
• #14: Typesafe has recently had a bit of a rocky relationship with us Spring aficionados In May they decided to change their name, and wrote a blog post about it. They were hoping to find a name evocative of what they do, and were hoping to avoid a market different from monolithic Spring. Which, you know, ok. Spring boot is here and we’re making some sweet microservices with it.
• #15: That post also pushed a speaker at this conference, phil webb, to push out this tweet. If you see Phil, give him a high five. Also, his follow up tweet is very interesting, and we’ll touch on Reactor later.
• #16: <pause> Anyway, Typesafe ( or whatever they want to call themselves now) does have a point. The internet is growing. The number of users on the internet has estimated to grow from 750 million to nearly 3 billion in just 11 years,
• #17: Even with this increased demand, users expect their browsing experiences to respond … immediately. And they get angry and impatient when sites are slow
• #18: Borrowed this slide from ilya grigorik, who introduced (I think) the idea of the 1000ms time to glass challenge… which basically states that your site should render to the screen (or glass) within 1 second of a user interaction. The reason for this is that studies have been done that show that users’s focus and mental concentration goes away when waiting for more than 1 second. Several years ago, an engineer with Amazon named Greg Linden revealed that the company ran experiment where they intentionally slowed down site performance - 100ms delay resulted in 1 percent drop in sales.
• #19: Furthermore, the Scale of the internet is growing tremendously The number of users in 2012 of just one site was equal to the entire internet user base just 6 years before that in 2006. The site is facebook, but still. Just shows you that web sites are facing increasing scaling problems
• #20: Applications need to handle as many users as possible… as efficiently as possible to avoid the stampeding herd problem Many frameworks and server technologies still use technology and patterns since the beginning of web development. E.g. a thread based approach, where one request consumes one thread for the duration of the request. This is especially a problem in a distributed system environment, where that request may need to communicate with other systems.
• #21: Reactive systems have 4 main principles that are meant to help guide a developer to meet modern system demands.
• #22: In it, the Manifesto declares that there are 4 principles that any application must meet in order to fulfill customer demand. Note that being Reactive isn’t a library or a framework, rather it’s a set of design principles that your app should strive to meet.
• #23: First: the application must be responsive
• #24: This comes right off of a previous point about speed. Your application, in general, should respond to user interaction as quickly as possible. A more ‘responsive’ application is a pleasing experience to your end user. The faster your application responds to their input, the less time they sit staring at your app, and the happier they’ll be. Also, it’s just important to be fast. Several years ago, an engineer with Amazon named Greg Linden revealed that the company ran experiment where they intentionally slowed down site performance 100ms delay resulted in 1 percent drop in sales. In other words, slowing down their site by a tenth of a second resulted in a considerable loss in revenue. Which makes sense, right? The faster you can take customer’s orders, the more money you make
• #25: Next up: your app must be resilient
• #26: The resilient principle says that we, as software developers, should have the mindset that at any given moment, your code is going to break. Think to yourself: How coupled is my code? -How many of your systems are held together by quick hacks? (I know I’m guilty of this one) - How dependent on other services, domain objects, third party services, etc is my application? - What happens to my system if any one of those go down?
• #27: The resilient principle says that we shouldn’t be scared of our application failing… instead we should *embrace* failure
• #28: -A Reactive application is resilient to failure. If one component breaks down, the others should not falter. if a third party service is unavailable, your app should have some fallback behavior. -Your system should be able to suffer damage and still operate. -For example, imagine an ecommerce application. if the ability to place orders goes down.. while your team is scrambling to fix, the end user should still be able to browse the products and add items to the cart. -They should just see a message that says “Sorry, order placement will be right back”…
• #29: Your resilient mantra should be “Independent things fail independently”
• #30: third:
• #31: Your application should stay responsive under load it should react to changes in workload by increasing or decreasing resources
• #32: lastly, Reactive applications are message driven via asynchronously methods -Communication within the system should be done via done via asynchronous immutable events, rather than long procedural code.
• #33: -This naturally promotes highly decoupled code. Sender and recipient can be constructed without having to know - or care - about implementation details of the others. I think this is a very important point… and is perhaps the most important facet of Reactive programming as the others may come naturally from adopting this single step By dealing with Message passing instead of direct function calls, this tends to result in building smaller, independent functions Fits nicely into a concurrent, asynchronous framework, whether it be an entire stack like Ratpack, a framework like Netty, or a library like GPars
• #34: However, we humans are not good at Concurrency. Things like Thread safety are very hard. Thus, Reactive systems call for using techniques to abstract the concurrent procedures
• #35: One of the shortcomings of the Reactive Manifesto is that it doesn’t offer concrete examples of what to do, it merely provides a set of principles.
• #36: Because Concurrency is Hard, The Reactive Manifesto folks highly recommend the Actor pattern.
• #37: Obviously, they’re going to recommend their own tools, Particularly their “Reactive Platform” product, which is a bundle including Scala, Play framework, Spark, and this library, Akka Akka is a library for Actors that you can use on it’s own
• #38: very complicated Each actor is a small code block that knows to do a specific action actors == function ? actors are not accessed directly, instead actors exist within an ‘Actor System’. you interact with the system instead of the actors directly. The system abstracts the concurrency techniques
• #39: But for all these diagrams up here, you really only have to end up creating the Actor code itself.
• #40: show example code of an actor This is code from a small demo I worked up a while ago. This toy demo was a simulation of Paddy’s Pub from It’s Always Sunny in Philadelphia. Each of the Drinkers received a message in the form of a Drink, and would reject it if it was not a full point (see line 21)
• #41: Actors each have a ‘mailbox’, and the code you write has to address messages onto the next actor The actor system than delivers these messages asynchronously
• #42: Actor systems are very scalable. Can be distributed across threads or even additional systems
• #43: Anyway, enough about actors
• #44: It should be understood that being reactive is not about any particular architecture, rather it’s a mindset one should follow. And a goal to achieve. By building small, asynchronous, non blocking, resilient code, this allows us to create highly scalable, performant systems to meet user demand.
• #45: Microservices are an excellent derivation of the Reactive mindset, assuming of course that you follow these 4 principles (e.g. build your services to be resilient). It’s also excellent that Spring, particularly now with the rise of Spring Boot, have been pushing us developers towards this trend
• #46: pause next up is Reactive streams  or Reactive Extensions (also known as RX)  - Anyway, Rx is a powerful new programming pattern which has been gaining traction recently.
• #47: If I were to try and describe Rx to you in one sentence, it would be… <read> Now, this may not be entirely correct, but it’s my observation after having worked with this technology for a while now. Fairly dramatic, eh?
• #48: A mouthful, eh? Now compare that with a more succinct definition:
• #49: I put a link to the video here as I’m going to mention it again Anyway, what does something like this even look like? What does something as dramatic as that even look like in terms of code?
• #50: At first glance, and as you might guess, Reactive Streams look just like stream or pipeline based programming. Is everyone here familiar with Streams or pipelines? Not going to sell you. see Fowler. But here’s a quick example
• #51: at first glance, it might seem fairly close to stream or pipeline based programming. Like the Java 8 streams api, or if we decided to chain together some of the groovy closure functions like collect or find. functional programming on data collections, rather than imperative statements in a loop - The reason why we call it Reactive extensions is that it adds functionality onto streams, “streams++” <Go Over example> However… Rx is vastly more complicated than that.
• #52: But first, a story! Rx has a fairly interesting history The idea of reactive extensions came out of Microsoft’s “Cloud Programability team” sometime before 2008. It was designed as an interface for integrating multiple asynchronous data sources in the cloud. This became popular, and the library made it’s way into .NET
• #53: Github used it for everything within their GH for Windows app
• #54: And they loved it! So much so that in 2012 they decided to port the Rx technology to other languages and platforms, so that they could use it throughout the organization
• #55: And in a highly coincidental move, MS decided at that same year to open source their Rx technology.
• #56: And it’s amazing they did that. As a result, several heavy hitters in the JVM space decided to bring the tech to Java
• #57: People from Netflix, Pivotal, Typesafe, Twitter, and many others came together. They made a spec, found at reactive-streams.org to flesh out further how Rx should work.
• #58: As of a few days ago, we have several libraries which fully adhere to the spec.
• #59: So anyway, what’s all the fuss? There’s clearly a reason why all those developers fell in love with itRx is some extensions on the concept of stream programming.
• #61: So anyway, what’s all the fuss? Rx is some extensions on the concept of stream programming.
• #62: Typically when working with an array or an iterable, one loops over the collection, and then pulls out data. I f I were to ask for the data at position 1 in an array, that’s an example of pulling information from the array. It sits there passively until I ask for it. with Rx it’s a bit different, in that our streams are configured to have data ‘pushed’ at them, without asking for it directly.
• #63: which brings us to the next topic. The key components in this pattern: the Observable and the Subscriber. Subscriber may also be called an Observer, and the Observable may sometimes be called a Stream
• #64: <Read> When an observable has a new data item, it pushes out to its subscribers. The subscriber acts as a ‘sentinel’, waiting, potentially asynchronously, for the next data item The observable interface is fairly simplistic: it can do 3 things: send a piece of data, signal that an error occurred, or signal that the data is complete.
• #65: Which leads nicely into this next section. When talking about Observables, it’s important to note whether the Observable is ‘Hot’ or ‘Cold’
• #66: A ‘Cold’ Observable is the most accessible or direct kind. If you’re just starting out, you’re almost certainly going to entirely be using Cold Observables. This is an example of one… generating an observable from a finite list of data
• #67: Hot is a bit different and more advanced slide of a created observable <explain> Two more points come out of this slide, the first being that…
• #68: streams are composable.
• #69: Here we have a stream of sales data being attached to a variable called ‘branch’. both of the subscribers listening on the ‘branch’ variable are receiving the same data that the stream emits
• #70: Second is, async behavior is EASY
• #74: Backpressure is the concept that a subscriber should alert a publisher that it’s sending information to quickly for the subscriber Publishers should not overload subscribers
• #75: One of the most basic versions of this
• #76: Finally, I think this next point is perhaps the most powerful aspect of RX. It’s possible do some wild things with multiple observables. Can combine them certainly, but it’s also possible to have an observable refrain from emitting data until another observable does, or have an observable emit data until it receives data from another observable.
• #77: I’m sure many of us here have written event handlers, event listeners, or have event used something like a listen ONCE handler to unsubscribe. I mentioned a man from Netflix named Jafar Husain earlier, along with a link to a video. You all should find that link and go watch that when you have a moment. One of his key take aways about RX… and this has a JS slant… is that… <read slide>
• #78: Auto complete How many lines of code do you think it is to do this? Excluding the rendering of each image, or course.
• #79: granted, the ‘updateSearchResults’ function is likely a bit lengthily.
• #81: akka and…
• #85: Can be a bit intimidating at first
• #86: Infamous for having colorful, but often confusing diagrams
• #87: and the descriptions can be a little… obtuse, too.
• #89: … So it’s a Reactive -Stream Based web server.
• #90: One of the downsides? Like anything, the documentation is missing many sections. Although, to be fair, the documentation is rapidly improving. It took me 5 sections to find the first ‘TODO’ they also have a very welcoming slack channel. I joined hoping to ask the experts a quick question about configuration. Within 30 minutes or so, I had lengthy, helpful answers from several people (one of them the creator). Also, I was yelled at by fellow speaker dan woods, so, you know, all in all a good time
• #93: lmax ring buffer: LMAX is a financial trading company that is trying to build the fastest trading platform in the world. They open sourced key piece of their technology, called the Disrupter which is based on a ring buffer pattern. Also, In addition to Rx, Reactor allows you to do efficient internal message passing and build Event Driven apps.
• #94: Reactor offers several options for your apps… including using either Reactive streams or what they call the Reactor bus Suppose we had an E-commerce app which included a service which created and processed orders. In this version, we use several additional service collaborators to do things like verifying that we have inventory, charge the user, and send emails if successful or not. Each of those service calls could take a while (checking inventory, sending email, money), which blocks the thread while we wait for each service call. This slows down the request not only for the end user but for any rampaging hordes trying to access our app
• #96: Here’s that same method. Where did the rest of the code go? First, note the ‘notify’ with a String-based event
• #97: On order:created, we execute the first services job Then we check the inventory for holding, and broadcast a new event based on those results
• #98: The moneyService will bill the client if the inventory is good, While the email service will respond either way. -Now, some of might be saying, “But Steve, that code is spread across 3 different slides!”. While, true, which of these would you rather use? Which version do you think is more decoupled? Which would be easier to test? -(Imagine having to mock all these services as collaborators, versus simply creating events)
• #99: GPARS! There will a talk just on GPars alone tomorrow by Ken Kousen. So look out for that one
• #101: load demo app basic print group by user, filter by items greater than 5 or something separate stream for 0 only go back and group by user and then location
• #103: - know when to async / when not to async
• #104: All this talk about streams and java… you might be wondering “Why didn’t Steve talk about Java 8 Streams?”
• #105: Java 8 Streams API      -at first seems great      - built into the language!      - streams api meant for finite iterable objects to pull from - parallelization support is weak. Uses a common resource pool (ForkJoin) for all parallel stream operations, across threads.      - observables deal with potentially infinite streams the subscribers receive and can offer backpressure
• #106: I hope you find this presentation, at the very least thought provoking, along with the several others on Reactive that are at this conference. I think it’s telling that there are 4 or 5 talks on Reactive this year. I think that as the popularity of Microservices increases
• #107: I mentioned earlier that Microservices can be an excellent application of Reactive. To clarify, I believe that being Reactive, following the Reactive Principles, thinking in terms of streams… are the blueprint of how Microservices should be built in order to succeed.