DEV Community: Matthew

2FA with NestJs & passeport using Google Authenticator

Matthew — Thu, 07 Jul 2022 12:45:30 +0000

I recently had to implement a two factor authentication on a project for my company and it was a whole new thing for me. Sure I had already used 2fa before but I had never implemented it.

What is 2fa ? Well we all know that passwords aren't really secure enough to avoid security breaches so...

2FA is an extra layer of security used to make sure that people trying to gain access to an online account are who they say they are. First, a user will enter their username and a password. Then, instead of immediately gaining access, they will be required to provide another piece of information.

In this case, I was asked to use the google authenticator app to generate a 2fa code that would be used to authenticate the user after the login step.

I'll be using nestJs with passportjs. Here's the GitHub link if you want to check it out: https://github.com/MatthieuHahn/2fa

Initializing the NestJS project with basic login password authentication

Let's create a new nestJs project.

nest new 2fa

Creating the authentication module

First let's install the nestJs passeport dependencies and types. We'll need them in the next step.

yarn add @nestjs/passport passport passport-local
yarn add -D @types/passport-local

Then, we'll generate the authentication module, controller and service.

nest generate resource authentication

It'll ask you a few questions: choose REST API and then answer No (it's an auth module, we don't need CRUD endpoints)

Then we'll create a user module, service and interface

nest generate module users

nest generate service users



export interface User {
  userId: number;
  username: string;
  password: string;
}

The users service will contain fake data, but, of course, you should add a data layer to persist data 😅



import { Injectable } from '@nestjs/common';
import { User } from "./user.entity";

@Injectable()
export class UsersService {
  private readonly users = [
    {
      userId: 1,
      username: 'john',
      password: 'changeme',
    },
    {
      userId: 2,
      username: 'maria',
      password: 'guess',
    },
  ];

  async findOne(username: string): Promise<User | undefined> {
    return this.users.find(user => user.username === username);
  }
}

Let's add a validateUser method that will check if the user and password that we'll send are a match with our data.



import { Injectable } from '@nestjs/common';
import { UsersService } from "../users/users.service";
import { User } from "../users/user.entity";

@Injectable()
export class AuthenticationService {
  constructor(private usersService: UsersService) {
  }

  async validateUser(email: string, pass: string): Promise<Partial<User>> {
    const user = await this.usersService.findOne(email);
    try {
      // Of course, we should consider encrypting the password
      const isMatch = pass === user.password;
      if (user && isMatch) {
        const { password: _, ...userWithoutPassword } = user;

        return userWithoutPassword;
      }
    } catch (e) {
      return null;
    }
  }
}

If you are not familiar with nestJs, this framework provides a UseGuard decorator that will act as an auth middleware which can rely on the passportjs library. So let's use this feature and the nestJs passport library to manage the user/password login.

First we define the local auth guard which extends the passportjs local strategy.

local-auth.guard.ts



import { Injectable } from '@nestjs/common';
import { AuthGuard } from '@nestjs/passport';

@Injectable()
export class LocalAuthGuard extends AuthGuard('local') {}

And then we define the local authentication strategy. The constructor contains the auth fields that will be sent by the front-end via the login POST route (email, password).
The validate method will use the validateUser method we created earlier. If it returns no user, then it will throw a 401 Unauthorized error, else it will return the user without the password.

local.strategy.ts



import { Strategy } from 'passport-local';
import { PassportStrategy } from '@nestjs/passport';
import { Injectable, UnauthorizedException } from '@nestjs/common';
import { AuthenticationService } from '../authentication.service';
import { User } from '../../users/user.entity';

@Injectable()
export class LocalStrategy extends PassportStrategy(Strategy) {
  constructor(private authenticationService: AuthenticationService) {
    super({
      usernameField: 'email',
      passwordField: 'password',
    });
  }

  async validate(email: string, password: string): Promise<Partial<User>> {
    const userWithoutPsw = await this.authenticationService.validateUser(email, password);
    if (!userWithoutPsw) {
      throw new UnauthorizedException();
    }
    return userWithoutPsw;
  }
}

We can now create the login method in the authentication controller and service. For now it'll only return the user's email. But later on, we'll add a Jwt access token

First we add the login method to the authentication service.



async login(userWithoutPsw: Partial<User>, isTwoFactorAuthenticated = false) {
    const payload = {
      email: userWithoutPsw.email,
      isTwoFactorAuthenticationEnabled: !!userWithoutPsw.isTwoFactorAuthenticationEnabled,
      isTwoFactorAuthenticated,
    };

    return {
      email: payload.email,
    };
  }

Then we create the controller route with the LocalAuthGuard



@UseGuards(LocalAuthGuard)
@Post('login')
@HttpCode(200)
async login(@Request() req) {
  const userWithoutPsw: Partial<User> = req.user;

  return this.authenticationService.login(userWithoutPsw);
}

Ok, so now, if we send a post request on the /authentication/login route with correct credentials, it will return the user's email. Let's add the Jwt management now.

First we add the nestJs Jwt package.

yarn add @nestjs/jwt

Then we have to register the JwtModule in the Authentication module in order to be able to use it. The secret should, of course, be secret and in an .env file.



JwtModule.register({
    secret: 'secret',
    signOptions: { expiresIn: '1d' },
  })

Then we just have to add the JwtService to the AuthenticationService and use it to generate the access_token we'll return to the front-end.
Here's what the authentication service should look like now.



import { Injectable } from '@nestjs/common';
import { UsersService } from "../users/users.service";
import { User } from "../users/user.entity";
import { JwtService } from "@nestjs/jwt";

@Injectable()
export class AuthenticationService {
  constructor(private usersService: UsersService, private jwtService: JwtService) {
  }

  async validateUser(email: string, pass: string): Promise<Partial<User>> {
    const user = await this.usersService.findOne(email);
    try {
      // Of course, we should consider encrypting the password
      const isMatch = pass === user.password;
      if (user && isMatch) {
        // eslint-disable-next-line @typescript-eslint/no-unused-vars
        const { password: _, ...userWithoutPassword } = user;
        return userWithoutPassword;
      }
    } catch (e) {
      return null;
    }
  }

  async login(userWithoutPsw: Partial<User>) {
    const payload = {
      email: userWithoutPsw.email,
    };

    return {
      email: payload.email,
      access_token: this.jwtService.sign(payload),
    };
  }
}

Now the frontend has a Jwt token it'll be able to use to authenticate requests to the backend. But how will the backend manage the Authorization token ?
Well, let's create a JwtAuthGuard using passportjs jwt package.

yarn add passport-jwt

We can now create the jwt strategy which is based on passportjs.

jwt.strategy.ts



import { ExtractJwt, Strategy } from 'passport-jwt';
import { PassportStrategy } from '@nestjs/passport';
import { Injectable } from '@nestjs/common';
import { UsersService } from '../../users/users.service';
import { TokenPayload } from '../token-payload.entity';

@Injectable()
export class JwtStrategy extends PassportStrategy(Strategy) {
  constructor(private readonly userService: UsersService) {
    super({
      jwtFromRequest: ExtractJwt.fromAuthHeaderAsBearerToken(),
      secretOrKey: 'secret',
    });
  }

  async validate(payload: TokenPayload) {
    const user = await this.userService.findOne(payload.email);

    if (user) {
      return user;
    }
  }
}

And create the JwtAuthGuard.

jwt-auth.guard.ts



import { Injectable } from '@nestjs/common';
import { AuthGuard } from '@nestjs/passport';

@Injectable()
export class JwtAuthGuard extends AuthGuard('jwt') {}

So for now, we have a complete basic authentication using JWT to authenticate requests. But as we said before, it is based on a user/password login and therefore it is not very secure. So let's add the two factor authentication.

Two factor authentication

Here's the login flow for 2fa authentication:

The user logs in with his email and password
If the 2fa is not enabled, he can enable it using the turn-on route. This will generate a QrCode that the user will scan with the google authenticator app.
The use then uses the random code the app has generated to authenticate

Creating the 2fa system

First we have to create a unique secret for every user that turns on 2fa, but we'll also need a special otp authentication url that we'll be using later to create a QrCode. The otplib package is a good match, so let's install it.

yarn add otplib

We should also update the user interface and add the twoFactorAuthenticationSecret property.



export interface User {
  userId: number;
  email: string;
  username: string;
  password: string;
  twoFactorAuthenticationSecret: string;
}

Then we create a method to generate the secret and otpAuthUrl in the authentication service and return both of them. The AUTH_APP_NAME is the name that will appear in the google authenticator app.



async generateTwoFactorAuthenticationSecret(user: User) {
    const secret = authenticator.generateSecret();

    const otpauthUrl = authenticator.keyuri(user.email, 'AUTH_APP_NAME', secret);

    await this.usersService.setTwoFactorAuthenticationSecret(secret, user.userId);

    return {
      secret,
      otpauthUrl
    }
  }

We have to update the user with the secret that has just been generated. Once again, this should all be in a database.



  async setTwoFactorAuthenticationSecret(secret: string, userId: number) {
    this.users.find(user => user.userId === userId).twoFactorAuthenticationSecret = secret;
  }

Now, we can generate the QrCode that will be used to add our application to the google authenticator app.

yarn add qrcode

Let's add the generate method in the authentication service.



  import { toDataURL } from 'qrcode';

  async generateQrCodeDataURL(otpAuthUrl: string) {
    return toDataURL(otpAuthUrl);
  }

Now we need to offer the possiblity for the user to turn on the 2fa. So let's add another property to the user interface.



export interface User {
  userId: number;
  email: string;
  username: string;
  password: string;
  twoFactorAuthenticationSecret: string;
  isTwoFactorAuthenticationEnabled: boolean;
}

Add the turnOn method in the users service



  async turnOnTwoFactorAuthentication(userId: number) {
    this.users.find(user => user.userId === userId).isTwoFactorAuthenticationEnabled = true;
  }

Add the method that will verify the authentication code with the user's secret



isTwoFactorAuthenticationCodeValid(twoFactorAuthenticationCode: string, user: User) {
    return authenticator.verify({
      token: twoFactorAuthenticationCode,
      secret: user.twoFactorAuthenticationSecret,
    });
  }

Add the turn on route in the authentication controller



 @Post('2fa/turn-on')
  @UseGuards(JwtAuthGuard)
  async turnOnTwoFactorAuthentication(@Req() request, @Body() body) {
    const isCodeValid =
      this.authenticationService.isTwoFactorAuthenticationCodeValid(
        body.twoFactorAuthenticationCode,
        request.user,
      );
    if (!isCodeValid) {
      throw new UnauthorizedException('Wrong authentication code');
    }
    await this.usersService.turnOnTwoFactorAuthentication(request.user.id);
  }

Logging in with 2fa

Let's add a login with 2fa method in the authentication service. The difference with the default login function is that we add the 2fa status in the payload.



  async loginWith2fa(userWithoutPsw: Partial<User>) {
    const payload = {
      email: userWithoutPsw.email,
      isTwoFactorAuthenticationEnabled: !!userWithoutPsw.isTwoFactorAuthenticationEnabled,
      isTwoFactorAuthenticated: true,
    };

    return {
      email: payload.email,
      access_token: this.jwtService.sign(payload),
    };
  }

We can now create the 2fa authentication route in the controller. If the code sent in the post body is valid, then we try to login with 2fa else we throw an error.



@Post('2fa/authenticate')
  @HttpCode(200)
  @UseGuards(JwtAuthGuard)
  async authenticate(@Request() request, @Body() body) {
    const isCodeValid = this.authenticationService.isTwoFactorAuthenticationCodeValid(
      body.twoFactorAuthenticationCode,
      request.user,
    );

    if (!isCodeValid) {
      throw new UnauthorizedException('Wrong authentication code');
    }

    return this.authenticationService.loginWith2fa(request.user);
  }

It is now possible to create an AuthGuard strategy based on Jwt and the 2fa status. If the 2fa is not turned on then we can rely on the jwt only, if the 2fa is enabled then we check if the user is 2fa authenticated.

jwt-2fa.strategy.ts



import { ExtractJwt, Strategy } from 'passport-jwt';
import { PassportStrategy } from '@nestjs/passport';
import { Injectable } from '@nestjs/common';
import { UsersService } from '../../users/users.service';

@Injectable()
export class Jwt2faStrategy extends PassportStrategy(Strategy, 'jwt-2fa') {
  constructor(private readonly userService: UsersService) {
    super({
      jwtFromRequest: ExtractJwt.fromAuthHeaderAsBearerToken(),
      secretOrKey: 'secret',
    });
  }

  async validate(payload: any) {
    const user = await this.userService.findOne(payload.email);

    if (!user.isTwoFactorAuthenticationEnabled) {
      return user;
    }
    if (payload.isTwoFactorAuthenticated) {
      return user;
    }
  }
}

jwt-2fa-auth.guard.ts



import { Injectable } from '@nestjs/common';
import { AuthGuard } from '@nestjs/passport';

@Injectable()
export class Jwt2faAuthGuard extends AuthGuard('jwt-2fa') {}

Let's see how this goes right now.

Testing

So first we'll do a POST request to log in with the user and password:

This will return the following:

Then, we need to get the QrCode to add our app to the google authenticator app

This will return a base64 data url which in turn will happen to be a QrCode

If you scan this with the Google Authenticator App it should add your app:

And then you should be able to call the authenticate route with the current code from the google authenticator app

My take on clean code

Matthew — Wed, 30 Dec 2020 14:06:40 +0000

I recently encountered a PHP project that made me want to write about clean code.
SitRep: One of our clients has a website that needs some bug fixing and some features to be added. Once I had cloned the GitHub repo, I took a look at how the code was written and my reaction was:

Ok, slight exaggeration here 😅, but you get me.

So here are my thoughts about how useful it is to write clean code

What is clean code anyway ?

I guess thousands of lines could be written about this topic, but in a nutshell, I'd say clean code is code that is going to be easy to maintain. Easy to maintain not only by yourself in one week, but probably other people months later when you're no longer here to explain it.

Ok now let's get on with it then.

Readability

To me, this is probably the most important in writing clean code.
The code you write MUST be readable by another human being without generating this kind of reaction:

Naming variables and functions

a, b, c, test, thing, ... are not good variable names, that's pretty obvious, but I still occasionally see them around 😅. I recently started to look into Golang and it seems quite frequent to see badly named variables there 🤔.

// Don't
function calcTwt(a, b, c) {
  return a * b * c;
}

// Do
function caculateTotalWithTaxes(quantity, unitPrice, taxes) {
  return quantity * unitPrice * taxes;
}

Of course, no need to overdo it, keep names short but understandable.

Also, there are many standards about naming variables already out there. For example, boolean will often be written isOpened, areOpened, hasRead.

Here's a pretty good article about naming stuff: https://hackernoon.com/the-art-of-naming-variables-52f44de00aad

Keep your functions simple

Your functions should only do what they say they do. For example, if you call your function getUser and pass an id param to it which would be getUser(id), it should only fetch and return the user which has this id, and that's ALL.

Also, if your function is too long and does many different actions, it's probably a sign that you should split it into multiple smaller functions.

Formatting

Here are a few tips about formatting your code:

Keep your files from being too long
Limit the length of lines
Last but not least, comply by the rules set by your team

Coding principles

DRY

Don't Repeat Yourself.

That's pretty straight forward ain't it. It states that every piece of code you write should only have one clear representation in your project's codebase.
In other words, you shouldn't write the same piece of code twice. If you are, then your code is going to be more difficult to maintain.

Here's a simple example, you have a list of users and want to display the concatenation of the firstName and lastName.

const users = [
  {
    id: 1,
    firstName: 'Luke',
    lastName: 'Cage',
  },
  {
    id: 2,
    firstName: 'Jessica',
    lastName: 'Jones'
  }, 
  {
    id: 3,
    firstName: 'The incredible',
    lastName: 'Hulk',
  }
]

// Don't

console.log(`${users[0].firstName} ${users[0].lastName}`);
console.log(`${users[1].firstName} ${users[1].lastName}`);
console.log(`${users[2].firstName} ${users[2].lastName}`);

// Do
function displayUserName(user) {
  console.log(`${user.firstName} ${user.lastName}`);
}

users.forEach(displayUserName);

KISS

Keep It Simple Stupid is a design principle noted by the U.S. Navy in 1960 meaning you should avoid unnecessary complexity as much as possible. If things are kept simple, they are easier to understand and therefore easier to maintain.

https://en.wikipedia.org/wiki/KISS_principle

Here's a silly example, but it should make it clear to you.

// Don't
function dayOfWeek(dayNumber) {
  switch(dayNumber) {
    case 1:
      return 'Monday';
      break;
    case 2:
      return 'Thuesday';
      break;
    case 3:
      return 'Wednesday';
      break;
    case 4:
      return 'Thursday';
      break;
    case 5:
      return 'Friday';
      break;
    case 6:
      return 'Saturday';
      break;
    case 7:
      return 'Sunday';
      break;
    default: 
      return null;
  }
}

// Do
function dayOfWeek(dayNumber) {
  if (dayNumber < 1 || dayNumber > 7) return null;

  const weekdays = [
   'monday',
   'thuesday',
   'wednesday',
   'thursday',
   'friday',
   'saturday',
   'sunday',
  ];

  return weekdays[dayNumber - 1];
}

YAGNI

You Aren't Gonna Need It.

One thing I learnt in my beginner years was not to write functions before you need them. Otherwise, you're probably going to create dead code.

For example if you're writing a user class, don't assume you might later need a method to concatenate the first name and the last name, only write it when you need it.

One way of achieving this principle is to write the code as you're going.

Imagine you want to display a list of users in an MVC language like angular, then you should theoretically write things in this order:

The view --> needs a users variable from the controller
The controller --> needs a getUsers function from the service
The service --> needs a fetch function from the httpService
HttpService --> And so on ...

Writing your code in this order should prevent you from creating functions you won't be using.

Please keep in mind that this is my way of avoiding to write dead code, you could also go "bottom up", start with the services and end up with the view.

Conclusion

I voluntarily kept this pretty short, I could, of course, go into details for all of those topics but the idea was to give a hint to beginners on how to keep their code clean.
You should always bear in mind that all teams have their standards of writing code.

Using NgRx with Angular

Matthew — Sat, 18 Jul 2020 19:03:32 +0000

As I just moved from the country I've lived in for my whole life, France 🇫🇷, to Canada 🇨🇦, I had to start a new job 🥳. I'm back to being a Software Developer, and that definitely feels great. I have learnt quite a few things in a few weeks, thanks to the incredible team working at Kumojin.

In this article I wanted to share what I learnt while working on an Angular project using NgRx. I was really new to NgRx although having been working with angular for a few years and what a discovery ! 🚀

What is NgRx 🤷🏼‍♂️ ?

NgRx is a framework for building reactive applications in Angular. https://ngrx.io/docs

😲

A reactive application is an application that depends on data streams and propagation of change.

Eg.:
You want to build a component which needs to fetch a list of products to display it. If a product is added later to this list by some other component, you won't need to add anymore logic to the first component in order to manage the change in the state.

So, should I use it then ?

Well, as most things in tech, there are cases where it is not really suited, and some where it's the best bet.

I wouldn't recommend using NgRx if the app you are building doesn't have many user interactions, isn't too complex. In this case you probably won't need it.

In a simple application I would clearly recommended to store the states in the services and call the services from the components.

However, if a state is accessed by multiple components, is updated with external data, needs to be used when re-entering a route or if the state gets modified by the actions of other sources then it is a hell of a good deal. It also brings quite a bit of structure to the project.

In other terms, it is important to understand that using NgRx will add quite a bit of complexity to the project's structure, so the choice has to be thought through.
Also, it is not that easy to understand when you are not used to managing states this way. I found it a bit disconcerting at first, but after a few days, I really got the hang of it.

Ok, then how does it work ?

Here's a quick diagram I got from GitHub that I found pretty clear (once it was explained to me 😂). I recommend you go back to this diagram at each section of this article, it should become clearer.

Actions

Actions are unique events which can happen in you app. They have a type and can eventually carry properties to add some context.

Eg:
I need my component to fetch products as earlier. Instead of directly calling the products service and wait for the result, the component will dispatch an action

Without NgRx:

products.component.ts

constructor(private productService: ProductService) {
  this.productService.getAll()
    .subscribe((products) => {
       this.products = products;
    });
}

With NgRx:

products.action.ts

Enumerate the actions, it's cleaner when you need them elsewhere.

export enum ProductActionTypes {
  FETCH_PRODUCTS = '[Products] Fetch products',
}

Implement the action (Add a type, and eventually some context)

export class FetchProducts implements Action {
  readonly type = ProductActionTypes.FETCH_PRODUCTS;
}

Export the actions type, it'll be useful later on

export type ProductsActions =
  | FetchProducts

products.component.ts

constructor(private readonly store: Store) {
  this.store.dispatch(new FetchProducts());
}

Ok then, we have started to isolate the component from the service by dispatching an action, what happens next ? Well, actions are processed by reducers and effects.

Reducers

Reducers manage the state transitions by listening to the actions which are dispatched.
If you think about the example you'll see there are in fact 3 different states:

State 1: The products are being fetched
State 2: The products have been fetched with success
State 3: The products fetching failed

In fact there even is a State 0, when the state is initialized and nothing has happened yet.

We will create as many actions as they are different states in the reducer as the reducer states depend on the actions

products.actions.ts

export enum ProductActionTypes {
  FETCH_PRODUCTS = '[Products] Fetch products',
  FETCH_PRODUCTS_SUCCESS = '[Products] Fetch products success',
  FETCH_PRODUCTS_FAIL = '[Products] Fetch products fail',
}

export class FetchProducts implements Action {
  readonly type = ProductActionTypes.FETCH_PRODUCTS;
}

export class FetchProductsSuccess implements Action {
  readonly type = ProductActionTypes.FETCH_PRODUCTS_SUCCESS;

  constructor(public products: Product[]) { }
}

export class FetchProductsFail implements Action {
  readonly type = ProductActionTypes.FETCH_PRODUCTS_FAIL;

  constructor(public payload: ErrorData) { }
}

export type ProductsActions =
  | FetchProducts
  | FetchProductsSuccess
  | FetchProductsFail;

products.reducer.ts

First, let's declare the state properties and the initial state (State 0 😉)

export interface ProductsState {
  loading: boolean;
  products: Product[];
}

export const productsInitialState: ProductsState = {
  loading: false,
  products: null,
};

Then let's listen for actions and manage the state accordingly

export function productsReducer(
  state = productsInitialState,
  action: ProductActions
): ProductsState {
  switch (action.type) {
    case ProductActionTypes.FETCH_PRODUCTS: {
      return {
        ...state,
        loading: true,
      };
    }

    case ProductActionTypes.FETCH_PRODUCTS_SUCCESS: {
      return {
        ...state,
        products: action.products,
        loading: false,
        loaded: true,
      };
    }

    case ProductActionTypes.FETCH_PRODUCTS_FAIL: {
      return {
        ...state,
        loading: false,
        loaded: false,
      };
    }

    default: {
      return state;
    }
  }
}

Effects

Once actions have been dispatched and states have been initialized, we need to take care of the side effects.

Effects are what's going to help you isolate services from components by listening to the dispatched actions. They can also trigger new events by dispatching new actions.

Let's explain it with an example. I want my products service to be called when the "Fetch products" action is dispatched, but I also want it to dispatch a new action once it has succeeded or failed don't I ?

products.effects.ts

First let's inject the services I need. Here, Actions is a stream which contains all the dispatched actions.

constructor(
    private actions$: Actions,
    private readonly productsService: ProductsService,
    private readonly errorService: ErrorService,
  ) { }

Then let's create our first effect:

@Effect()
public fetchProducts$ = this.actions$.pipe(
    ofType<FetchProducts>(ProductActionTypes.FETCH_PRODUCTS),
    switchMap(() => this.productsService.fetchProducts().pipe(
      map((products: Product[]) => new FetchProductsSuccess(products)),
      catchError((error: ErrorData) => of(new FetchProductsFail(error)))),
    ),
  );

What this effect is saying is:

Listen to all dispatched action for an action with the "FetchProduct" type
If an action of this type is dispatched, then call the products service to fetch products.
If the service call is a success then dispatch a FetchProductsSuccess action (passing it the result of the service call)
If the service call fails, then dispatch a FetchProductsFail action.

The action dispatched on success doesn't need an effect as it's only there to change the products state, remember ?

case '[Products] Fetch products success': {
      return {
        ...state,
        products: action.products,
        loading: false,
      };
    }

So, I dispatch a FetchProductsSuccess action, feed it the data I just got from the service, and guess who's waiting for it: the reducer.

Finally, in this case, I created an effect to display an error message if the service fails to fetch the products. By default, an effect will always dispatch a new action, but you can override this by adding { dispatch: false }. My effect will therefore call the service and then nothing more happens.

@Effect({ dispatch: false })
public fetchProductsFail$ = this.actions$.pipe(
    ofType<FetchProductsFail>(ProductActionTypes.FETCH_PRODUCTS_FAIL),
    map((action: FetchProductsFail) => action.payload),
    tap((error: ErrorData) => this.errorService.displayError(error)),
  );

This brings us to the last step "Selectors". If you remember, in our component, we dispatched the action this.store.dispatch(new FetchProducts());. That's the way to go, but, nobody in this component is watching for the state changes, so nothing visible should happen.

Selectors

Selectors are function that will help you get the "pieces" of your states you need.

In my example, I need to get the products and the loading state of my products state.

products.selector.ts

export const getProductsState = createFeatureSelector<ProductsState>('products');

export const getLoading = createSelector(
  getProductsState,
  (state: ProductsState) => state.loading
);

export const getProducts = createSelector(
  getProductsState,
  (state: ProductsState) => state.products
);

To use a selector, you have to call the store like follows:

products.component.ts

public products$: Observable<Product[]> = this.store.pipe(
    select(getProducts),
  );

public loading$: Observable<boolean> = this.store.pipe(
    select(getLoading)
  );

Using the async pattern in the Html file prevents from having to clean up the observables in the component's onDestroy method. The cleaning is done automatically when leaving the component.

product.component.html

<p *ngIf="loading$ | async"> Loading </p>
<ul *ngIf="products$ | async as products">
  <li *ngFor="let product of products">{{ product.name }}</li>
</ul>

Declaring the store in the App module

Note the StoreDevtoolsModule which is very useful when debugging a NgRx application 👌.

[...]
import { reducers } from './core/store/reducers';
import { effects } from './core/store/effects';

  imports: [
    [...],
    StoreModule.forRoot(reducers, { runtimeChecks: { strictStateImmutability: true, strictActionImmutability: true } }),
    EffectsModule.forRoot(effects),
    StoreDevtoolsModule.instrument(),
  ]

Conclusion

This is the end of this small introduction to NgRx. You obviously can do much more stuff with it, like manage your app router, use entities to manage state collections and plenty of other magical things.
As you can see, for just a simple webapp, it might be just too complex to setup. In the example above, I only did the work for one state, one component and a few actions.
The magic really starts operating when your app becomes complex, things are always at the place you expect them to be, your components are isolated from the services and using the devtools, you can easily debug and see the action/data flow of your app.
Just below are some links including the GitHub project for the example above.
I hope you appreciated my first tech article, I'll be happy to discuss it over even if you disagree 😇.

Links

Live example: https://5f1246c2a5e2da029b87fe44--hungry-bhabha-4ea98a.netlify.app/
GitHub: https://github.com/MatthieuHahn/ngrx
NgRx full documentation: https://ngrx.io/

Credits

I'd really like to thank Julien and Lukasz from the Kumojin team who waited patiently for me to be able to move to Canada for more than 8 months.

Kudos to Faustine and Pierre who took the time to explain NgRx to me.

Being a CTO is great, but ...

Matthew — Sun, 04 Aug 2019 13:12:34 +0000

Earlier this week I wrote my first blog post, and, to be honest, I was so surprised to see how many people reacted to it here and on Twitter. I've no idea if the numbers are good or not and I don't really care.
I just want to thank you all for reading and leaving replies which I'm sure will help me write my next blog posts.

In my last post I explained how I became CTO, but I didn't go through what I love with this job and what makes me think I maybe should have waited or tried something else before.

Being a CTO

First of all, I want you to know that what I'm sharing here is my experience of the job and it's probably not what another CTO would think or tell you. What I think is cool or uncool about this job is my perception but, hey, isn't it the aim of all this ?

The company that I work for only has a few developers and half of them are outsourced. This was already the case when I arrived two years ago. So, I'm not the CTO of the next Uber, Twitter or whatever, and that's fine by me.

The good parts of the job

Being a CTO is awesome in many aspects:

I love building things, and, being a CTO means you're taking decisions with the CEO to build the company the way you want it to go and it's soooo interesting !
I get to choose what tools we'll be using for the next few years. Of course, I don't choose on my own, but I have a big responsibility in the choice. What I like the most about that, is building the Proofs Of Concept and getting to explain the pros and cons of a solution.
I work with a small team of developers that all have their ideas on what we should do next, why we are doing things wrong, how they would do them better and being in the center of this is overwhelming in a good way.
I'm in charge of recruiting the team that will build our products. I'll put this item in both cool and uncool lists and explain why it's also uncool to me. Recruiting is fun ! You get to meet people that come from different backgrounds. When I'm recruiting a Junior dev who has just finished her/his course, I often speak about what I'm learning right now and see what they understand about the subject (and I don't expect them to know anything about it). I'll always give them hints on books I have read or websites I have visited and that helped me a lot. When I'm recruiting a more experienced dev, I often do the opposite and ask what they learned last and try to understand the stuff myself.

The downfalls

Well, not everything is perfect (For myself of course) :-P

For some of the next few items, I have to say, my CEO is a control freak. She needs to have a grasp on every single feature even though she doesn't always get the idea.

Recruiting: Of course, you can't recruit everyone, so you have to say no to great people and I hate that. On a totally different aspect, it also consumes a lot of my time. The other hard part is having to battle with my CEO on why someone who hasn't got a freaking computer science degree should be hired rather than someone who has. God! It's hard !
Working with an outsourced team (considering my CEO): You got the idea. Just imagine a feature that was estimated to 10 days of work and finally takes 12 or 13 maybe. Then I need to explain once again, that writing code isn't an exact science. It's like making a cake. Ask me to follow the recipe that should take 15 minutes, I'll take me at least an hour. Ask my wife ? She'll have it finished in 10 minutes. Even though I know how to cook, my wife is much better at it than I am, it's a fact. In my opinion, coding is pretty much the same.
Planning: I hate planning for other people ! I already hate doing it for myself. That's one of the main reason I thought I wasn't made for project management. I love mentoring, I love explaining what I've built, but I freaking hate planning.
Well, I don't write as much code as I'd like too. This is one of the hardest aspects. I really love building stuff and I only get little time to do it. Most of the time I think: "Oh I'd love to build this feature!" and then "Man, I don't have time for this, let's hand it out to our outsourced team". So all I get to do is write on how I think the feature should be built.

What if ?

What If had to start my career all over again today ?

Honestly, I don't think I'd go for the CTO stuff. Don't get me wrong, put aside the hard relation with my CEO, I like it a lot. But I, by far, prefer building stuff, and I really don't do enough of it today.

I've done a little freelancing this year and that's something I find awesome. You can change stacks all the time, you're forced (in the good way) to stay up to date with tech and you're pretty much free to choose your "boss".

When I speak to young developers who have just finished school, the question I often ask them: "Why don't you try freelancing ?".

The answer is pretty much the one I would have given too: "I don't feel legitimate enough".

So, I think, we, as a community, should help those young developers to feel more legitimate.

Any idea on how we could do that ? Feel free to respond to this post, I'd be glad to discuss it with you all.

How I became CTO in just a few years

Matthew — Fri, 02 Aug 2019 07:36:00 +0000

I'm not sure how to start about this, so let's go with the beginning.

I've been in the webdev industry for just a few years and am the CTO of a small french e-health company that provides programs for people who suffer from weight, insomnia or stress issues. And that feels great, believe me !

So you might be asking yourself where I'm going with this ...

At the very beginning

The thing is, this wasn't quite the career I was aiming at when I started college and then graduated. I did start with a computer science two year course where I learnt the basis of algorithms and how to code in C, C++ and other cool stuff like that, but the teachers, at the time, kept telling us that being a developper was like being a the bottom of the food chain.

Clearly, according to them, the trend was to be on the functional side of tech. So I went on with a masters degree to become project manager. Therefore, I started my career by writing functional specifications (Gasp).

The turning point

I was working for this big power company writing specs on data exchange between the different apps and noticed we had no way to know where the data really was. So I developed a small Java JSX app that enabled us to track the data, it worked so well, they put it into production, I was thrilled !

I thought, what the hell am I doing writing functional specs and wanting to be project manager, I hate all of that! At this point, I was regretting all I had done until then, thinking that I would never be fully happy with my career, ever.

This company then started to replace their awful palm devices by iPads and were looking for developers to build the new apps. So they hired this guy to start working on the stuff and I dared to ask if I could have a try on working with him, and if he would mentor me. This is the best decision I have ever made in my whole career!

They accepted ! They gave me the chance I needed. Up to me to make it worth it.

I worked 2 years there was great to learn, but the thing with big companies is that you never really get to see the whole picture. You just work on a part of a project. So I left, to work as a Lead Fullstack developer in a Startup for 1 year and then had the opportunity to become CTO of another small company.

I decided to give it a try, even though I didn't really feel legitimate for the job. I felt like I was missing so much knowledge and that I would never manage to take the right decisions fast enough.

To the point now

A few points I'd like tech recruiters to not forget:

Studies are a good thing, but they don't make you a good developer, passion and practicing does.
Junior developers can be really good if you just give them a chance, we all were Junior first
It really is possible to learn how to code in just as few weeks (this one is for my CEO who thinks it's better not to hire people who don't have a computing background)

This is the first blog post I've ever written, and it feels right. I didn't want to start with some technical stuff. I really wanted to thank some people I follow on twitter for making me feel legitimate to write here.

So thank you

[Deleted User]

Ali SpittelFollow

Passionate about education, Python, JavaScript, and code art.

Ben HalpernFollow

A Canadian software developer who thinks he’s funny.

and all the others for making this happen.