This is part of my live blogging from QCon 2015. See my QCon table of contents for other posts.
- Ephemeral – time dependent
- Possibly unbounded in length
- Focus on transformation and transformation of data
Programming involves moving things from A to B and changing the bytes along the way.
- message oriented programming model for reactive apps
- can be used from Java or Scala.
- unit of proessing a called an Actor
- component with address, mailbox, current behavior and storage
- No CPU cost if actor doesn’t have someting to do. Only use a few bytes each so scale well
- Each actor has a parent- handling for failures
- Higher order abstraction for concurrency
- Solving the 100% case is impossible and 90% case is hard. Akka focuses on 80% case. Solve most problems
- Immutable, reusable, composable, coordinated, async transformations.
- Flows – one input and one output. Not connected to source or destination. Like a reusable pipe. Goal is to describe the transformation.
Types of transformations
- Linear Time-agnotistic -ex common ones like map
- Linear Time sensitive – ex dealing with infinite streams
- Linear Rate detached – ex how deal with buffering
- Linear Async – ex calling a service
- Non-linear – ex binary flow (two inputs going to two outputs), custom stages
Sources – publisher, iterator, future, etc
Sinks – subscriber, foreach/fold/onComplete, ignore, head, etc
Fan in/fan out – merge, zip, etc
Output/Input – Http, tcp, InputStreamSource/OutputStreamSink blocking wrappers, etc
Materialization – taking description of transformation and making it run. Streams are blueprint. Materializer makes it run. Cycles are allowed. Look for troublesome ones.
If can’t solve problem without programming; wnt be able to solve it without programming. Why would be able to tell a computer how to do something if we don’t understand it either.
Push vs pull
- Want to get data across async boundary without blocking back-pressure.
- When pushing data, have to drop if get it too fast.
- “A slow solution is no solution”
- Pull can be slow
- Better: Two way channel – only push when know ready. Know what needed based on requests. Don’t demand 100 ice creams unless know what to do with them. Switching between push/pull and batching requests when know about related ones. Called “dynamic push pull”
Also see The Reactive Streams Initiave
Impressons: good talk; learned a lot. Both about Akka and conceptually. Glad I’m comfortable with the basics of functional programming so it wasn’t overwhelming.