This is part of my live blogging from QCon 2015. See my QCon table of contents for other posts.

Streams are:

• 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.

Akka

• message oriented programming model for reactive apps
• can be used from Java or Scala.

Actors

• 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

Akka Streams

• 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.