Reactive Programming Interview Questions and Answers

Reactive programming is programming with asynchronous data streams. Event buses or your typical click events are really an asynchronous event stream, on which you can observe and do some side effects. Reactive is that idea on steroids. You are able to create data streams of anything, not just from click and hover events. Streams are cheap and ubiquitous, anything can be a stream: variables, user inputs, properties, caches, data structures, etc. For example, imagine your Twitter feed would be a data stream in the same fashion that click events are. You can listen to that stream and react accordingly.

The Reactive Manifesto is a document that defines the core principles of reactive programming. It was first released in 2013 by a group of developers led by a man called Jonas Boner. The Reactive Manifesto underpins the principles of reactive programming.

A stream is a sequence of ongoing events ordered in time. It can emit three different things: a value (of some type), an error, or a "completed" signal.

Here’s a short list of advantages : avoid “callback hell” a lot simpler to do async / threaded work a lot of operators that simplify work very simple to compose streams of data complex threading becomes very easy you end up with a more cleaner, readable code base

easy to implement back-pressure

Reactive programming is about non-blocking, event-driven applications that scale with a small number of threads, with back pressure being a key ingredient that aims to ensure producers don’t overwhelm consumers. The primary benefits of reactive programming are: increased utilization of computing resources on multicore and multi-CPU hardware and increased performance by reducing serialization Reactive programming is generally event-driven, in contrast to reactive systems, which are message-driven. Thus, using reactive programming does not mean we’re building a reactive system, which is an architectural style.

In concurrent programming an algorithm is considered non-blocking if threads competing for a resource do not have their execution indefinitely postponed by mutual exclusion protecting that resource. In practice this usually manifests as an API that allows access to the resource if it is available otherwise it immediately returns informing the caller that the resource is not currently available or that the operation has been initiated and not yet completed. A non-blocking API to a resource allows the caller the option to do other work rather than be blocked waiting on the resource to become available. This may be complemented by allowing the client of the resource to register for getting notified when the resource is available or the operation has completed.

Promise - A Promise handles a single event when an async operation completes or fails. Note: There are Promise libraries out there that support cancellation, but ES6 Promise doesn't so far. Observable - An Observable is like a Stream (in many languages) and allows to pass zero or more events where the callback is called for each event. Often Observable is preferred over Promise because it provides the features of Promise and more. With Observable it doesn't matter if you want to handle 0, 1, or multiple events. You can utilize the same API in each case. Observable also has the advantage over Promise to be cancelable. If the result of an HTTP request to a server or some other expensive async operation isn't needed anymore, the Subscription of an Observable allows to cancel the subscription, while a Promise will eventually call the success or failed callback even when you don't need the notification or the result it provides anymore.

Observable provides operators like map , forEach , reduce , ... similar to an array. There are also powerful operators like retry() , or replay() , ... that are often quite handy.

In reactive programming, Observables emit data, and send it to the subscribers. This can be seen as data beingPUSHed in reactive programming, as opposed to data being PULLed in imperative programming, where you explicitly request data (iterating over collection, requesting data from the DB, etc).

Observables Observables are the data source /stream can emit multiple values, just one, or none can also emit errors can be infinite or finite, in which case they emit their completion event Subscribers Subscribers subscribe to Observables they consume/observe the data they also receive the errors and completion events from the Observable Operators used to create Observables (timers, ranges, from other data sources)

used to transform Observables (map, buffer, group, scan, etc)
used to filter Observables (filter, distinct, skip, debounce, etc)
used to combine Observables (zip, merge, combine latest, etc)
Schedulers

mechanism that allows us to easily add threading to our Observables and Subscribers

subscribeOn() specifies on which Scheduler to Observables should operate
observeOn() specifies on which Scheduler/Thread the Subscribers should be notified

The fuller concept of reactive programming extends the traditional observer pattern somewhat - instead of just firing a particular action on a single event (such as a user click), you can create and subscribe to streams of such events, and set actions to run based on the events that occur in that stream.

In Imperative programming each line of code is sequentially executed to produce a desired outcome. The imperative paradigm forces programmers to write “how” a program will solve a certain task. Functional programming is a programming paradigm where you model everything as a result of a function that avoids changing state and mutating data. Reactive programming is the practice of programming with asynchronous data streams or event streams. An event stream can be anything like keyboard inputs, button taps, gestures, GPS location updates, accelerometer, and iBeacon. You can listen to a stream and react to it accordingly.

FRP is a combination of Functional programming (programming paradigm built upon the idea of everything is a pure function) and reactive programming paradigm (built upon the idea that everything is a stream (observer and observable philosophy)). It is supposed to be the best of the worlds. In pure functional programming, there are no side-effects. For many types of software (for example, anything with user interaction) side-effects are necessary at some level. One way to get side-effect like behavior while still retaining a functional style is to use functional reactive programming.