Reactive applications & reactive programming result in flexible, concise, performant code and are a superior alternative to the old thread-based programming model. The reactive approach has gained popularity for a 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, particularly when one realizes that we must be Reactive up and down the entire programming stack.
In this talk we’ll explore what it means to be ‘Reactive’. We’ll examine some of the more interesting tools available to us, some of which come from the Groovy community. Specifically we’ll cover Ratpack, RxGroovy, React, and RabbitMq - along with examples and a sample implementation. We’ll demonstrate how effectively they can work together at each level of the stack - from the front end, to the back end, to handling http requests and message queue events - and how easy it can be to go Reactive all the way down.
16. @svpember
Reactive Services…
• Are Fast and Efficient
• Resist and are Resilient to Failure
• Scale Horizontally to Meet Current Demand
• Are Driven by Asynchronous Messages / Events
36. @svpember
HTTP
• C10k problem
• Nonblocking I/O
• Many popular web servers support async or reactive handlers
• Ratpack’s been doing it for years now
45. @svpember
Messaging
• Non Blocking I/O is vital!
• Need an Asynchronous Message Broker
• Need a dedicated Thread Pool (ExecutorService)
• Message Flow:
59. @svpember
React
• View Library for JS
• Define Components that receive props and maintain state
• + Encourages reusable components
60. @svpember
Stateful Components (“Containers”)
• Maintains internal state of Component
• Written as a class, with a variety of internal functions (e.g. click Handlers)
• Not intended for re-use
• May receive external State as props
• Passes Props to Child Components
• Simple Render functions that may concern layout
• Children can be both Containers and Presentational
• Refrain from ‘raw’ HTML (JSX), CSS, render() should use Presentational Components
• Little-To-No Business Logic
61.
62. @svpember
Stateless Components (“Presentational”)
• No State. Only receives Props.
• Written as a single function (representing the render())
• Ideal if Presentational components are reusable
• Potentially complex render functions. note: calling render() only affects
DOM if props have changed for a component
• No Business Logic
63.
64. @svpember
React
• View Library for JS
• Define Components that receive props and maintain state
• + Encourages reusable components
• + Shadow / Virtual DOM
65.
66. @svpember
React
• View Library for JS
• Define Components that receive props and maintain state
• + Encourages reusable components
• + Shadow / Virtual DOM
• + Reacts to property changes
67. @svpember
React
• View Library for JS
• Define Components that receive props and maintain state
• + Encourages reusable components
• + Shadow / Virtual DOM
• + Reacts to property changes
• + Has a massive ecosystem
69. @svpember
Redux
• Library for handling global state, derived from Flux
• One Immutable Store, but can allow for hierarchy (i.e. not flat shape)
• Strict, Unidirectional Data Flow
• Reducers, Actions, ActionCreators
• Intended for Synchronous change operations
• Hooks for Middleware / plugins
70.
71. @svpember
React
• View Library for JS
• Define Components that receive props and maintain state
• + Encourages reusable components
• + Shadow / Virtual DOM
• + Reacts to property changes
• + Has a massive ecosystem
• - APIs change frequently
72. @svpember
React
• View Library for JS
• Define Components that receive props and maintain state
• + Encourages reusable components
• + Shadow / Virtual DOM
• + Reacts to property changes
• + Has a massive ecosystem
• - APIs change frequently
• - Forces you to think in React
73. @svpember
React: Use If…
• You need a powerful View layer for your frontend
• You appreciate the usefulness of composed, reusable View components
• You have the mental agility to follow and keep up with the latest Javascript
trends
76. @svpember
Ratpack
• NIO HTTP Library
• + Built on top of Netty
• + Fast, lightweight
• + Non-opinionated
• + Excellent Testing support
• + Excellent Gradle support
• - Taking a while to adopt rxJava2
• - It’s I/O thread pool is Unbounded
• - Non-obvious how to access registry / DI during a test
77. @svpember
When to use Ratpack
• You need NIO http support, but don’t want a full framework
• You need to handle high levels of concurrent users
• You’re comfortable going to a conference with many folks from the Grails
team and talking about an alternative solution
79. @svpember
RxJava
• Reactive Streams implementation on the JVM, designed for communication across
boundaries
• + Makes Async / parallel programming ‘easy’
• + Promotes a highly functional, stream-oriented style
• + Promotes stream-oriented programming
• + Backpressure
• + Composable & Cancelable
• + Ideal for inputs of potentially infinite amounts of data
• - Learning curve is steep / new programming paradigm
• - can swallow exceptions if not careful
82. @svpember
When to use RxJava
• You need to write Async code
• You have 1000s+ or potentially infinite events to process
• You want to feel stupid
• You comfortable going to a Groovy conference and telling people you don’t
use GPars
84. @svpember
RabbitMQ
• High Throughput Message Broker
• + Complex and Powerful routing mechanisms
• + High Availability, clustering, back pressure
• + Durability / failure tolerance
• + Easy to deploy / cluster
• - not as fast as other message brokers
• - Written in Erlang
85. @svpember
When to use RabbitMQ:
• You need Async message handling
• You like having simple consumers and smart routing
• You don’t mind being looked down upon by Kafka fans