RxJS, Reactive Extensions for JavaScript, is a library for querying data streams. The library is used for composing asynchronous and event-based programs by using observable sequences. While RxJS has been around for some 5 years, it’s recently been gaining new momentum and recognition, with some hot ticket companies like Netflix as references.

At callstats.io, we’ve been gradually moving to RxJS since July 2016, and it’s really improved the data flow management in our dashboard. In this blogpost, our Lead Engineer Sten Hägglund, reflects on our experiences with RxJS and what we’ve liked and disliked about it.

Got interested in our web dev approach and working with tech like RxJS and React? We’re recruiting software engineers for all parts of the stack!

How we use RxJS at callstats.io?

We use RxJS to create single-directional data flows, a bit similar to what Facebook is doing with their Flux pattern. This means that in our use case, we have one global store with multiple observables. The actions in the flow eventually update 1..N observables from the store. For example, callstats.io is a call quality analytics product, so we might store conference search results as one observable and currently selected app as another. Then, when users switch between their different apps, refreshing search results happens automatically. Again, like on Facebook, observable changes are reflected to components through a higher order component (HOC) that assigns them to props.

Easy, real time updates

Working with RxJS has been an enjoyable experience. Things we’ve appreciated include:

• Timely Updates: The observables will always remain up to date as long as the setup has been done correctly
• Easy Adaptability: Changing a single value will propagate through all of the subscribed observables. For example, selecting a new app will be reflected in all currently loaded data (which in callstats’ case, could be permissions, search results, etc). Currently we’re utilizing this feature quite sparingly though, but we’re planning to use this more in future efforts.
• Easy re-tries: With RxJS, it’s easy to re-create an observable request. We use this extensively to, for example, negate temporary internet issues.
• Real-time updates across the flow: It’s easy to change the data through pub-sub notifications or polling from our backends. A single value update can be set to automatically trigger all the related updates that are required.

Even with all the benefits of RxJS, we’ve struggled with a few aspects, like

• Onboarding: For a new team member, it can be more difficult to follow RxJS flows, compared to React based state updates
• A shift in mindset: Consequently, to successfully use RxJS requires a new mindset. People working with it need to learn and understand how data flows through the observables over time, instead of assuming that data would be static.
• Circular updates: It’s fairly easy to accidentally create circular updates that result in strange results such as your React component re-rendering continuously.

Next steps with RxJS

We’ve been using RxJS for about a year now, and are still in the beginning of our journey. Future goals include designing a pattern that is easier to understand, develop and change - especially for developers without much prior RxJS experience.

Does this sound like something you’d like to help us with? Callstats.io is hiring Dashboard, Full-stack and Server Engineers!