This is part of my live blogging from QCon 2015. See my QCon table of contents for other posts.
Definitions
- responsiveness – behavioral, UI/UX specific
- resilience – operational requirement
- event orientation – transport detail
- async – invocation detail
- scalabillity – business requirement. why scale if not many users
Everyone needs to have an architectural mindset. Experience determines how much can contribute to it.
Ideas come from where demand is. Even if sily idea, ok if people will pay for it.
Components coopratethrough minimal cntracts and expectations. Addition to, not replacement of, traditional approches to development. Still need layers, loose coupling, etc. It is involcation behavior that changes.
Context is reactive – data recived, processed and delivered. Lazy logic. Ready to be called
We’ve been using reactive without noticing.Examples, UNIX pipeline, OS kernel, app container.
Benefits
- Responsive to change. Just have to register/subscribe. Easier to experiment with features
- Resource efficiency. Stay lazy until there is work to do
- Fight or flight – react to changes of behavior
Overcome temptation to go full reactive. For example, can change way notify about events. Also, don’t go reactive when doesn’t apply. For example, CRUD for predictable load. Don’t write own reactive framework.
Rx – reactive extensions works for most apps.
Akka or Reactor – for real time/heavy load apps
Observables
Store and forward – don’t have to do everything in memory
Reactive programming can be functional, but doesn’t have to be
Embrace functional programming for laziness, composition nd side effect freedom
Erlang has “let it crash and bring it back”. It is normal for a small actor to crash. Ops has to learn not to see this in the logs and think something is wrong. Akka has the same idea. Declaratively describe what to do when thing crash.
Use randomness in early testing to avoid laster debugging. Test non-determinism with property tests. Doesn’t assume know everything. Define what good/bad and sends much random data in.
How many people are doing unit tests? Maybe 30% of the audience raised hands.