Angular

Nx Workspace with Angular and Nest

Published Apr 7, 2021

Updated Feb 14, 2023

6 min read

This article was written over 18 months ago and may contain information that is out of date. Some content may be relevant but please refer to the relevant official documentation or available resources for the latest information.

Nx Workspace with Angular and Nest

In a previous article, we covered creating an Angular project with Nx monorepo tooling. This gives us a great base, but usually, our application will need a server-side project to feed our frontend application with all of the necessary data. Why not leverage the monorepo approach for this use-case then?

In this article, I would like to show you how to bring Nest server-side application that will serve our frontend application all the necessary data and behaviors. We will build on top of the existing Nx-based Angular application, which you can find in this GitHub repository. If you want to follow the code in this article, I recommend cloning this repository and checking out new branch with the nxAngularNest_entryPoint tag.

git clone git@github.com:ktrz/nx-photos.git
git clone https://github.com/ktrz/nx-photos.git (In case of using HTTPS)

cd nx-photos
git checkout -b nxAngularNestWorkingBranch nxAngularNest_entryPoint

The application in the aforementioned repository contains a simple application that displays a list of photos that can be either liked or disliked. If you run the code initially, you'll notice that the app requires a backend server from which to pull the necessary data. We will build this simple backend application using the Nest framework, and all of that within a single monorepo project, so that it is easier to manage both applications.

Nest Overview

Nest is a backend framework for building scalable Node applications. It is a great tool for Angular devs to get into server-side development as it is based on concepts that are very similar to Angular ones:

TypeScript support
Dependency Injection mechanism that is very similar to the Angular mechanism
Puts emphasis on testability
Configuration is similar (mostly based on decorators)
Best practices and conventions are similar - knowledge is transferable

All of this makes for a great candidate to use Nest as a server application framework for our application. Let's add a Nest application to our existing project.

Add Nest app

To start off, we need to install all of the dependencies which will allow Nx to assist us with building a Nest application. All of this is packed into a single Nx plugin @nrwl/nest.

yarn add -D @nrwl/nest

# or
# > npm install -D @nrwl/nest

With the tooling in place, we can generate the Nest application with one command.

# > nx g @nrwl/nest:application <nest-app-name>

Please keep in mind that, since we're keeping applications using 2 separate Nx plugins, we need to specify the full path to the schematics for generating applications/libraries. In this case, it is @nrwl/nest:application

A nice feature when creating a Nest application is the ability to set up a proxy to our newly created application so that our FE application can easily access it. We can use the --frontendProject additional param to do so. Let's use it to create our actual Nest application:

nx g @nrwl/nest:application api/photos --frontendProject fe-photos

This command will generate a project skeleton for us. The application is bootstrapped similarly to an Angular app. We define an AppModule, which will be a root of the app, and all the other necessary modules will be imported within this module.

// apps/api/photos/src/main.ts

import { Logger } from '@nestjs/common';
import { NestFactory } from '@nestjs/core';

import { AppModule } from './app/app.module';

async function bootstrap() {
  const app = await NestFactory.create(AppModule);
  const globalPrefix = 'api';
  app.setGlobalPrefix(globalPrefix);
  const port = process.env.PORT || 3333;
  await app.listen(port, () => {
    Logger.log('Listening at http://localhost:' + port + '/' + globalPrefix);
  });
}

bootstrap();

// apps/api/photos/src/app/app.module.ts

import { Module } from '@nestjs/common';

import { AppController } from './app.controller';
import { AppService } from './app.service';

@Module({
  imports: [],
  controllers: [AppController],
  providers: [AppService],
})
export class AppModule {}

For a more in-depth explanation of the Nest framework, please visit the official docs.

Building the API

For our photos application we require 3 following endpoints to be handled: GET /api/photos - which returns the list of all photos PUT /api/photos/:photoId/like - allows us to like a photo PUT /api/photos/:photoId/dislike - allows us to dislike a photo

To handle requests in Nest, we use a class called Controller which can handle requests to a specific sub-path (in this case it will be the photos sub-path). To keep our application clean, let's create a separate module that will contain our controller and all the necessary logic.

nx g @nrwl/nest:module app/photos --project=api-photos nx g @nrwl/nest:controller app/photos --project=api-photos --export

Since the controller shouldn’t contain business logic, we will also create a service to handle the logic for storing and manipulating our photo collection.

nx g @nrwl/nest:service app/photos --project=api-photos

Our newly created service will be added to our PhotosModule providers.

// apps/api/photos/src/app/photos/photos.module.ts

@Module({
  controllers: [PhotosController],
  providers: [PhotosService]
})
export class PhotosModule {}

Just like in Angular, we also need to include our PhotosModule in the AppModule's imports to notify Nest of our module's existence.

// apps/api/photos/src/app/app.module.ts

@Module({
  imports: [PhotosModule],
  controllers: [AppController],
  providers: [AppService],
})
export class AppModule {}

Now, we are ready to build the API we need. We can start with the first endpoint for getting all the photos: GET /api/photos

Let's start by creating all the necessary logic within the PhotosService class. We need to store our collection of photos and be able to return them in a form of an Array. To store it, I prefer to use an id-based map for quick access.

// apps/api/photos/src/app/photos/photos.service.ts

const stateToArray = (state: PhotoState): Photo[] =>
  Object.keys(state).map((key) => state[key]);

@Injectable()
export class PhotosService {
  state: PhotoState = {
    ['11ecb817-d6fc-49a9-8b53-229fc064da97']: {
      id: '11ecb817-d6fc-49a9-8b53-229fc064da97',
      title: 'Nest',
      url: 'https://docs.nestjs.com/assets/logo-small.svg',
      likes: 0,
      dislikes: 0,
    },
    /* more initial data entries */
  };

  getPhotos(): Photo[] {
    return stateToArray(this.state);
  }
}

To simplify transformation from a map to an array, I added a utility function stateToArray. It can definitely be extracted to a separate file/directory as an application grows, but for now, let's leave it here inline.

Now, our controller can leverage this getPhotos function to return a list of all photos via an API. To create an endpoint in Nest, we use decorators corresponding to an HTTP method that we want to expose. In our case, it will be a GET method so we can use a @Get() decorator:

// apps/api/photos/src/app/photos/photos.controller.ts

// this prefix will be used for all routes in this controller
@Controller('photos')
export class PhotosController {

  constructor(private photoService: PhotosService) {}

  // we're handling GET request to root path from this controller
  @Get()
  findAll(): any[] {
    return this.photoService.getPhotos();
  }
}

Now, we can run both our frontend and backend server to see the list of photos requested via our new API.

nx serve fe-photos

nx serve api-photos

We still need to implement the liking and disliking feature in the Nest app. To do this, let's follow the same approach as we did earlier. First, let's add the liking functionality to PhotosService:

// apps/api/photos/src/app/photos/photos.service.ts

@Injectable()
export class PhotosService {

  /* rest of the service */

  likePhoto(id: string): Photo {
    const photo = this.state[id];
    this.state = {
      ...this.state,
      [id]: {
        ...photo,
        likes: photo.likes + 1,
      },
    };
    return this.state[id];
  }
}

and similarly, we can implement the dislike functionality

// apps/api/photos/src/app/photos/photos.service.ts

@Injectable()
export class PhotosService {

  /* rest of the service */

  dislikePhoto(id: string): Photo {
    const photo = this.state[id];
    this.state = {
      ...this.state,
      [id]: {
        ...photo,
        dislikes: photo.dislikes + 1,
      },
    };
    return this.state[id];
  }
}

With both methods in place, all that is left to do is implement to endpoints in the PhotosController and use methods provided by a PhotosService:


@Controller('photos')
export class PhotosController {

  /* rest of the controller */

  @Put(':photoId/like')
  likePhoto(@Param() params: {photoId: string}): Photo {
    return this.photoService.likePhoto(params.photoId);
  }

  @Put(':photoId/dislike')
  dislikePhoto(@Param() params: {photoId: string}): Photo {
    return this.photoService.dislikePhoto(params.photoId);
  }
}

The path params are defined analogously to how we define params in Angular routing with the : prefix, and to access those params we can use @Param() decorator for a method's parameter. Now, after our server reloads, we can see that the applications are working as expected with both the liking and disliking functionalities working.

Common interfaces

In this final section, I would like to show you how we can benefit from the monorepo approach by extracting the common interface between the frontend and backend to a separate library. Let's start by creating a library, again using the Nx command tools.

nx g @nrwl/workspace:library photo/api

This will generate a new library under libs/photo/api/ folder. Let's create a new file libs/photo/api/src/lib/photo.model.ts and put the ApiPhoto interface in it so it can be shared by both frontend and backend applications.

// libs/photo/api/src/lib/photo.model.ts

export interface ApiPhoto {
  id: string;
  title: string;
  url: string;
  likes: number;
  dislikes: number;
}

We need to export this interface in the index.ts file of the library as well:

// libs/photo/api/src/index.ts

export * from './lib/photo.model';

There is no way we can use the same interface for an API request in both of our applications. This way, we make sure that the layer of communication between our applications in always up to date. Whenever we change the structure of the data in our server application, we will have to apply the appropriate changes to the frontend application as well as the TypeScript compiler. This forces data to be consistent and braking changes to be more manageable.

Conclusion

As you can see, maintaining the project in a monorepo makes it easier to maintain. Nest framework is a great choice for a team of developers that are acquainted with Angular as it builds on top of similar principles. All of that can be easily managed by the Nx toolset.

You can find the code for this article's end result on my GitHub repo.

Checkout the nxAngularNest_ready tag to get the up-to-date and ready-to-run solution. To start the app you need to serve both Angular and Nest projects:

nx serve fe-photos

nx serve api-photos

In case you have any questions you can always tweet or DM me @ktrz. I'm always happy to help!

This Dot is a consultancy dedicated to guiding companies through their modernization and digital transformation journeys. Specializing in replatforming, modernizing, and launching new initiatives, we stand out by taking true ownership of your engineering projects.

We love helping teams with projects that have missed their deadlines or helping keep your strategic digital initiatives on course. Check out our case studies and our clients that trust us with their engineering.

Chris Trześniewski

Software Engineer, ultra-marathoner. He is passionate about functional programming in JavaScript and loves working with RxJS. In his free time he likes to go jogging.

@ktrz__@ktrz

Exploring Angular Forms: A New Alternative with Signals

Exploring Angular Forms: A New Alternative with Signals In the world of Angular, forms are essential for user interaction, whether you're crafting a simple login page or a more complex user profile interface. Angular traditionally offers two primary approaches: template-driven forms and reactive forms. In my previous series on Angular Reactive Forms, I explored how to harness reactive forms' power to manage complex logic, create dynamic forms, and build custom form controls. A new tool for managing reactivity - signals - has been introduced in version 16 of Angular and has been the focus of Angular maintainers ever since, becoming stable with version 17. Signals allow you to handle state changes declaratively, offering an exciting alternative that combines the simplicity of template-driven forms with the robust reactivity of reactive forms. This article will examine how signals can add reactivity to both simple and complex forms in Angular. Recap: Angular Forms Approaches Before diving into the topic of enhancing template-driven forms with signals, let’s quickly recap Angular's traditional forms approaches: 1. Template-Driven Forms: Defined directly in the HTML template using directives like ngModel, these forms are easy to set up and are ideal for simple forms. However, they may not provide the fine-grained control required for more complex scenarios. Here's a minimal example of a template-driven form: ` ` 2. Reactive Forms: Managed programmatically in the component class using Angular's FormGroup, FormControl, and FormArray classes; reactive forms offer granular control over form state and validation. This approach is well-suited for complex forms, as my previous articles on Angular Reactive Forms discussed. And here's a minimal example of a reactive form: ` ` Introducing Signals as a New Way to Handle Form Reactivity With the release of Angular 16, signals have emerged as a new way to manage reactivity. Signals provide a declarative approach to state management, making your code more predictable and easier to understand. When applied to forms, signals can enhance the simplicity of template-driven forms while offering the reactivity and control typically associated with reactive forms. Let’s explore how signals can be used in both simple and complex form scenarios. Example 1: A Simple Template-Driven Form with Signals Consider a basic login form. Typically, this would be implemented using template-driven forms like this: ` ` This approach works well for simple forms, but by introducing signals, we can keep the simplicity while adding reactive capabilities: ` ` In this example, the form fields are defined as signals, allowing for reactive updates whenever the form state changes. The formValue signal provides a computed value that reflects the current state of the form. This approach offers a more declarative way to manage form state and reactivity, combining the simplicity of template-driven forms with the power of signals. You may be tempted to define the form directly as an object inside a signal. While such an approach may seem more concise, typing into the individual fields does not dispatch reactivity updates, which is usually a deal breaker. Here’s an example StackBlitz with a component suffering from such an issue: Therefore, if you'd like to react to changes in the form fields, it's better to define each field as a separate signal. By defining each form field as a separate signal, you ensure that changes to individual fields trigger reactivity updates correctly. Example 2: A Complex Form with Signals You may see little benefit in using signals for simple forms like the login form above, but they truly shine when handling more complex forms. Let's explore a more intricate scenario - a user profile form that includes fields like firstName, lastName, email, phoneNumbers, and address. The phoneNumbers field is dynamic, allowing users to add or remove phone numbers as needed. Here's how this form might be defined using signals: ` > Notice that the phoneNumbers field is defined as a signal of an array of signals. This structure allows us to track changes to individual phone numbers and update the form state reactively. The addPhoneNumber and removePhoneNumber methods update the phoneNumbers signal array, triggering reactivity updates in the form. ` > In the template, we use the phoneNumbers signal array to dynamically render the phone number input fields. The addPhoneNumber and removePhoneNumber methods allow users to reactively add or remove phone numbers, updating the form state. Notice the usage of the track function, which is necessary to ensure that the ngFor directive tracks changes to the phoneNumbers array correctly. Here's a StackBlitz demo of the complex form example for you to play around with: Validating Forms with Signals Validation is critical to any form, ensuring that user input meets the required criteria before submission. With signals, validation can be handled in a reactive and declarative manner. In the complex form example above, we've implemented a computed signal called formValid, which checks whether all fields meet specific validation criteria. The validation logic can easily be customized to accommodate different rules, such as checking for valid email formats or ensuring that all required fields are filled out. Using signals for validation allows you to create more maintainable and testable code, as the validation rules are clearly defined and react automatically to changes in form fields. It can even be abstracted into a separate utility to make it reusable across different forms. In the complex form example, the formValid signal ensures that all required fields are filled and validates the email and phone numbers format. This approach to validation is a bit simple and needs to be better connected to the actual form fields. While it will work for many use cases, in some cases, you might want to wait until explicit "signal forms" support is added to Angular. Tim Deschryver started implementing some abstractions around signal forms, including validation and wrote an article about it. Let's see if something like this will be added to Angular in the future. Why Use Signals in Angular Forms? The adoption of signals in Angular provides a powerful new way to manage form state and reactivity. Signals offer a flexible, declarative approach that can simplify complex form handling by combining the strengths of template-driven forms and reactive forms. Here are some key benefits of using signals in Angular forms: 1. Declarative State Management: Signals allow you to define form fields and computed values declaratively, making your code more predictable and easier to understand. 2. Reactivity: Signals provide reactive updates to form fields, ensuring that changes to the form state trigger reactivity updates automatically. 3. Granular Control: Signals allow you to define form fields at a granular level, enabling fine-grained control over form state and validation. 4. Dynamic Forms: Signals can be used to create dynamic forms with fields that can be added or removed dynamically, providing a flexible way to handle complex form scenarios. 5. Simplicity: Signals can offer a simpler, more concise way to manage form states than traditional reactive forms, making building and maintaining complex forms easier. Conclusion In my previous articles, we explored the powerful features of Angular reactive forms, from dynamic form construction to custom form controls. With the introduction of signals, Angular developers have a new tool that merges the simplicity of template-driven forms with the reactivity of reactive forms. While many use cases warrant Reactive Forms, signals provide a fresh, powerful alternative for managing form state in Angular applications requiring a more straightforward, declarative approach. As Angular continues to evolve, experimenting with these new features will help you build more maintainable, performant applications. Happy coding!...

Oct 4, 2024

5 mins

AngularJavaScript

How to Develop a Vision Pro App using Angular with Nathan Walker

In this training led by Nathan Walker, viewers are introduced to Angular app development for VisionPro. The session covers integrating 3D models, manipulating them with NeoScript Swift, and using USDZ files, with a focus on asset management and Swift packages for immersive experiences. Nathan also reviews integrating and manipulating 3D models using NeoScript Swift, enhancing Angular apps with interactive and visually appealing interfaces. The use of USDZ files added stunning 3D graphics, bringing apps to life. The training also explores the interaction between NativeScript views and Swift UI components, demonstrating the flexibility in app development. This integration allows developers to create dynamic user interfaces, combining the strengths of Angular and Swift UI for exceptional user experiences....

Jun 11, 2024

1 min

AngularJavaScript

Getting Started with Custom Structural Directives in Angular

Introduction Angular comes with many built-in directives. Some of them (eg. NgIf, NgModel or FormControlDirective) are used daily by Angular developers. Those directives can be split into 2 categories: - Attribute directives They can be used to modify the appearance of behavior of Angular components and DOM elements. For example: - RouterLink - NgModel - FormControlDirective - Structural directives They can be used to manipulate the HTML structure in the DOM. Using them, we can change the structure of part of the DOM that they control. For example: - NgIf - NgForOf - NgSwitch In this article, I will focus on the latter. Creating a custom structural directive As I've mentioned above, there are a couple of built-in structural directives in Angular. However, we might come across a case that the ones provided with the framework don't solve. This is where a custom structural directive might help us resolve the issue. But how do we write one? --- All the code examples in this article use the Angular CLI or Nx CLI generated project as a starting point. You can generate a project using the following command, or use Stackblitz starter project. ` --- NgIf directive clone Let's learn the basic concepts by reimplementing the basic features of the NgIf directive. We will call it CsdIf (CSR prefix stands for Custom Structural Directive :)) The structural directive is actually just a regular directive (with some additional syntactic sugars provided by Angular). So we can start with creating a module and empty directive using AngularCLI: ` our new directive should look like this: ` Let's implement the basic functionality of displaying the content if passed value is true. ` To achieve that, we need a couple of elements: - an input that will determine whether to show or hide the content (@Input) - a reference to the template that we want to conditionally display (TemplateRef) - a container that will provide us with access to Angular's view (ViewContainerRef) The input can be just a regular class property with Angular's @Input decorator. The important thing is to use a proper naming convention. For it to work as it does in the example code shown above, we need to name the property the same as the attribute's selector: ` Now our directive has the information whether to display the content or not but we need to also gain access to the TemplateRef and ViewContainerRef instances. We can do that by injecting them via a constructor: ` Now we have all the necessary tools and information to display or hide the content. We can use ViewContainerRef's createEmbeddedView method to display and clear method to remove the content. Important note: To make sure the csdIf property is assigned already, we need to use ngOnInit lifecycle hook. ` With this implementation, the following example already works as expected. ` There is still a problem with this implementation. Let's try to use the following example: ` The "My conditional header" is displayed correctly when the page renders but as soon as we uncheck the showInput, our header doesn't disappear as we would expect. This is because we only check the csdIf input value inside of ngOnInit, but we do not react to the input's changes. To resolve this, we can either use ngOnChanges lifecycle hook or modify the csdIf to be a setter rather than just a property. I will show you the later solution but implementing it using ngOnChanges should be very similar. As a first step, let's modify the csdIf to be a setter, and store its value in a private property show. ` Secondly, when the new csdIf value is set, we need to perform the same logic as we do in ngOnInit. We need to make sure though that we don't render the template twice so we can clear the view first in all cases. ` As a final step, let's refactor to remove the code duplication by extracting the common logic into a method. ` Now, our second example works as expected: ` Handling additional parameters - else template The CsdIf directive shows and hides the content based on the boolean input correctly. But the original NgIf directive allows for specifying an alternative template via the "else" property as well. How do we achieve this behavior in our custom directive? This is where understanding the "syntactic sugar" that stands behind the structural directives is crucial. The following NgIf syntax: ` is actually equivalent to the following syntax: ` This means that the else property is actually becoming ngIfElse input parameter. In general, we can construct the property name by concatenating the attribute following * and the capitalized property name (eg. "ngIf" + "Else" = "ngIfElse""). In case of our custom directive it will become "csdIf" + "Else" = "csdIfElse ` is equivalent to ` By analyzing the "unwrapped" syntax we can notice the the reference to an alternative template is passed via the csdIfElse property. Let's add and handle that property in the custom directive implementation: ` This addition makes our directive much more useful, and allows for displaying content for cases when the condition is true or false. If something is not clear, or you want to play with the example directive please visit the example on Stackblitz. Real life example The above example is very simple, but it gives you tools to create your own custom directive when you need it. If you want to have a look at some real-life custom directive example that we've found useful at This Dot Labs, I suggest checking out our route-config open source library. You can read more about it in one of our articles: - Introducing @this-dot/route-config - What's new in @this-dot@route-config v1.2 Summary In this article, we've learnt how to write a simple custom structural directive that handles additional inputs. We've covered the syntactic sugar that stands behind the structural directive, and how it translates into directive's inputs. In the second part, I will show you how to add some additional functionalities to the custom structural directive and present ways to improve type checking experience for the custom directive's templates. In case you have any questions, you can always tweet or DM me at @ktrz. I'm always happy to help!...

Nov 22, 2021

5 mins

AngularTypeScriptDirectiveWeb Development

Java’s AI Evolution: Semantic Caching JVM, and GenAI Architectures with Theresa Mamarella & Brian Sam-Bodden

In this episode of the Modern Web Podcast, Danny Thompson, Director of Technology at This Dot Labs, hosts a conversation with Theresa Mammarella, JVM Engineer at IBM, and Brian Sam-Bodden, Applied AI Engineer at Redis. They explore their talks at JCONF in Dallas, Texas, covering topics like GenAI architectures in the Java community and OpenJDK's Project Valhalla. Their conversation covers Java’s evolution, AI applications, semantic caching, and how these technologies are impacting development workflows and performance optimization. Chapters 00:00 - Introduction 01:00 - Brian on GenAI in the Java Community 01:47 - Java’s Safe Evolution Path 02:17 - Teresa on Project Valhalla 03:54 - Value Classes and Performance 04:33 - Brian on Semantic Caching 06:54 - Challenges of Rewording Prompts 09:15 - What is RAG Architecture? 11:34 - Java’s Role in AI 13:57 - Cost of LLMs and Caching Strategies 15:57 - Teresa on Java’s Future 18:22 - Learning Resources for Java Developers 20:44 - Addressing Misconceptions About Java 22:39 - Final Thoughts Follow Theresa Mammarella & Brian Sam on Social Media Theresa Mammarella Twitter: https://x.com/t_mammarella Brian Sam-Bodden Twitter: https://x.com/bsbodden Theresa Mammarella Linkedin: https://www.linkedin.com/in/tmammarella/ Brian Sam-Bodden Linkedin: https://www.linkedin.com/in/sambodden/...

Oct 29, 2024

1 min

Artificial Intelligence

Let's innovate together!

We're ready to be your trusted technical partners in your digital innovation journey.

Whether it's modernization or custom software solutions, our team of experts can guide you through best practices and how to build scalable, performant software that lasts.

Nx Workspace with Angular and Nest

Nx Workspace with Angular and Nest

Nest Overview

Add Nest app

Building the API

Common interfaces

Conclusion

Chris Trześniewski

You might also like

Exploring Angular Forms: A New Alternative with Signals

How to Develop a Vision Pro App using Angular with Nathan Walker

Getting Started with Custom Structural Directives in Angular

Java’s AI Evolution: Semantic Caching JVM, and GenAI Architectures with Theresa Mamarella & Brian Sam-Bodden

Let's innovate together!

You might also like

Exploring Angular Forms: A New Alternative with Signals

How to Develop a Vision Pro App using Angular with Nathan Walker

Getting Started with Custom Structural Directives in Angular

Java’s AI Evolution: Semantic Caching JVM, and GenAI Architectures with Theresa Mamarella & Brian Sam-Bodden