RxJS 5.5.0-beta.0 was released on 22nd of September and the main feature it introduces is the new way to apply operators on observables. This feature is called lettable operators. In this blog post I’ll explain what lettable operators are, what problems are they addressing and why I feel the way they are released is not optimal for the future of RxJS 5.

Lettable Operators

Let’s start by taking a look at what do the lettable operators look like:

import { range } from 'rxjs/observable/range';
import { map, filter, scan } from 'rxjs/operators'; // Point 1
const source$ = range(0, 10);
source$.pipe( // Point 2
  filter(x => x % 2 === 0),
  map(x => x + x),
  scan((acc, x) => acc + x, 0)
.subscribe(x => console.log(x))

The example code above is from from RxJS’s own introduction.
We can see that there are two main differences to the “traditional” RxJS 5:

  1. Operators are imported by name from new package called rxjs/operators. Before they were patched automatically on Observable.prototype with import 'rxjs/add/operator/<operator name>'.
  2. We now use a new method called pipe that takes varying number of these operators as parameter and then applies them one by one. Pre-5.5 they were chained as method calls. This was possible since they were found from the prototype of the Observable.

Let’s first discuss the point number one. The way the operators were imported pre-5.5 was cumbersome as there was no automatic importing available. Also the error messages for missing imports were hard to interpret. The 5.5 way provides a better developer experience by allowing code completion with automatic import generation as the operators are explicitly imported from the package. It also allows more optimizations as it is easy for the optimization tools to drop out the unused operators in a process called tree-shaking. This was also somewhat possible with pre-5.5 way to import but not all optimization tools supported it this way and it was really easy to forget to remove the unused imports as it wasn’t noticed as unused by linters and compilers. Also, each import was global as the imports patched the global Observable which lead to a confusing situation where the import was only required for the very first usage of an operator in the project and after that it was available in other files too. This also applied for all of the usages in libraries used by the application.
The second difference makes the code a little more verbose by enforcing the usage of yet another method (pipe) to apply the operators. It may not seem too verbose but it can still add up for example in a case where you have multiple functions chained with each applying a bunch of new operators to Observable before returning it. Now on each function you need to first call the pipe and then pass operators to it as parameters. Maybe not the most verbose thing in the world but still noticeable difference in usage as it comes up all the time.

The Benefits of Lettable Operators

We already covered three of the four main reasons to use the lettable operators described in the RxJS’s own write-up. These were augmentation of Observable.prototype (first point on post), missing compatibility with tree-shaking (point two) and missing support for linters and build tooling (point three).
The fourth point is about the easiness of creating custom operators. Even though declaring your own operators has been possible since the release of RxJS 5, it hasn’t been so easy. RxJS 5.5 improves on this as the methods are now just functions which return a new function with signature of ((source: Observable<T>): Observable<R>). This approach is called function composition and it is the essential idiom behind lettable operators and their benefits. If you wonder why an operator is a function returning a function, just think about how the operators are consumed like for example map(x => x * x) and take(5). Let’s take an example of a simple custom operator that simply uses the existing map to implement toPower operator that raises the number in stream to power of the parameter n.

import { Observable } from 'rxjs/Observable';
import { map } from 'rxjs/operators';
export const toPower =
  (n: number) =>
    (source: Observable<number>): Observable<number> =>
      source.pipe(map((x: number) => Math.pow(x, n)));

which could then be used as

import { range } from 'rxjs/observable/range';
import { toPower } from './to-power.operator';
range(0, 10).pipe(toPower(3)).subscribe(x => console.log(x))

The benefits gained from lettable operators are – without a doubt – huge. It improves the tooling, bundle sizes and developer experience without any obvious drawbacks.

So What Is Wrong With Adding the Lettable Operators?

So based on the beginning of the post the lettable operators are simply awesome. The problem isn’t actually the implementation and features of lettable operators but instead on the hardness of wrapping your head around reactive programming in the first place. I know this first-hand based on the numerous trainings I’ve held that have included a lesson on reactive programming with RxJS.
Reactive programming is one of the hottest topics in the industry at the moment. Yet, I rarely face a candidate in a job interview that has actual experience with reactive programming. Only a few more even know what it means. It is a shame but I’m convinced this will change in the upcoming years as so many important players in the field are bringing reactive programming as an essential part of the solutions they are providing. EcmaScript proposal about Observables (currently ready to move to stage 2 out of 4 stages before reaching the standard) is a great example even though it will take years to make it through to the published standard. Also very significant frameworks, like Spring 5 WebFlux (Reactor) and Angular (RxJS) to name a few, have adopted reactive programming as the core of their implementations.
So why hasn’t RxJS gained as much traction as it should have? I think the main reason is that it simply has been overally too complex to use. I’ve seen this first-hand in multiple projects where it has been constant frustration for programmers not used to it. There are multiple points that have made it hard for beginners to get started:

  • RxJS 4 vs. 5: Still today googling brings up results for version 4 instead of the 5 and they are hard to differ from each other as they share the very same terminology.
  • Import format for operators as discussed above.
  • Poor documentation: Check out for example the documentation pages for the first subjects presented in the docs – AsyncSubject & BehaviorSubject. Also the documentation itself seems not to be so search engine friendly. For example googling rxjs timer doesn’t even show the link to corresponding method in RxJS 5 documentation. Instead it brings up the RxJS 4 documentation as a first result. Thankfully the RxJS 4 documentation was added a link to point to the RxJS 5 documentation on top of the page some time ago.
  • Cold vs. hot observables: Everything in JS world has always been hot. RxJS observables being always cold is a constant source of confusion for newcomers.
  • Completability and cancelling: Subscriptions can be cancelled (unsubscribed) unlike promises and callbacks. It is a great feature but it adds up on the burden.

The list is not comprehensive but underlines the fact that RxJS already contains enough confusing elements. Adding a second syntax for such an essential parts like operator applying and imports makes it even harder to adopt by newcomers. For this reason I don’t think it is/was a good idea to release these changes as 5.5 and as an alternative syntax.

What Should’ve Been Done Instead?

Not meaning to pick on the authors of RxJS at all (they’ve done outstanding job on RxJS 5 and I really appreciate it) but maybe this could’ve been thought once designing the library API in the first place as the JS world wasn’t that different when releasing RxJS 5.0.0 less than one year ago. Well, easy to say now and cannot be changed anymore.
I think a better way to implement this kind of major change would’ve been to release RxJS 6 with deprecation or removal of the old syntax and imports. I’m not quite sure whether deprecation or removal would’ve been the correct choice as they both have their benefits and disadventages.
Deprecation would left the confusing syntax to exist and be found all around. Yet, it would give a lot of time for developers to slowly migrate out of the old syntax with meaningful warnings shown for the usage of deprecated way.
Removal of the old syntax would mark a clear difference on the RxJS 5 and 6 thus being clear what is needed to move to RxJS 6. After all, the changes required are straightforward and easy to apply.


Lettable operators are here to stay and they are a great improvement on the developer experience of RxJS 5. Yet, they add even more cognitive burden to newcomers trying to absorb the reactive paradigm and RxJS 5. Thus, I would’ve loved to see them only brought in as a new major version (RxJS 6) with deprecation or removal of the earlier syntax.
Who knows if this could still be affected. RxJS 5.5 is still in beta 0 after all. Let me know what you think about the topic on comments below!

Roope Hakulinen

As a lead software developer Roope works as team lead & software architect in projects where failure is not an option. Currently Roope is leading a project for one of the world's largest furniture retailers.

Do you know a perfect match? Sharing is caring

Business design, explained

What is Business design? How should customer needs be taken into account in strategic decision making? This brand new Gofore’s Business design booklet gives you answers to these questions.
This booklet provides an introduction to the topic of business design. The purpose is to define what business design means in practice and to give examples of challenges solved within business design projects.
– The key in business design is to involve both company experts and customers to identify new business opportunities, Senior Business Designer Hanna-Riikka Sundberg, booklet author.
Co-operation between these parties guarantees that the identified business opportunities respond to both the customers’ needs and the company’s strategic goals.
Our goal at Gofore is to work with clients to define their specific business design and look at how they can develop their business in a more customer-oriented way. The contents of this booklet are based on the knowledge gained from several business design projects and discussions with colleagues and peers on the topic. It is also written to inspire readers to think about customer and user experience in a new light when designing services and making strategic decisions.
The Business design booklet is written for anyone interested in getting an initial glimpse into the topic, professionals working among business design related issues, and for those who believe that business design is the answer to finding new opportunities in increasingly competitive markets.

Download the booklet here.


More info about Gofore’s Business design services:
Soile Roth, tel. + 358 400 782 737,

Hanna-Riikka Sundberg

Hanna-Riikka works as a Senior Business Designer at Gofore. She is responsible for creating new business models and services by bringing the needs of customers and users into strategic decision-making. This she has done for OP, Telia, MTV, Tikkurila, Raisioagro, Wärtsilä, and Andritz, among others. Hanna-Riikka holds a PhD in Industrial Management (with distinction). She is also an Executive MBA (EMBA) trainer at Edutech in the Customer and user experience in business development program. She is the author of the Business Design booklet.

Do you know a perfect match? Sharing is caring

With the merger of Gofore and Leadin at the end of May, we received a lot of new opportunities and challenges and also new muscle to carry out challenging tasks of digital transformation of organizations in Finland and Europe. The recent history of Gofore has been very successful, mostly due to our work within the Finnish public sector. The language used within Gofore has traditionally been Finnish, and knowledge of the Finnish language has always been a requirement for employees also.
Many things have changed with the merger. Leadin brings in a lot of new diversity, industrially based customers and most interestingly of all, international operations with international clients. As a result of this, the company language is now moving more towards English. Gofore now has operations in the UK, Germany and three locations in Finland.
I have enjoyed my over 10-year journey with Gofore helping mainly Finnish customers with their digital transformation. However, this was a perfect time for me to change the scope a bit. In the beginning of June, I joined our team of experts that works for the most important industrial customer, the German originated Voith.

Industrie 4.0

Industrie 4.0 is a German-government-sponsored vision for advanced manufacturing and refers to what is considered to be the fourth industrial revolution, following water and steam power, mass production and automation through IT and robotics.

Picture: Christoph Roser at AllAboutLean.com

Revolution is a fundamental change of old structures and methods that takes place in a relatively short time. As with a revolution in general, industrial revolution means that some of the old successes will die and new ones will rise. Even a giant can fall if they are not keeping up with the current fast occurring changes.


Voith, which was founded around the time the first industrial revolution took place, has successfully applied changes from the industrial revolutions ever since. The global industry leader, with 150 years of history, operates, for example, in the fields of hydropower generation, paper technology and power transmission and is one of the largest family-owned companies in Europe with around 19,000 employees and sales of €4.3 billion.
I have no doubt Voith will benefit hugely from, and be at the forefront of this fourth industrial revolution. The effort invested in the development of projects such as the industrial internet as well as other completely new business models, is remarkable and it is imperative this development continues, especially when such fundamental changes are happening not only rapidly but also on such a regular basis. Simply put, Voith has unbeatable expertise within the industrial areas that they operate in and have a clear vision for the steps required to remain on the top during the fourth industrial revolution. We at Gofore are delighted to be helping Voith achieve another success story in their long history.
When I had the opportunity to join the team, it became quite clear to me that in order to be able to help the customer the best possible way, it would be very beneficial to be near them. It was also something I was more than happy to do. Without too much planning, in the beginning of July, I packed my family together with necessary things into our car and started driving towards the Voith headquarters located in Southern Germany.


My family had the opportunity to spend the summer in the lovely Swabian town of Heidenheim, which is where the Voith headquarters is located. Despite the town being in the beautiful countryside of Baden-Württemberg, the atmosphere and work environment in Voith Digital Solutions, where I spent my working days, is very international, with many people with a multitude of different nationalities working together to achieve a common goal, with English being used as a common working language. Sometimes the working days were long, but I still had plenty of free time to enjoy the Southern Germany and the neighbouring surroundings.
As a nature and mountain lover, I really enjoyed the hiking and mountain biking in the woods and on the hills in the region. We also went on a few weekend trips to some of the medieval towns, bigger cities and amusement parks like Legoland. Maybe the most memorable moments we had, were on a weekend trip to Austria, where we experienced skiing in the heat of July and hiking in breath-taking scenery.


While in Germany, it would be rude not to mention the fantastic beer that is available and the environment in which to enjoy it. The nice varieties of wheat beer called Weizenbier or Hefeweizen (wheat beer) or Weißbier (white beer), were most enjoyable and available everywhere in the region.
Alas, our time in Germany was interrupted by the children’s need to return to school, and with that time approaching we had to head back to Finland. Fortunately for me, I still continue working with the wonderful people involved in the programme. I appreciate the expertise of people of Voith as well as the new colleagues I have met during the past few months. And even while writing this, I am preparing for the next trip back to Heidenheim, the flight being early tomorrow morning. This time I am not able to take my family with me and the stay will be shorter, but nevertheless, I am very much looking forward to it. I will have some free time next weekend and I am going to spend it in Munich and enjoy the beginning of Oktoberfest.

Sami Kallio

Do you know a perfect match? Sharing is caring

My previous blog post introduced MongoDB, which was one of the first ‘not only SQL’ (NoSQL) databases. The blog post explained how MongoDB became almost synonymous with the NoSQL movement and how MongoDB’s rival enemy PostgreSQL responded. This blog post clarifies more reasons regarding MongoDB’s failure and reveals a glimpse of the future of the DBMS market.
New Kids on The Data Block
When MongoDB was launched, the NoSQL ecosystem was just developing. MongoDB’s competitors were old relational databases that had been on the market for ages. However, where there is demand there will be supply.
Completely new kinds of NoSQL-databases arose in the late 2000s and early 2010s. A good example was a real-time data and performance-optimised, key-value database Redis. The column-family database Cassandra, originally designed by Facebook, was another new competitor. Cassandra focussed on massive datasets and a linear scalability, and was the rational choice for huge Big Data projects. The dramatic growth of content and data search created specialised search engines such as Elasticsearch and Solr. In addition, new time-series databases like InfluxDB  were born, and they suit IoT- and sensor-based worlds extremely well. All the new NoSQL databases were exceptional in their own area and attracted old MongoDB customers.
Cloud-computing platforms, such as Amazon Web Services (AWS) and Azure, also launched their own database services. These platforms offered an easy setup, an unlimited scaling option, and a refreshing pricing model. However, advanced competitors were not MongoDB’s only enemies.
MongoDB in the Mirror
After initial enthusiasm, the first discords arose in the MongoDB-related projects. Software developers suffered various and often unusual problems. Compared to other trendy technologies, MongoDB seemed untrustworthy for products meant for a real environment.
With MongoDB’s dynamically typed schema—or in other words, “schemaless”—the benefits are easy setup and data modelling flexibility. However, this doesn’t come without a cost. A schema guarantees that the data can be stored in a consistent format. Without a schema, the responsibility of database consistency shifts to the application. A schemaless database makes the code more error-phone, increases code duplication, and easily creates deeply-nested structures.
The number one priority all databases is to store the data and keep it safe. Rumours started to spread that MongoDB’s consistency model was broken by design and that it might lead to data loss. MongoDB was accused of a lack of the product development discipline, monetising the NoSQL-market, and a slow customer support. In the end, MongoDB, Inc.’s CTO replied to the rumours in an open letter. It remains unclear if MongoDB can really lose the data, but the scandal damaged its reputation badly.
MongoDB has also suffered multiple growing pains. Lockdown problems, complicated sharding, bugs in replications, and unsafe writing are just a few to mention. In response to a critique, MongoDB released major updates, published support blogs, and organised conferences and hackathons. Unfortunately, this did not change the general opinion.
Finally, the developer community turned against MongoDB. Blogs such as Why You Should Never Ever Ever Use MongoDBGoodbye MongoDB Hello PostgreSQL, and MongoDB Frankenstein Monster NoSQL databases strengthened the negative atmosphere. The Reddit message board even contains a huge joke thread about MongoDB’s weak points.
Reality Bites
MongoDB started to become sandwiched between traditional relational databases and new NoSQL databases. Many products still need strong relational consistency, reliability, and referential integrity. Alternatively, startups are looking for more database as service solutions.
A microservices architecture encourages developers to use multiple databases in one system. With a microservices architecture, it’s possible to use MySQL for the business data and Elasticsearch for the logging purpose. MongoDB’s ‘something for everybody’ strategy did not seem valid anymore.
The database ecosystem will fragment even more in the next years. MongoDB will remain in history as a main character of the NoSQL movement. Sadly for MongoDB, history has taught us that the first rebels are not the leaders after revolution.
Graphic Design
Esa Lahikainen

Juhana Huotarinen

Juhana Huotarinen is a lead consultant of software development at Gofore. Juhana’s background is in software engineering and lately, he has taken part in some of the biggest digitalisation endeavours in Finland. His blogs focus on current topics, involving agile transformation, software megatrends, and work culture. Juhana follows the ‘every business is a software business’ motto.

Do you know a perfect match? Sharing is caring

In 2015 MongoDB, Inc. published a press release that its influence has grown more than 163% in the past two years and has overtaken PostgreSQL in the DB-Engines database ranking. In addition, 27 of the Fortune 100 companies used MongoDB in their business in 2013. However, in the database management system (DBMS) league you’re only as good as your last game.
Based on the same DB-Engines database ranking, MongoDB hasn’t gained popularity in 2017. On the contrary, its influence has started to sink in the past months. Why didn’t MongoDB win the DBMS market after all?

Not a One-Hit Wonder

MongoDB’s story started in 2007 when the team behind DoubleClick created a database for their scalability and agility needs. MongoDB was one of the first document-oriented database and quickly got the developers’ attention. MongoDB seemed fresh and exciting.
MongoDB simplified development, because documents map to object-oriented programming languages naturally and remove complex object-relational mapping (ORM) layer. MongoDB’s dynamic schema model likewise meant that a database schema can evolve with business requirements. MongoDB also scaled with no downtime and without application changes, which is a huge advantage if data volume and throughput significantly grow.
MongoDB’s popularity growth had a strong bond to the emergence of JavaScript in the late 2000s. MongoDB and JavaScript use the same JavaScript Object Notation (JSON) standard for representing data structures. For the first time, it was possible to create an enterprise web application without impedance mismatch and data conversion.
The global startup movement also gave a boost to MongoDB. Startups work with proof-of-concepts, how to decrease time-to-market, and dynamic business models. Startups often needed a software to implement their product, and MongoDB was an effortless choice with its quick deployment and dynamic schema model.
When the term NoSQL was reintroduced in early 2009, MongoDB was almost a synonym of a NoSQL-database. However, NoSQL defines all kinds of non-relational databases, not only document-oriented databases. MongoDB even established “MongoDB University” where certifications and multiple online courses are available for everybody.

Return of PostgreSQL

One of MongoDB’s rival enemies is PostgreSQL. Unlike MongoDB, PostgreSQL was a traditional relational database created in the 20th century. PostgreSQL gained popularity over the years, but it had the same weaknesses as other relational databases.
PostgreSQL released version 9.4 in the end of 2014. This version contained support for HStore and JSON, which actually turned PostgreSQL into a document-capable database. On top of that, PostgreSQL 9.4 outperforms MongoDB its own backyard —in performance tests.
This changed the game between these two competitors. In a new project, it was safer to choose PostgreSQL over MongoDB, because PostgreSQL supported relational and document databases features. For the same reason, switching from PostgreSQL to MongoDB in an existing project wasn’t a topic anymore. The result was that PostgreSQL overcame MongoDB in the DB-Engines database ranking in 2017.
My latter blog post continues analysing the reasons of MongoDB’s recession and offers a glimpse in the future of the DBMS market.

Graphic Design

Esa Lahikainen



Juhana Huotarinen

Juhana Huotarinen is a lead consultant of software development at Gofore. Juhana’s background is in software engineering and lately, he has taken part in some of the biggest digitalisation endeavours in Finland. His blogs focus on current topics, involving agile transformation, software megatrends, and work culture. Juhana follows the ‘every business is a software business’ motto.

Do you know a perfect match? Sharing is caring