SlideShare utilise les cookies pour améliorer les fonctionnalités et les performances, et également pour vous montrer des publicités pertinentes. Si vous continuez à naviguer sur ce site, vous acceptez l’utilisation de cookies. Consultez nos Conditions d’utilisation et notre Politique de confidentialité.
SlideShare utilise les cookies pour améliorer les fonctionnalités et les performances, et également pour vous montrer des publicités pertinentes. Si vous continuez à naviguer sur ce site, vous acceptez l’utilisation de cookies. Consultez notre Politique de confidentialité et nos Conditions d’utilisation pour en savoir plus.
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.
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.
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”
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:
-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/)
Groovy Options for Reactive Applications - Greach 2015
Reactive Options for Groovy