This chapter covers:
- Why streams are a useful abstraction on top of eventing
- What is back-pressure and why it is fundamental with asynchronous producers and consumers
- How to parse protocol data from streams
So far we have been processing events using callbacks, and from various sources such as HTTP or TCP servers. Callbacks allow us to reason about events one at a time.
Processing an incoming data buffer from a TCP connection, from a file or from a HTTP request is not very different: you need to declare a callback handler that reacts to each event and allows custom processing.
That being said, most events need to be processed as series rather than as isolated events. Processing the body of a HTTP request is a good example, as several buffers of different sizes need to be assembled to reconstitute the full body payload.
Since reactive applications deal with non-blocking I/O, efficient and correct stream processing is key. Let us see why streams pose challenges, and how Vert.x offers a comprehensive unified stream model.
Vert.x offers a unified abstraction of streams. A read stream is a source of events that can be read, while a write stream is a destination for events to be sent. As an example, a HTTP request is a read stream, while a HTTP response is a write stream.
Streams in Vert.x span a wide range of sources and sinks, including those from table 4.1.