Reactive Programming, a shift in mindset

As part of my upcoming book Getting Started With Angular 8, I spent a time researching Observables and RxJs in Angular. In the book I spend a complete chapter going through how Observables work and how RxJs is a JavaScript library that comes with Angular, which helps with working with Observables.

While this chapter gives a detailed explanation of using Observables and Observers, how you use them within your Angular applications.

One thing I have noticed now within the Angular community, there are more and more talks and articles about how to make use of Observables and RxJs to create fully reactive applications.

Now developers are beginning to understand what Observables are and what RxJs brings to their applications, the next question is how can we make use of this to the benefit of our applications? More and more community leaders are showing ways we can use RxJs to make applications more reactive.

Changing the mindset from imperative to reactive

In the Observables and RxJs chapter of the book I go through how to use and Observable with RxJs, but the approach I use is a more imperative approach. Where we create and Observable, set it up and then Subscribe to the Observable when we want to make use of it.
Now after seeing some fantastic talks from NgConf about how we can make use of RxJs to turn how we setup our Observables to make the way data is passed throughout the application more reactive.

Some of the great talks that show this new approach are:

  • Data Composition with RxJs – in this talk Deborah Kurata show a pattern for creating streams of data with RxJs to generate a View Model behind our components. Models that load data via Observables that don’t need to be subscribed to.
  • Mastering the Subject: Communication Options in RxJs – in this talk Dan Walhin shows how we can use the Subject observables to pass data or messages to multiple components within our application.
  • Thinking Reactively – Mike Pearson goes through why thinking in a more reactive approach is a great idea. He makes some fantastic points about why taking this reactive approach will benefit our applications.

Having a more reactive mindset means we use patterns to structure how data is passed into and out of our components, so the application reacts to changes from the user. Building applications this way makes our apps appear faster and more responsive to the user. A fast acting application makes a happy end-user.

As Angular developers I think we should start sharing different approaches to how we can write more reactive Angular applications. If we look at sources from outside Angular, like existing patterns which may not be used currently in this imperative approach. These patterns will help us develop in a more reactive mindset.

These talks are a great starting place if you want to start take your knowledge of Observables and RxJs and how they can be used to making a more reactive application. If you’re not sure how to use Observables and RxJs then feel free to check the chapter in my upcoming book.

Angular and Nest idea for fullstack apps

Photo by Steve Halama on Unsplash

I’ve recently worked on a project where we found ourselves in the situation where we was waiting for some APIs to be developed by the backend team. So in order to not stop our development we decided to look at creating mock APIs.

Now there are many online services that can provide you with a mock end point to work with, but there are limitations with the number of endpoints you can make or the structure of the data you can return.

So we decided to take a look at using NestJS in order to create our mock APIs. First impressions were really positive, as an Angular developer I found getting started with Nest very easy. With Nest using similar concepts to Angular (Services, Modules etc) I found Nest a great way of adding a backend to my Angular application, Nest is something I plan to look at further.

I can see that there will be two approaches to creating a fullstack application, one approach seems to be ReactJS with Node/Express and the second approach is Angular and Nest. If you look at the job market you’ll see a lot of roles where the tech stack is React and Node in order to create a complete fullstack application. Now with Nest becoming more and more popular I can see Angular and Nest becoming a tech stack for creating a fullstack application.

If we look at how Nrwl are developing enterprise applications they are taking this approach of using Angular with Nest as their stack for their clients. As a side note when we decided to create our mock APIs we was using Nrwl’s Nx service, which makes managing the setup of a complete Angular/Nest application so easy and with the addition of Cypress it makes a fantastic complete approach to creating a full stack application.

As an Angular developer I would recommend that any Angular developers look at using Nest even if the applications they build are using APIs created in another language by another team within their organisation. The reason I think we should look at Nest is because if, like I did in this application, you have to wait for the ‘real’ APIs to be ready you could use Nest to create a mock APIs.

Eventually I can see the Angular/Nest approach becoming a standard way of building fullstack applications, which is something I’m planning to work on while I’m between projects.