Daily Archives: June 20, 2017

reactive programming by example – live blogging from spring days

Posted on by
Reply

Reactive Programming by Example: Intro to Pivotal Reactor
Speaker: Victor Grazi @vgrazi
https://github.com/vgrazi/reactive-demo
See list of all bog posts from conference

What is Reactive

  • Think in streams – but more powerful than Java 8 streams
  • reactive streams – high performance, async stream processing non-blocking back pressure – when ready to stop getting data
  • declarative
  • doesn’t vary much by language

Maven dependencies

  • reactor-core
  • reactor-test – ex: simulate waiting X seconds without actually waiting

Everything is a stream of messages – ex: events, query results, exceptions (errors aren’t special; still a message)
Publisher – Flux emits event messages (Observable in rx-java), immutable
Subscriber – gets next message and handles events on error/complete/subscribe. doOnNext() is like peek() in Java 8 for debugging

Marble diagram

  • treat events as marbles
  • Website: http://rxmarbles.com – can see different operations and drag marbles (on a computer; doesn’t work on iPad)

Creating a flux
Flux.just(singleValue)
Flux.fromIterable/fromArray – to transform from collection/array
Flux.range(startNumber, numberOfElementsInRange)
Flux.interval(Duration.ofSeconds(n)) – emit a value every X seconds
Flux.merge – combine streams
Flux.withLatestFrom – unlike zip, get latest available element rather than getting the “next” one
Flux.create – use lambda to create a listener with logic for publishing elements

Transformations
take
skip
distinct
distinctUntilChanged-only eliminate adjacent duplicates
filter
map
flatMap
zipWith – combine existing stream with another stream in tuples
sort

Differences from Java streams

  • push based,not pull based
  • Attached to real time feeds
  • Conncurrent
  • Back pressure
  • Can only use once
  • Can compose streams (zip/merge)
  • Can fully work with infinite streams

Cold vs Hot Flux
Cold streams are finite, known elements. Hot streams are more realistics

Must call subscribe for anything to happen (like a terminal operator in Java 8 streams)

I learned a lot. Or reviewed a lot and learned some. Having heard this,I realize I had heard some of it before. Also, while the concepts are different than Java 8, knowing Java 8 streams really well helps retain this. The syntax similarities help. As do learning the key differences vs learning every API and not thinking about streams at all. And the demo at the end was easy to follow. This presentation reminds me of Java 8 streams in that it took me a few presentations by different people to finally grok it well.

servlet vs reactive stacks – live blogging from spring days

Posted on by
Reply

Servlet vs Reactive Stacks in 5 Use Cases
Speaker: Rossen Stoyanchev
See list of all blog posts from conference

Asynchronous

  • asynch is a perception from the beholder. For example, HTTP is synchronous but looks async from the server. [i’m a little confused but i think i get the point of this example]
  • Amount of asynchronity is growing. The more you do it, the more complex it becomes
  • Puting blocking component behind a thread pool makes async because now there is a callback
  • Different to do async throughout the app vs one callback in one place

Elastic thread pool
<ul

  • absorb latency of blocking call
  • can be difficult to configure because need enough threads for the number of slow clients so can absorb lateny
  • uses memory from increasing call stack for threads especially at scale.
  • strategy works, but doesn’t scale

Event loop

  • Have only one thread
  • Model is non-blocking

This is how modern HTTP servers work – certain number worker threads and event loop delegates to them

Reactive

  • brings flow control/li>
  • Scale without adding more threads

Java 9 Flow is closest built in option but need library for implementation.Ex Reactor, RxJava

Reactive Stack
Need Spring 5

  • Netty/Servlet 3.1+/Undertow
  • Reactive Streams Reactor
  • Spring WebFlux

Servlet Stack
Need Servlet 3 for async

  • Servlet container
  • Servlet API
  • Spring MVC

The use cases were live examples. It was cool that the Flux API looks like Java 8 streams code.

Showed how backpressure prevents adding more when not ready.

I like the @Tailable annotation – it shows what you can tail the results of while running.

Overall, I learned/reviewed some basics. The use cases were too fast for me to follow. Which is a sign I need to read a book about reactive. I’ve seen some presentations, but I don’t remember enough to recall all the terms fast enough to follow the code examples. That said,live demos are fun.

microservices pattern language – live blogging from spring days

Posted on by
Reply

Microservice s Pattern Language
Speaker: Chris Richardson – @crichardson
See list of all blog posts from conference

Modern software development:moving fast and not breaking things!
Do this with DevOps, Continuous Deployment/Delivery and small autonomous teams

Monolith

  • Not an anti-pattern because it makes sense at one point
  • Can deploy frequently at the beginning
  • Then it grows. Quickly
  • Then ball of mud
  • Get stuck with obsolete tech stack that used when started project

Microservices

  • Architectural styles
  • set of services
  • loosely coupled
  • organized around business capabilities
  • tackle complexity through modularization
  • Improved scalability is secondary (“monoliths can scale quite well”)
  • Each service has own private data store/schema (doesn’t need own database)

Benefits

  • Once agree on APIs cn develop with less communication and integration
  • Easier to understand develop/test
  • Less potential for jar hell
  • Start up time faster which imporves MTTR (mean time to recover)
  • Know who owns each service – with monolith, everyone is responsible so nobody really is
  • Can fail safely with new technology because only affects one service

Downside – Complexity

  • Now have messaging/remote calls
  • Deal with timeouts and partial failures – circuit breaker pattern
  • Multiple databases and transaction management – need series of local transactions
  • Queries more complicated – can’t just join with SQL. Need to call multiple APIs or replicate data
  • Need a lot of automation; a lot of production applications /services
  • New feature needs multiple services to be deployed in right order

Your monolith will grow forever and never get better. Automation makes microservices better. But need some automation as pre-req for successful microservices

Pattern language

  • To solve architectural problems
  • See patterns on microservices.io
  • Chris writing a book on the topic – currently available through Manning Early Access Program (MEAP)
  • Example of a pattern for dealing with querying data from multiple sources: CQRS – command query responsibility segregation – see CQRS pattern on web
  • Chris is still creating new patterns so remember to check back on the site

Overall, I like that more of the presentation was about microservices than the patterns themselves. It shows why this is important and gives the background to read the patterns. I like the patterns he chose to show.