Forem: cbb-it-minds

Monorepos with Nx

cbb-it-minds — Fri, 28 Aug 2020 07:35:53 +0000

If you are building a serious app, you most likely have multiple projects you are managing in different repositories and on different team members. Projects such as multiple frontends that communicate with each other backends, shared common businesslogic or even components.

The benefit of splitting your codebase into independent versioned packages is extremely useful for sharing your code.

However, managing changes across multiple repositories can quickly become yucky. Monorepos tries to solve this problem among many others while maintaining organisation wide practices.

In this article we take a look Nx and the nice tooling for creating and managing monorepos.

Using Nx CLI to create our foundation

Our product manager told us to create an application where Users can look at different fruit. He also wants an admin panel where he and other admins can manage what fruit to be in the shop.

We create our workspace by running the command:

npx create-nx-workspace@latest

We are given some options including the name of our workspace followed by some default setups. You can go ahead and choose whatever you like. In the example we create an empty workspace. The workspace should look a lot like this:

apps ( where our apps go )
libs ( shared libraries: ui, interfaces etc.)
tool ( scripts that act on your codebase: db, custom build etc.)

Give a week of meetings with our product owner and the team. We decide our server should be a Nest.js with a client-app in React and an admin-panel in React.

apps

fruit-shop
fruid-panel
fruit-server

libs

ui
models

tool

We can use the CLI to generate these libraries and apps for us:

nx generate @nrwl/react:app fruit-shop
nx generate @nrwl/react:app fruit-panel
nx generate @nrwl/nest:application fruit-server

Okay, so that's cool but we could do this in a regular "single repo, many projects" kinda workspace as well. Where Nx really is different is its tooling.

Tooling

We notice a lot of code duplication in our client-app and admin-panel to improve our codebase and serve the purpose of DRY. We create a component library:

nx generate @nrwl/react:library ui

But how do we keep track wether or not the library actually affect changes in our app? Nx dep-graph is a tool which detects apps/libraries are affected by the change you just made.

Our newly created fruity-button-component is implemented in both the client-app and the admin-panel. With a few modifications we make a more generic component in the ui-library.

We use the new button in both apps and if we make modifications to the button both apps are affected:

Here we can see the dependency graph for our apps. Pretty sweet. But what's even more better is, Nx can see affected apps within your changes.

Affected Graph

Our apps + the server has a dependency to the Users-model in the models-library. Let's change the interface a bit and see which apps are affected by the change:

running: nx affected:dep-graph

As we can see all of our projects are affected by this change. There are all sorts of filters that lets you focus on a specific app or exclude apps. Also, it lets you group dependencies by folders.

Many may say that they don't want to develop in a monorepo because they need to build and run test on apps they didn't even affect. With Nx, that's a different story. Nx benefits from knowing which apps are affected by change and therefore knows what kind of test, e2e and builds it needs to run.

Extensions

For now, we have used the Nx CLI to generate our apps and libraries. But Nx offers a vscode-extension, which can help run commands in a GUI, so you don't have to remember the commands or the documentation.

Last comments

There's a lot of benefits running a serious application with a tool like Nx. The dep-graph and code/boilerplate generation through the Nx CLI makes it easier to work and collaborate on larger codebases.

I would even consider using this in a smaller app, due to the great tooling behind Nx.

How to architecture your JavaScript API using NestJS with a GraphQL API example part 2/2.

cbb-it-minds — Fri, 01 Nov 2019 06:09:07 +0000

This is a follow up article to the previous introduction to NestJS (read the prior article here). After the introduction and setup, we are now ready to start building our resolvers for our API.

Build APIs in NestJS

When we are building APIs in NestJS, we primarily work in 3 different types of files. The files .service, .resolvers and .types.graphql. all have their own responsibilities:

The Types

The types is where we define the Queries, Mutations InputTypes and other GraphQL specifications which we want in our Schema. Our setup in the previous article (take a look in app.module.ts) join all our .graphql-files in one Schema.

The Service

If we think of a service in Angular, we primarily use these to prevent the component itself against performing requests to resources. Hence we use the power of dependency injection to inject these services to the component and call the service when need be for resources.

Same goes for the service in NestJS! Due to this separation we can easily test the functionality of services and its "users", so to speak. We use these services to acquire resources. Usually I use the service for business specific logic as well. Say you want to make some recommendation logic for our products.

The Resolvers

Resolvers are just resolvers as we know them. Here we define the logic for our Queries and Mutations. Usually I keep these as clean as possible and force logic into the services. Typically this results in delegation of the arguments from the Mutation and Query to a service.

With these type of files in mind, I think it is time for us to start creating the API.

Product Types to our Schema

We start by creating our Product-type and a corresponding inputType. We want to be able to create a Product and hereafter find it again by its ID. Hence we create a Query and a Mutation as well:


"""
products.types.graphql
"""

type Query {
  productGetById(id: ID!) Product
}

type Mutation {
  productCreate(createProductInput: CreateProductInput!): Product!
}

type Product {
  id: ID!
  title: String!
  brand: String!
  currentPrice: Float!
}

input CreateProductInput {
  title: String!
  brand: String!
  currentPrice: Float!
}

As we save the file you might find that the compiler generated a new graphql.ts-file. In this file you will see generated interfaces from the GraphQL types we just defined.

// graphql.ts

export interface Product {
    _id: string;
    title: string;
    brand: string;
    currentPrice: number;
}

export interface IQuery {
    getProductById(id: string): Product | Promise<Product>;
}

export interface IMutation {
    createProduct(createProductInput: CreateProductInput): Product | Promise<Product>;
}

export interface CreateProductInput {
    title: string;
    brand: string;
    currentPrice: number;
}

Now we can finally create our resolvers in our product.resolvers.ts-file. Looking in the file we notice it looks a lot like a service class from Angular. With the power of decorators and dependency injection we notice how the framework helps us being consistent with our resolvers.

@Resolver('Product')
export class ProductsResolvers {
  constructor(
    private readonly productsService: ProductsService,
  ) {}

  // specifying what mutation to use
  @Mutation('createProduct')
  async create(@Args('createProductInput') args: CreateProductInput) {
    return await this.productsService.createOne(args);
  }

  // naming convention to use this query
  @Query()
  async getProductById(id: string) {
    return await this.productsService.findById(id);
  }

}

All we need now is to implement the service and we are ready to test the resolvers. The products.service.ts-file is where we fetch the data from a database or other sources.

@Injectable()
export class ProductsService {
  constructor(private readonly productRepository: ProductRepository) {}

  async findOneById(id: string) {
    return await this.productRepository.findOne({ _id: id });
  }

  async createOne(product: Product) {
    return await this.productRepository.createOne(product);
  }
}

Now run the application and see that it's working ! You can use either the playground or Postman/Insomnia.

You are now ready to go HAM and implement your new NodeJs server in a new strict way!

How to architecture your JavaScript API using NestJS with a GraphQL API example part 1/2.

cbb-it-minds — Thu, 25 Jul 2019 14:13:52 +0000

A traditional NodeJS and Express backend is quite simple to certain extent. You have a RouteHandler and some functions which returns some data upon request. While Node servers are simple, we are often afraid to open an old project during either maintenance or updating these projects.

Node does not give a concrete guidance as to how we are to structure our APIs, hence we see a bunch of Express routes that does all kinds of operations like: data-access, validation, logging, etc. While this is not always the case we do see them once in a while.

As well as these 'interesting' interpretations of how backend APIs should be structured and if logic should be separated or not. We do see structured APIs where data-access and business-logic is separated into different modules in a MVC-like architecture.

As much as I like the degrees of freedom Node and Express provides us. I believe that the problem inherited from this freedom is the main reason as to why we are so terrified, when we open a Node application.

In this series of blog posts we will take a look at how NestJS provides us guidance as to how we can structure our Node Express (Fastify and more...) applications and APIs with a GraphQL API example. Hopefully as we dig deeper into NestJS you will experience the same epiphany as I did the more I worked with NestJS.

In this first part of this series, we will setup the project and talk about what NestJS CLI gives us out-of-the-box. We will take a look at how we set up a simple MongoDB and structure a Mongoose Schema and Model, it is more fun playing with a real database than some JSON-objects.

In the second part we will start creating a GraphQL API in a Schema first approach and how NestJS can help structuring the application using dependency injection and decorators. We will look at some of the quirks and some of the cool stuff that NestJS introduces.

What is NestJS?

NestJS provides an abstraction on top of Node and makes use of Express (at least pr. default). NestJS provides an out-of-the-box application architecture that reminds a lot about the way you would structure an Angular application. With stuff like Modules, Services, Interceptors and Guards we clearly see from where they've been inspired. This architecture allows for scalability, easily maintainable- and testable applications as in Angular. Separating your validation- , business-logic as well as your data-access into different modules and services, provides a concise and testable application and API. But enough of the talking, lets dig into it and get started.

Let's get started

First we download the NestJS CLI and create a new project:

$ npm i -g @nestjs/cli
$ nest new my-nest

NestJS uses the power of TypeScript. If you are writing an application with TypeScript you will probably already know why this a great thing to have out-of-the-box.

Looking inside src/main.ts we see a function which acts like the entrypoint for our application. Just like in Express. We create an app and listen on some port. To run your application use:

$ npm run start:dev

Test the API by going to localhost:3000 in your browser or use your favorit API testing tool.

Project Structure

If we open src we see three different types of files: controller, module and service. The controller is where we define different endpoints. In the file we see that we can annotate functions as Get, Post, Put etc. Since we are going to use GraphQL, this is not relevant. We will later be creating resolvers, which will act as a controller.

Service: is an injectable component we use for fetching data to our controller.

MongoDB and Mongoose

To get going with our own database we use MongoDB and Mongoose:

$ npm install --save mongoose
$ npm install --save-dev @types/mongoose

I like to put my database configuration in a database folder (src/database). Create a module which we can use to inject in our model-classes. As in a classic Mongo setup this will make each class that depend on the connection wait till until a promise is resolved.

// products.module.ts

import { Module } from '@nestjs/common';
import { databaseProviders } from './database.providers';

@Module({
  providers: [...databaseProviders],
  exports: [...databaseProviders],
})
export class DatabaseModule {}

Create the database providers. Here we can specify connection option as optional arguments, eg: {useNewUrlParser: true}.

// database.providers.ts

import * as mongoose from 'mongoose';
import { KEYS } from '@/config/config.constants';

export const DATABASE_CONNECTION = 'DATABASE_CONNECTION';

export const databaseProviders = [
  {
    provide: DATABASE_CONNECTION,
    useFactory: (): Promise<typeof mongoose> =>
      mongoose.connect(KEYS.mongodb_connection_uri, { useNewUrlParser: true }),
  },
];

Now we are almost ready to connect to our database, all we need now is to define some model we would like to save in our database.

Creating a ProductModel

In the database-folder create a new schemas-folder. Inside the Schemas folder create a products-folder and create two files: products.schema.ts & products.interface.ts. The interface file are as follows:

// products.interface.ts

import { Document } from 'mongoose';

export interface Product {
  title: string;
  brand: string;
  currentPrice: number;
}

export interface ProductDocument extends Document, Product {}

With a Schema as follows:

// products.schema.ts

import { ObjectId } from 'mongodb';
import { Model, Schema } from 'mongoose';
import { ProductDocument } from './products.interface';

export const ProductSchema = new Schema({
  _id: { type: ObjectId, auto: true },
  title: String,
  brand: String,
  currentPrice: Number,
});

export type ProductModel = Model<ProductDocument>;

That it for our ProductModel for now. We will now create a module which we can define our types, queries and mutations. But first we need to create a ProductProvider:

// products.providers.ts

import { Connection } from 'mongoose';
import { ProductSchema } from './products.schema';
import { DATABASE_CONNECTION } from '@/database/database.providers';

export const PRODUCT_MODEL = 'PRODUCT_MODEL';

export const productsProviders = [
  {
    provide: PRODUCT_MODEL,
    useFactory: (connection: Connection) =>
      connection.model('Product', ProductSchema),
    inject: [DATABASE_CONNECTION],
  },
];

ProductModule

Create a new module using the NestJS CLI:

$ nest g module products

Add the productsProviders and DatabaseModule:

// products.module.ts

import { Module } from '@nestjs/common';
import { DatabaseModule } from '@/database/database.module';
import { productsProviders } from '@/database/schemas/products/products.providers';

@Module({
  imports: [DatabaseModule],
  providers: [...productsProviders],
})
export class ProductsModule {}

Import ProductModule into ApplicationModule and add it to imports. Now we can finally start creating our API! So stay tuned for the second part of this series, where we finally can start coding :)
This will be out next friday!