Groovy Options for Reactive Applications - Greach 2015
•Als PPTX, PDF herunterladen•
5 gefällt mir•3,060 views
Performance demands placed on the web applications we build have drastically increased over the past few years. The Reactive approach has gained popularity recently for one simple reason: we need alternative designs and architectures to meet today’s demands. Speed is everything. Reactive applications and Reactive programming are an alternative to the standard thread-based imperative programming model that can result in flexible, concise code. 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.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie Groovy Options for Reactive Applications - Greach 2015
Ähnlich wie Groovy Options for Reactive Applications - Greach 2015 (20)
Mehr von Steve Pember
Mehr von Steve Pember (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Groovy Options for Reactive Applications - Greach 2015
- 1. THIRDCHANNEL Reactive Options for Groovy Steve Pember CTO, ThirdChannel @svpember Greach, 2015
- 3. THIRDCHANNEL 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 Possible Reactive Definitions • Reactive Programming • Reactive Systems
- 6. THIRDCHANNEL Possible Reactive Definitions • Reactive Programming • Reactive Systems • Reactive Streams / Reactive Extensions (Rx)
- 7. All 3 Are Different, But Related
- 8. … Today is About Reactive Systems and Rx
- 9. THIRDCHANNEL Agenda • Reactive Systems • Reactive Streams / Reactive Extensions • Reactive Groovy • Demos
- 11. The Need For Reactive (The Reactive Manifesto)
- 12. –Johnny Appleseed “Type a quote here.”
- 13. THIRDCHANNEL
- 14. –Johnny Appleseed “Type a quote here.”
- 15. –Johnny Appleseed “Type a quote here.”
- 16. Need to Handle As Many Users As Possible
- 17. THIRDCHANNEL Reactive Systems • The Need for Reactive • 4 Reactive Principles
- 18. –Johnny Appleseed “Type a quote here.”
- 19. THIRDCHANNEL
- 20. THIRDCHANNEL Reactive Systems • The Need for Reactive • 4 Reactive Principles • Responsive
- 21. THIRDCHANNEL
- 22. THIRDCHANNEL Reactive Systems • The Need for Reactive • 4 Reactive Principles • Responsive • Resilient
- 23. –Johnny Appleseed “Type a quote here.”
- 24. Embrace Failure
- 27. THIRDCHANNEL Reactive Systems • The Need for Reactive • 4 Reactive Principles • Responsive • Resilient • Elastic (Scalable)
- 29. THIRDCHANNEL Reactive Systems • The Need for Reactive • 4 Reactive Principles • Responsive • Resilient • Elastic (Scalable) • Asynchronous Message-Driven
- 30. Events
- 32. Actors
- 33. –Johnny Appleseed “Type a quote here.”
- 34. –Johnny Appleseed “Type a quote here.”
- 35. Never Block
- 36. THIRDCHANNEL Agenda • Reactive Systems • Reactive Streams / Reactive Extensions
- 37. THIRDCHANNEL Reactive Streams / Extensions • Originally out of Microsoft
- 38. THIRDCHANNEL Reactive Streams / Extensions • Originally out of Microsoft • Brought to JVM
- 40. –Johnny Appleseed “Type a quote here.”
- 41. THIRDCHANNEL Reactive Streams / Extensions • Originally out of Microsoft • Brought to JVM • Designed to Handle Messages Asynchronously Across Boundaries
- 42. THIRDCHANNEL Reactive Streams / Extensions • Originally out of Microsoft • Brought to JVM • Designed to Handle Messages Asynchronously Across Boundaries • Composable
- 44. THIRDCHANNEL Reactive Streams / Extensions • Originally out of Microsoft • Brought to JVM • Designed to Handle Messages Asynchronously Across Boundaries • Composable • Hot / Cold
- 45. THIRDCHANNEL Reactive Streams / Extensions • Originally out of Microsoft • Brought to JVM • Designed to Handle Messages Asynchronously Across Boundaries • Composable • Hot / Cold • Backpressure
- 47. THIRDCHANNEL
- 48. THIRDCHANNEL Agenda • Reactive Systems • Reactive Streams / Reactive Extensions • Groovy Options
- 49. THIRDCHANNEL A Few Groovy Options… • Akka
- 50. THIRDCHANNEL A Few Groovy Options… • Akka • Akka Streams
- 51. THIRDCHANNEL Akka & Akka Streams • Definition of Reactive System • Typesafe • Actor-Based Concurrency • Implemented Streams on Top of Actor Model
- 52. THIRDCHANNEL A Few Groovy Options… • Akka • Akka Streams • RxJava / RxGroovy
- 53. THIRDCHANNEL RxJava • Comes out of Netflix • Part of reactivex.io • Reactive Streams on the JVM
- 54. THIRDCHANNEL
- 56. THIRDCHANNEL A Few Groovy Options… • Akka • Akka Streams • RxJava / RxGroovy • Ratpack
- 57. THIRDCHANNEL • HTTP application server • Non-opinionated • Built on Reactive Streams, Netty, Java 8, Guava • Fully embodies reactive
- 58. THIRDCHANNEL A Few Groovy Options… • Akka • Akka Streams • RxJava / RxGroovy • Ratpack • Reactor
- 59. THIRDCHANNEL • Reactive Streams • Reactor Pattern • Built on LMAX Ring Buffer / Disrupter
- 60. THIRDCHANNEL
- 61. VS
- 62. THIRDCHANNEL
- 63. THIRDCHANNEL
- 64. THIRDCHANNEL
- 65. What About Java 8 Streams?
- 66. THIRDCHANNEL Java 8 Streams • Built into the language • Meant for Finite Iterables • Observables -> potentially infinite items, with back pressure • “Pulling” vs “Pushing”
- 67. THIRDCHANNEL Agenda • Reactive Systems • Reactive Streams / Reactive Extensions • Groovy Options • Demos
- 69. 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/
Hinweis der Redaktion
- Let’s talk about asynchronous data.
- When we say ‘Reactive’, what exactly do we mean? There’s several definitions floating around the internet, all with different meanings. To me, when I hear the term ‘reactive’ I think of 3 things:
- 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.
- Second: Reactive Systems.
- Third: Reactive Streams or Reactive Extensions I’ll explain more about these in a moment.
- while all 3 of these definitions are different they are related.
- however, 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 go over reactive streams cover a short list of options available to us when working with Groovy
- To begin, let’s talk about the need for reactive… straight out of a document called the Reactive Manifesto
- <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.
- Furthermore, the Scale of the internet is growing tremendously The number of users in 2012 of just one site is 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 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
- 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
- In it, the Manifesto declares that there are 4 principles that any application must meet in order to meet customer demand.
- First: the application must be responsive
- This comes right off of the 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: you 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 be able to take up the slack. if a third party service is unavailable, your app should handle it -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 asynchronously This calls for building and using highly concurrent systems 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 Recommended to do this in one of two ways:
- Event
- -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
- Actor system is highly recommended
- 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
- Both patterns have a few things in common, especially that they are asynchronous. They Key Take away: In a Reactive Application, you must NEVER BLOCK YOUR RESOURCES
- pause next up is Reactive streams - I’m going to refer to them as Streams, but I think Extensions is also valid.
- The idea of reactive extensions came out of Microsoft’s “Cloud Programability team” sometime before 2010. It was designed as an interface for integrating multiple asynchronous data sources in the cloud. Github used it for everything within their GH for Windows app, and decided to build their own version for Mac because they loved the pattern so much Microsoft open sourced it in 2012… perhaps to thwart Github?
- a couple years later, several heavy hitters in the JVM area decided to bring Reactive Streams to us.
- People from Netflix, 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.
- This is a tricky one
- both of the subscribers on the branch variable are receiving the same data
- Can be a bit intimidating at first
- Infamous for having colorful, but often confusing diagrams
- and the descriptions can be a little odd, too. I know english, and even that doesn’t help to decipher what that means
- … So it’s a Reactive -Stream Based web server. I think there’s a talk on Ratpack at this conf. You all should attend.
- 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.
- 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)
- 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 - observables deal with potentially infinite streams the subscribers receive and can offer backpressure
- It’s Demo Time (for those of you viewing this later, the url for sample code is: https://github.com/spember/greach2015-reactive-demos/)