Gr8conf US 2015: Reactive Options for Groovy
•Transferir como PPTX, PDF•
2 gostaram•1,311 visualizações
Reactive applications and Reactive programming are an alternative to the standard thread-based imperative programming model that can result in flexible, concise code. The Reactive approach has gained popularity recently for one simple reason: we need alternative designs and architectures to meet today’s demands. However, it can be difficult to shift one’s mind to think in Reactive terms. It doesn’t help that the descriptions around the web can be contradictory and the library documentation can be obscure. In this talk, we’ll explore the concepts of Reactive and Reactive Programming. We’ll demonstrate some of the useful Reactive functions and examine some practical implementations - including how we’re currently using Reactive libraries in production code. Most importantly, we’ll look at some of the open source options available to us in the Groovy community, including Reactor, RxJava, and the Java 8 stream API. If Reactive is new to you, this should be an excellent introduction.
Recomendados
Recomendados
Mais conteúdo relacionado
Semelhante a Gr8conf US 2015: Reactive Options for Groovy
Semelhante a Gr8conf US 2015: Reactive Options for Groovy (20)
Mais de Steve Pember
Mais de Steve Pember (19)
Último
Último (20)
Gr8conf US 2015: Reactive Options for Groovy
- 1. THIRDCHANNEL @svpember Reactive Options for Groovy Steve Pember CTO, ThirdChannel @svpember
- 3. THIRDCHANNEL @svpember Possible Reactive Definitions • Reactive Programming
- 4. Imperative: A = B+C at that moment in time Reactive: A = B+C whenever B or C change values
- 5. THIRDCHANNEL @svpember Possible Reactive Definitions • Reactive Programming • Reactive Systems
- 6. THIRDCHANNEL @svpember Possible Reactive Definitions • Reactive Programming • Reactive Systems • Reactive Streams / Reactive Extensions (Rx)
- 7. THIRDCHANNEL @svpember Possible Reactive Definitions • Reactive Programming • Reactive Systems • Reactive Streams / Reactive Extensions (Rx)
- 8. THIRDCHANNEL @svpember Agenda • Reactive Systems • Reactive Streams / Reactive Extensions • Reactive Groovy
- 9. The Need For Reactive (The Reactive Manifesto)
- 10. –Johnny Appleseed “Type a quote here.”
- 11. –Johnny Appleseed “Type a quote here.” http://www.internetlivestats.com/internet-users/
- 13. –Johnny Appleseed “Type a quote here.”
- 14. –Johnny Appleseed “Type a quote here.” https://medium.com/reactive-programming/what-is-reactive-programming-bc9fa7f4a7fc
- 15. Need to Handle As Many Users As Possible
- 16. THIRDCHANNEL @svpember Reactive Systems • The Need for Reactive • 4 Reactive Principles
- 18. THIRDCHANNEL @svpember Reactive Systems • The Need for Reactive • 4 Reactive Principles • Responsive
- 20. THIRDCHANNEL @svpember Reactive Systems • The Need for Reactive • 4 Reactive Principles • Responsive • Resilient
- 21. –Johnny Appleseed “Type a quote here.”
- 22. Embrace Failure
- 25. THIRDCHANNEL @svpember Reactive Systems • The Need for Reactive • 4 Reactive Principles • Responsive • Resilient • Elastic (Scalable)
- 27. THIRDCHANNEL @svpember Reactive Systems • The Need for Reactive • 4 Reactive Principles • Responsive • Resilient • Elastic (Scalable) • Asynchronous / Message-Driven
- 29. Humans Are Terrible At Concurrency
- 32. –Johnny Appleseed “Type a quote here.”
- 33. –Johnny Appleseed “Type a quote here.”
- 34. Never Block Your Resources
- 35. THIRDCHANNEL @svpember Agenda • Reactive Systems • Reactive Streams / Reactive Extensions
- 36. “A standard for asynchronous stream processing of potentially infinite data, across boundaries, with non-blocking backpressure”
- 41. THIRDCHANNEL @svpember Story Time 2012 - MS Open Source’s RX! (wut?)
- 42. THIRDCHANNEL @svpember Story Time 2012 - MS Open Source’s RX! (wut?)
- 44. –Johnny Appleseed “Type a quote here.”
- 45. THIRDCHANNEL @svpember Rx: More Than a Stream • Pull vs Push
- 47. THIRDCHANNEL @svpember Rx: More Than a Stream • Pull vs Push • Observable / Subscriber
- 48. An Observable is a push-based collection
- 49. THIRDCHANNEL @svpember Rx: More Than a Stream • Pull vs Push • Observable / Subscriber • Hot / Cold
- 52. THIRDCHANNEL @svpember Rx: More Than a Stream • Pull vs Push • Observable / Subscriber • Hot / Cold • Composable
- 54. THIRDCHANNEL @svpember Rx: More Than a Stream • Pull vs Push • Observable / Subscriber • Hot / Cold • Composable • Async is Easy!
- 55. The Subscriber & Observable can be independently Async
- 57. THIRDCHANNEL @svpember Rx: More Than a Stream • Pull vs Push • Observable / Subscriber • Hot / Cold • Composable • Async is Easy! • Backpressure
- 60. THIRDCHANNEL @svpember Rx: More Than a Stream • Pull vs Push • Observable / Subscriber • Hot / Cold • Composable • Async is Easy! • Backpressure • Observable Interaction
- 61. THIRDCHANNEL @svpember Rx: More Than a Stream • Pull vs Push • Observable / Subscriber • Hot / Cold • Composable • Async is Easy! • Backpressure • Observable Interaction • You really only need 4 functions
- 62. THIRDCHANNEL @svpember 4 functions! • filter • map / flatMap • groupBy • reduce
- 63. THIRDCHANNEL @svpember Agenda • Reactive Systems • Reactive Streams / Reactive Extensions • Groovy Options
- 64. THIRDCHANNEL @svpember A Few Groovy Options… • Akka
- 65. THIRDCHANNEL @svpember A Few Groovy Options… • Akka • Akka Streams
- 66. THIRDCHANNEL @svpember Akka & Akka Streams • Library • Definition of Reactive System • Typesafe • Actor-Based Concurrency • Implemented Streams on Top of Actor Model
- 67. THIRDCHANNEL @svpember A Few Groovy Options… • Akka • Akka Streams • RxJava / RxGroovy
- 68. THIRDCHANNEL @svpember RxJava • Library • Comes out of Netflix • Part of reactivex.io • Reactive Streams on the JVM
- 71. THIRDCHANNEL @svpember A Few Groovy Options… • Akka • Akka Streams • RxJava / RxGroovy • Ratpack
- 72. THIRDCHANNEL @svpember • HTTP application server • Non-opinionated • Built on Reactive Streams, Netty, Java 8, Guava • Fully embodies reactive
- 73. THIRDCHANNEL @svpember A Few Groovy Options… • Akka • Akka Streams • RxJava / RxGroovy • Ratpack • Reactor
- 74. THIRDCHANNEL @svpember • Library • Reactive Streams • Reactor Pattern • Built on LMAX Ring Buffer / Disrupter
- 76. VS
- 80. THIRDCHANNEL @svpember • Groovy Parallelism and Concurrency • Built into the language! • Actors • DataFlow • Async Closures
- 81. Do I Have Time for a Demo?
- 82. Final Thought: What About Java 8 Streams?
- 83. THIRDCHANNEL @svpember Java 8 Streams • Built into the language • Meant for ‘pull’ on finite Iterables • Parallelization has rather severe problems (e.g. https://dzone.com/articles/think- twice-using-java-8) • No Async • vs Observables -> potentially infinite items, async, with back pressure
- 85. Image Credits • 1000ms Time To glass: https://docs.google.com/presentation/d/1IRHyU7_crIiCjl0Gvue0WY3eY_eYvFQvSfwQouW9368/present?slide=id.g1e697bbb_0_7 • internet users in the world: http://www.internetlivestats.com/internet-users/ • internet users vs Facebook: https://medium.com/reactive-programming/what-is-reactive-programming-bc9fa7f4a7fc • reactivex logo: https://www.stickermule.com/marketplace/2223-rx-reactive-extensions-logo-4 • cheetah: www.livescience.com/21944-usain-bolt-vs-cheetah-animal-olympics.html • dominoes: https://www.flickr.com/photos/louish/5611657857/sizes/l/in/photostream/ • 300 / Spartans: http://www.300themovie.com/ • latop punch: http://walls4joy.com/wallpaper/730566-angry-laptops-punch • mailman: http://thebrandtstandard.com/2013/02/09/u-s-post-office-to-end-saturday-letter-delivery-this-summer/ • actor system: http://letitcrash.com/post/30585282971/discovering-message-flows-in-actor-systems-with • slow down: http://forthefamily.org/reminder-slow/ • Buffalo: http://news.sd.gov/newsitem.aspx?id=15164 • Midvale School for the Gifted: http://www.2ndfirstlook.com/2012/09/gary-larson.html
Notas do Editor
- 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
- So let’s begin. When we say ‘Reactive’, what exactly do we mean? There’s several definitions all with varying meanings. To me, when I hear the term ‘reactive’ I think of 3 possible definitions or interpretations:
- first, ‘reactive programming’
- 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. especially if you work at all with User Interfaces (e.g. Javascript). UIs are all about reacting to user input.
- Moving on… Second definition: Reactive Systems.
- Third: Reactive Streams or Reactive Extensions
- today is about reactive systems and RX I think these concepts are the most exciting and they’re gathering quite a bit of traction
- 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.
- * 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’.
- 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
- <pause> 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,
- Even with this increased demand, users expect their browsing experiences to respond … immediately. And they get angry and impatient when sites are slow
- 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.
- 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
- 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.
- Reactive systems have 4 main principles that are meant to help guide a developer to meet modern system demands.
- 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.
- First: the application must be responsive
- 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
- Next up: your app must be resilient
- 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?
- The resilient principle says that we shouldn’t be scared of our application failing… instead we should *embrace* failure
- -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”…
- Your resilient mantra should be “Independent things fail independently”
- third:
- Your application should stay responsive under load it should react to changes in workload by increasing or decreasing resources
- 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.
- -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
- 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
- Because Concurrency is Hard, The Reactive Manifesto folks highly recommend the Actor pattern.
- 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 Actor systems are very scalable. Can be distributed across threads or even additional systems
- With an Actor model you do not talk to the actors directly. Instead, you send messages into the system. Actors each have a ‘mailbox’, and know how to address messages to other actors or actor types. The actor system than delivers these messages asynchronously
- Key Take away: In a Reactive Application, you must NEVER BLOCK YOUR RESOURCES. Could spend an entire talk on why blocking is bad, and non blocking IO is amazing.
- 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.
- 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? What does something as dramatic as that even look like in terms of code?
- 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. Is everyone here familiar with Streams or pipelines? Not going to sell you. see Fowler. 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.
- 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
- Github used it for everything within their GH for Windows app
- 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
- And in a highly coincidental move, MS decided at that same year to open source their Rx technology.
- And it’s amazing they did that. As a result, several heavy hitters in the JVM space decided to bring the tech to Java
- 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.
- As of a few days ago, we have several libraries which fully adhere to the spec.
- So anyway, what’s all the fuss? Rx is some extensions on the concept of stream programming.
- 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.
- 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
- <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.
- Which leads nicely into this next section. When talking about Observables, it’s important to note whether the Observable is ‘Hot’ or ‘Cold’
- 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
- 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…
- streams are composable.
- 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
- Second is, async behavior is EASY
- I’m only going to mention this briefly, because I haven’t used this too often so I’m not the most knowledgeable about this. 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. Wild stuff
- But anyway, don’t worry about that yet. When you’re just starting out, there’s really only 4 functions that you find using all of the time.
- filter, map / flatMap, groupBy, and reduce
- akka and…
- Can be a bit intimidating at first
- Infamous for having colorful, but often confusing diagrams
- and the descriptions can be a little… obtuse, too.
- … So it’s a Reactive -Stream Based web server. I believe the entire dev team is at this con, which is pretty great
- 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.
- 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
- Here’s that same method. Where did the rest of the code go? First, note the ‘notify’ with a String-based event
- 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
- 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)
- GPARS!
- 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
- All this talk about streams and java… you might be wondering “Why didn’t Steve talk about Java 8 Streams?”
- 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 for all parallel stream operations, across threads. - observables deal with potentially infinite streams the subscribers receive and can offer backpressure