# Understanding flatMap and merge in RxJava

DevFeed: [Understanding flatMap and merge in RxJava](<https://devfeed.tech/articles/flatmap-part-1-24795.md>)

Original publisher: [Read original article](<https://akarnokd.blogspot.com/2016/02/flatmap-part-1.html>)

Author: David Karnok (noreply@blogger.com)

Published: 2016-02-24T16:22:00Z

Content type: tutorial

Language: en

Sources: [Akarnokd - Advanced RxJava](<https://devfeed.tech/sources/akarnokd-advanced-rxjava.md>)

Topics: [Programming](<https://devfeed.tech/topics/programming.md>), [Functional programming](<https://devfeed.tech/topics/functional-programming.md>)

Tags: [backpressure](<https://devfeed.tech/tags/backpressure.md>), [callback](<https://devfeed.tech/tags/callback.md>), [consumer](<https://devfeed.tech/tags/consumer.md>), [express](<https://devfeed.tech/tags/express.md>), [functional](<https://devfeed.tech/tags/functional.md>), [map](<https://devfeed.tech/tags/map.md>), [merge](<https://devfeed.tech/tags/merge.md>), [protocol](<https://devfeed.tech/tags/protocol.md>), [rxjava](<https://devfeed.tech/tags/rxjava.md>), [stream](<https://devfeed.tech/tags/stream.md>)

## AI overview

This introductory article explains the outer and inner properties of flatMap, including how it transforms values into Observables whose outputs may vary in time, location, and count. It compares flatMap with merge, describing flatMap as an upstream value-to-Observable operation and merge as an operation over an Observable of Observables. It also discusses backpressure, serialization, and their relationship in RxJava 1.x.

## Source excerpt

Introduction In this blog post, I begin to explain the outer and inner properties of the most used, misunderstood and at the same time, one of the most complex operator there is: flatMap. FlatMap is most useful because it let's you replace simple values with something that can change the output in terms of time, location and value count. FlatMap is misunderstood because it is introduced late, not enough time is spent demonstrating it and often surrounded with functional programming technoblabble. Finally, it's complex because it has to coordinate backpressure of a single consumer and request from multiple sources, and we usually don't know which of them will respond with actual items. Maybe all of them. FlatMap has a companion operator: merge. Merge lets you flatten a sequence of Observables into a single stream of values while ensuring the contract of the Observer, namely, the requirement of non-concurrent invocation of the onXXX methods and the conformance to the onNext* (onError|onCompleted)? protocol. This is necessary because although the individual Observables you merge do conform the same protocol individually, they get mixed in time, location and numbers when you listen to them all at once. Of course, flatMap has to do the same so why are there two operators? The answer is convenience and usage pattern. FlatMap is an in-sequence operator that reacts to values from the upstream by generating an Observable, through a callback function, that is internally subscribed to, coordinated and serialized in respect to any previous or subsequent Observables generated through the same callback function. Merge, on the other hand works on a two-dimensional sequence: an Observable of Observables. There is no function involved here but the operator has to subscribe all of those inner Observables emitted by the outer Observable. The fun thing is, you can express them with the other: Func1<T, Observable<R>> f = ... source.flatMap(f) == Observable.merge(source.map(f)) Observabl