Functional Reactive Programming - Streams on steroids

Functional Reactive Programming - Streams on steroids

Wojciech Marusarz - July 4, 2018

What is functional reactive programming at all?

Functional reactive programming is a programming paradigm that connects reactive programming with asynchronous data streams and uses building blocks of functional programming. Just like other programming paradigms, it is not a brand new idea. The concept was introduced in 1997, but it gains in popularity since 2014 when Reactive Manifesto, mentioned later, was published.

Why asynchronous data streams?

Usually interaction with mobile, desktop or web applications is about submitting the whole form to the backend and rendering view to the frontend. Nowadays users expect a more real-time experience. After typing some letters in the search field, the user expects to see search results immediately. This is doable if continuous data flow between UI and backend applications is persisted and that’s where data streams play a crucial role.

With reactive programming, it is possible to create data streams out of anything.

Emitted data is captured asynchronously, and handled by defined function. You can also define another function when an error is emitted, and another function when the stream is completed. Sometimes these last two can be omitted, and you can just focus on defining the function for values.

The “listening” to the stream is called subscribing. The functions we are defining are observers. The stream is the observable being observed. This is precisely the Observer Design Pattern.

Why functional programming

Functional Programming raises the level of abstraction of your code so you can focus on the interdependence of events that define the business logic, rather than having to constantly fiddle with a large number of implementation details which are now hidden layer underneath streams. Functional programming also brings a fantastic toolbox of functions to combine, create, map and filter any data streams.

Reactive manifesto

Reactive Manifesto According to the manifesto, reactive systems are

  • Responsive: the system responds on time if at all possible. Responsiveness also means that problems may be detected quickly and dealt with effectively.
  • Resilient: system remain responsive in case of failure, failures are contained with each component isolating components from each other.
  • Elastic: system stays responsive under changing workload, reactive systems can react to changes in the input rate by increasing or decreasing the resources allocated to services.
  • Message Driven: relies on asynchronous message-passing to establish a boundary between components that ensures loose coupling, isolation and location transparency.

Reactive systems are thus more flexible, loosely-coupled and scalable. This makes them easier to develop and to allow changes. They are significantly more tolerant of failure and when failure does occur they meet it with elegance rather than a disaster.

Reactive Programming Implementation

Why should I even care?

Typical server side applications are developed in an imperative style based on subsequent calls of operations that are put on a call stack. The primary function of the call stack is to keep track of the caller of a given routine, execute the invoked routine while blocking the caller in the process, and returning control to the caller with a return value.

For event-driven applications call stack is not the main concern. The primary concern is somewhat triggering events by publishers and monitoring events streams by observers. The big difference between event-driven and imperative style is that the caller does not block and hold onto a thread while waiting for a response.

The event-loop itself may be single threaded, but concurrency is still achieved while invoked routines go about their business (and potentially block on IO themselves) while allowing the (sometimes single) threaded event-loop to process incoming requests.

For the sake of example, let’s look at a time-consuming process like search among big data set which returns the whole response as a single batch. However, what about bringing items just after they are found as in the example below. Records are stored in a big collection in MongoDB, so the search for items that contain phrase takes some time. To increase user experience, records appear on the screen one after another without waiting for the whole operation to complete.

Reactive Movies Example

To achieve such effect as presented above you need to use Server-Sent Events (SSE). API code that produces the stream of movies is really simple. Just note response Media Type which is TEXT_EVENT_STREAM

@GetMapping(value = "/search", produces = MediaType.TEXT_EVENT_STREAM_VALUE)
public Flux<Movie> search(@RequestParam String query) {
    return movieRepository.findByQuery(query);

At client side, you need to handle Event Stream by listening on incoming messages.

  this.loadingMore = true //show progress bar
  let eventSource = new EventSource('http://localhost:8080/search?query=' + query)
  eventSource.addEventListener('message', event => {
    let movie = JSON.parse(
    this.movies.push(movie) //push movie to array observed by VUE
  }, false)
  eventSource.addEventListener('error', event => {
    if (event.eventPhase === EventSource.CLOSED) {
      this.loadingMore = false //hide progress bar
  }, false)

Simple, isn’t it?

Note that Server-Sent Events are not supported by IE, you need to use polyfill to ensure compatibility with your favorite browser.

Reactive programming support

Reactive Programming is supported by a majority of popular languages which implements ReactiveX API like Java, JavaScript, C#, Scala, Kotlin, Python or Go.

For Java, there are two most popular reactive libraries - RX Java 2 and Project Reactor which are very similar. At Nexocode we use Project Reactor for backend since it is used in Spring by default, but there are no obstacles to use RX Java 2 with Spring as well. For front-end application we use RxJS.

Reactor is a fully non-blocking foundation with effective demand management. It directly interacts with Java 8 functional API, Completable Future, Stream, and Duration.

Reactor offers two reactive composable API: Flux and Mono extensively implementing Reactive Extensions. Flux (Flowable in RX Java 2) represents an asynchronous sequence of 0 to N emitted items. Mono (Single in RX Java 2) represents at most one emitted item.

Like other reactive libraries, it brings a ton of useful operators, which you can find in Mono and Flux documentation or you can look at an excellent visualization of stream operators with marble diagrams.

Debounce Animation

Legacy applications

The dream is to write a brand new application without dependencies on legacy databases or legacy APIs. At Nexocode we develop new projects from scratch. Where it is possible, we implement Reactive Programming approach from “top to down” using Reactive Mongo (Spring Data supports MongoDB, Apache Cassandra, and Redis) and WebClient for network communication. Still, we have to communicate with external APIs.

Fortunately, there is a solution for that too. Instead of waiting for external API calls to be completed, reactive libraries bring a set of wrappers, that can create streams over blocking events. That is not a perfect solution since it requires waiting for requests to finish, so it disallows stream processing, but at least the caller’s thread is not blocked, which results in smaller computational consumption.

Any disadvantages?

Generally, I feel that I write more efficient and much more readable code with reactive rather than imperative approach, but Reactive Programming also may have some disadvantages.

First of all, this paradigm is more memory expensive, because it requires to store immutable streams of data most of the time.

From the developer, it requires some effort to change the way of thinking because of different programming paradigm, which is also not described as thoroughly as Object-Oriented programming which is the most popular.

For me, the biggest drawback is that during development, debugging is more complicated, because you need to debug not only your implementation, but also need to take care of correct stream API usage. Furthermore, your implementation is wrapped with stream API.


All of the above scratches the surface of developing reactive applications. It seems that Reactive Programming isn’t just another trend but rather the paradigm for modern software development that encourages writing efficient and readable software that brings user experience on next level.

Regardless of the language or toolkit you choose, putting scalability and resilience first in order to achieve responsiveness is the only way to meet the expectations of users. This will only get more important with each passing year.

About the author

Wojciech Marusarz

Wojciech Marusarz

Software Engineer

Linkedin profile Twitter Github profile

Wojciech enjoys working with small teams where the quality of the code and the project's direction are essential. In the long run, this allows him to have a broad understanding of the subject, develop personally and look for challenges. He deals with programming in Java and Kotlin. Additionally, Wojciech is interested in Big Data tools, making him a perfect candidate for various Data-Intensive Application implementations.

This article is a part of

Zero Legacy
36 articles

Zero Legacy

What goes on behind the scenes in our engineering team? How do we solve large-scale technical challenges? How do we ensure our applications run smoothly? How do we perform testing and strive for clean code?

Follow our article series to get insight into our developers' current work and learn from their experience. Expect to see technical details, architecture discussions, reviews on libraries and tools we use, best practices on software quality, and maybe even some fail stories.

check it out

Zero Legacy

Insights from nexocode team just one click away

Sign up for our newsletter and don't miss out on the updates from our team on engineering and teal culture.


Thanks for joining the newsletter

Check your inbox for the confirmation email & enjoy the read!

This site uses cookies for analytical purposes.

Accept Privacy Policy

In the interests of your safety and to implement the principle of lawful, reliable and transparent processing of your personal data when using our services, we developed this document called the Privacy Policy. This document regulates the processing and protection of Users’ personal data in connection with their use of the Website and has been prepared by Nexocode.

To ensure the protection of Users' personal data, Nexocode applies appropriate organizational and technical solutions to prevent privacy breaches. Nexocode implements measures to ensure security at the level which ensures compliance with applicable Polish and European laws such as:

  1. Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC (General Data Protection Regulation) (published in the Official Journal of the European Union L 119, p 1); Act of 10 May 2018 on personal data protection (published in the Journal of Laws of 2018, item 1000);
  2. Act of 18 July 2002 on providing services by electronic means;
  3. Telecommunications Law of 16 July 2004.

The Website is secured by the SSL protocol, which provides secure data transmission on the Internet.

1. Definitions

  1. User – a person that uses the Website, i.e. a natural person with full legal capacity, a legal person, or an organizational unit which is not a legal person to which specific provisions grant legal capacity.
  2. Nexocode – NEXOCODE sp. z o.o. with its registered office in Kraków, ul. Wadowicka 7, 30-347 Kraków, entered into the Register of Entrepreneurs of the National Court Register kept by the District Court for Kraków-Śródmieście in Kraków, 11th Commercial Department of the National Court Register, under the KRS number: 0000686992, NIP: 6762533324.
  3. Website – website run by Nexocode, at the URL: whose content is available to authorized persons.
  4. Cookies – small files saved by the server on the User's computer, which the server can read when when the website is accessed from the computer.
  5. SSL protocol – a special standard for transmitting data on the Internet which unlike ordinary methods of data transmission encrypts data transmission.
  6. System log – the information that the User's computer transmits to the server which may contain various data (e.g. the user’s IP number), allowing to determine the approximate location where the connection came from.
  7. IP address – individual number which is usually assigned to every computer connected to the Internet. The IP number can be permanently associated with the computer (static) or assigned to a given connection (dynamic).
  8. GDPR – Regulation 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of individuals regarding the processing of personal data and onthe free transmission of such data, repealing Directive 95/46 / EC (General Data Protection Regulation).
  9. Personal data – information about an identified or identifiable natural person ("data subject"). An identifiable natural person is a person who can be directly or indirectly identified, in particular on the basis of identifiers such as name, identification number, location data, online identifiers or one or more specific factors determining the physical, physiological, genetic, mental, economic, cultural or social identity of a natural person.
  10. Processing – any operations performed on personal data, such as collecting, recording, storing, developing, modifying, sharing, and deleting, especially when performed in IT systems.

2. Cookies

The Website is secured by the SSL protocol, which provides secure data transmission on the Internet. The Website, in accordance with art. 173 of the Telecommunications Act of 16 July 2004 of the Republic of Poland, uses Cookies, i.e. data, in particular text files, stored on the User's end device.
Cookies are used to:

  1. improve user experience and facilitate navigation on the site;
  2. help to identify returning Users who access the website using the device on which Cookies were saved;
  3. creating statistics which help to understand how the Users use websites, which allows to improve their structure and content;
  4. adjusting the content of the Website pages to specific User’s preferences and optimizing the websites website experience to the each User's individual needs.

Cookies usually contain the name of the website from which they originate, their storage time on the end device and a unique number. On our Website, we use the following types of Cookies:

  • "Session" – cookie files stored on the User's end device until the Uses logs out, leaves the website or turns off the web browser;
  • "Persistent" – cookie files stored on the User's end device for the time specified in the Cookie file parameters or until they are deleted by the User;
  • "Performance" – cookies used specifically for gathering data on how visitors use a website to measure the performance of a website;
  • "Strictly necessary" – essential for browsing the website and using its features, such as accessing secure areas of the site;
  • "Functional" – cookies enabling remembering the settings selected by the User and personalizing the User interface;
  • "First-party" – cookies stored by the Website;
  • "Third-party" – cookies derived from a website other than the Website;
  • "Facebook cookies" – You should read Facebook cookies policy:
  • "Other Google cookies" – Refer to Google cookie policy:

3. How System Logs work on the Website

User's activity on the Website, including the User’s Personal Data, is recorded in System Logs. The information collected in the Logs is processed primarily for purposes related to the provision of services, i.e. for the purposes of:

  • analytics – to improve the quality of services provided by us as part of the Website and adapt its functionalities to the needs of the Users. The legal basis for processing in this case is the legitimate interest of Nexocode consisting in analyzing Users' activities and their preferences;
  • fraud detection, identification and countering threats to stability and correct operation of the Website.

4. Cookie mechanism on the Website

Our site uses basic cookies that facilitate the use of its resources. Cookies contain useful information and are stored on the User's computer – our server can read them when connecting to this computer again. Most web browsers allow cookies to be stored on the User's end device by default. Each User can change their Cookie settings in the web browser settings menu: Google ChromeOpen the menu (click the three-dot icon in the upper right corner), Settings > Advanced. In the "Privacy and security" section, click the Content Settings button. In the "Cookies and site date" section you can change the following Cookie settings:

  • Deleting cookies,
  • Blocking cookies by default,
  • Default permission for cookies,
  • Saving Cookies and website data by default and clearing them when the browser is closed,
  • Specifying exceptions for Cookies for specific websites or domains

Internet Explorer 6.0 and 7.0
From the browser menu (upper right corner): Tools > Internet Options > Privacy, click the Sites button. Use the slider to set the desired level, confirm the change with the OK button.

Mozilla Firefox
browser menu: Tools > Options > Privacy and security. Activate the “Custom” field. From there, you can check a relevant field to decide whether or not to accept cookies.

Open the browser’s settings menu: Go to the Advanced section > Site Settings > Cookies and site data. From there, adjust the setting: Allow sites to save and read cookie data

In the Safari drop-down menu, select Preferences and click the Security icon.From there, select the desired security level in the "Accept cookies" area.

Disabling Cookies in your browser does not deprive you of access to the resources of the Website. Web browsers, by default, allow storing Cookies on the User's end device. Website Users can freely adjust cookie settings. The web browser allows you to delete cookies. It is also possible to automatically block cookies. Detailed information on this subject is provided in the help or documentation of the specific web browser used by the User. The User can decide not to receive Cookies by changing browser settings. However, disabling Cookies necessary for authentication, security or remembering User preferences may impact user experience, or even make the Website unusable.

5. Additional information

External links may be placed on the Website enabling Users to directly reach other website. Also, while using the Website, cookies may also be placed on the User’s device from other entities, in particular from third parties such as Google, in order to enable the use the functionalities of the Website integrated with these third parties. Each of such providers sets out the rules for the use of cookies in their privacy policy, so for security reasons we recommend that you read the privacy policy document before using these pages. We reserve the right to change this privacy policy at any time by publishing an updated version on our Website. After making the change, the privacy policy will be published on the page with a new date. For more information on the conditions of providing services, in particular the rules of using the Website, contracting, as well as the conditions of accessing content and using the Website, please refer to the the Website’s Terms and Conditions.

Nexocode Team


Want to be a part of our engineering team?

Join our teal organization and work on challenging projects.