DEV Community: Sebastian Larrieu

Building a feature flags Angular NPM library

Sebastian Larrieu — Sun, 26 Apr 2020 21:36:07 +0000

Hi everyone, in this tutorial we will create and publish a NPM library for Angular. In this case, we are going to use services, directives and the Angular injector to build a feature flag library that will allow us to show (or hide) features based on conditions, like a custom *ngIf.

Lets start with the Angular library skeleton, it will allow us to create and test the library. Using CLI:

// You could change prefix or don't use parameter, default prefix is app
ng new ngx-flags --prefix=slr
cd ngx-flags
ng generate library ngx-feature-flags

Now we have a src folder where we will test and use the library (as in a real Angular project) and a project folder where we will write the actual library code. You could delete component.ts and .spec.ts in project/src/lib as we don't need them.

Lets write the service, it will hold the features list and be consulted by directives to check if a feature is set to on.
We need a Map to maintain de features and a bool to check if we have already initialised it.

private featureFlags: Map<string, boolean>;
private initialized = false;

get Initialized() {
  return this.initialized;
}

As we are building a library, we don't know how people will set their features so we will inject a lambda function in constructor for the initialisation action. I will talk about this later. We also need a refresh token to update the view when a new Map arrives.

private refresh: Subject<boolean>;
public refresh$: Observable<boolean>;

constructor(private initFun: () => Promise<Map<string, boolean>>) {
 this.featureFlags = new Map();
 this.refresh = new Subject();
 this.refresh$ = this.refresh.asObservable();
}

As I said, we will use that function to get the features

public async initialize() {
  this.featureFlags.clear();
  this.featureFlags = await this.initFun();
  this.initialized = true;
  this.refresh.next(true);
}

Now the actual work, we need functions to detect and check for a specific feature. We will have both positive and negative because we will probably need to show one section of our app if a feature is enabled or another if its not (like a if-else)

public featureOff(featureName: string) {
  return !this.featureOn(featureName);
}

public featureOn(featureName: string) {
  if (!featureName) {
    return true;
  }
  return this.featureFlags.has(featureName) && is.featureFlags.get(featureName);
}

Now we are going to build two structural directives to show elements based on a feature name (you could read more about structural directives here, the basic information you need right now its that when we use structural directives (with an * like *ngIf) Angular allow us to inject the host element to manipulate it. So inside the lib folder of the library project run

ng g directive showIfFeature
ng g directive showIfNotFeature

I will show one of them, as are both equivalent. We will need a private nameFeature property and an Input setter so we can react to changes, if you don't like this approach, you could use onChage lifeCycle hook. As we are building a structural directive to manipulate DOM, we need the TemplateRef (holds a reference to its host element) and ViewContainerRef (a container where we can attach views). We will use the refresh token to update the view when the service told us that the features are available. We will also need the service we have just write so lets inject all the things.

private featureName: string;

@Input() set ngxShowIfFeature(feature: string) {
  this.featureName = feature;
  this.showOrHide();
}
 private subs: Subscription;

 constructor(private featureFlagService: NgxFeatureFlagsService, private templateRef: TemplateRef<any>, private vcr: ViewContainerRef) {}

ngOnInit() {
  this.subs = new Subscription();
  this.subs.add(this.featureFlagService.refresh$.subscribe(() => this.showOrHide()));
}

//Never forget to unsubscribe to avoid memory leaks
ngOnDestroy() {
  this.subs.unsubscribe();
}

With all in place, the showOrHide is very simple. We check the condition and put the view (the templateRef) in DOM using the vcr.

private showOrHide() {
  if (this.featureName) {
    const featureOn = this.featureFlagService.featureOn(this.featureName);

    if (featureOn && !this.hasView) {
      this.vcr.createEmbeddedView(this.templateRef);
      this.hasView = true;
    } else if (!featureOn && this.hasView) {
      this.vcr.clear();
      this.hasView = false;
    }
  }
}

Now lets build a guard so we could also control navigation based on our feature service. Lets use CLI (check both canActivate and canActivateChild).

 ng g guard featureFlags

Now we have to add a constructor and change canActivate to use our feature service. We will use the data property to tell our guard wich feature are we checking

constructor(private featureFlagService: FeatureFlagService) { }

async canActivate(route: ActivatedRouteSnapshot) {
  const featureFlag = route.data.featureFlag;

  if (!featureFlag) {
    return true;
  }

  if (this.featureFlagService.Initialized) {
    return this.featureFlagService.featureOn(featureFlag);
  } else {
    await this.featureFlagService.initialize();
    return this.featureFlagService.featureOn(featureFlag);
  }
}

The canActivateChild() will reuse the canActivate.

async canActivateChild(route: ActivatedRouteSnapshot) {
  return await this.canActivate(route);
}

We are almost done with coding. Remember to add directives to export array in the library module. Also remove the injectable part from the service. Don't worry, I will talk about this in next steps.

// remove this
import { Injectable } from '@angular/core';

// and this
@Injectable({
  providedIn: 'root'
})

We are almost there, now we can compile the libray, in root folder run

ng build ngx-feature-flags

If everything finish correctly, lets configure and use the library in the application. I forgot to change the selector in library so inside tslint.json change 'lib' for 'ngx' and change directives names.

If you remember, our library need an injected function so it could initialise the features Map. I'm going to write a service so I could get that information from anywhere (maybe hard-coding features at first, and using an API later), that is the best part of using services for abstraction.
So from the root folder use the CLI to create the service in the app

cd src/app
ng g service featuresConfiguration

This is a normal service (so we can inject any other service we need in the constructor in order to get the features of our system). For this tutorial, I'm just going to return a harcoded Map (don't judge me). The function must be a lamda so it will keep context if we use some injected service to get the features (for example, an userService with an API connection method to get permissions from current logged user)

 constructor() { }

 public getFeatureFlags = async (): Promise<Map<string, boolean>> => {
  const flags = new Map<string, boolean>();
  flags.set('featureA', true);
  flags.set('featureB', false);
  return flags;
}

You may be wondering ¿How could I inject that function in the library service?. Well, the answer is factory providers. We will create a provider that will inject that function as the initFun of the flags service.

In the app folder, create a ngx-feature-flags.service.provider.ts. It will have a factory to create the service and a provider section that will use that factory.

import { FeatureFlagProviderService } from './feature-flag-provider.service';
import { FeatureFlagService } from './feature-flags.service';

const featureFlagServiceFactory = (provider: FeatureFlagProviderService) => {
  return new FeatureFlagService(provider.getFeatureFlags);

};

export let FeatureFlagServiceProvider = {
  provide: FeatureFlagService,
  useFactory: featureFlagServiceFactory,
  deps: [FeaturesConfigurationService]
};

If the factory need some services, for example the FeatureFlagProviderService, you have to add them in the deps array of the provider. Now in the providers array section of the appModule, you have to add the FeatureFlagServiceProvider and also add the NgxFeatureFlagsModule in the imports array.

Now lets change the app.html to use our new directives

<div style="text-align:center">
  <h1>
    Welcome to {{ title }}!
  </h1>
</div>
<h2>Here are some links features: </h2>
<ul>
  <li *ngxShowIfFeature="'featureA'">
    <p>Feature A </p>
  </li>
  <li *ngxShowIfFeature="'featureB'">
    <p>Feature B </p>
  </li>
  <li *ngxShowIfNotFeature="'featureC'">
    <p>Feature C </p>
  </li>
</ul>

Lets add some scripts in package.json to test the library

"build-lib": "ng build ngx-feature-flags",
"debug": "npm run build-lib && ng serve"

Now if you run the command and go to localhost:4200, you will only see Feature C, as we didn't enable any feature. To change that, inject the feature service in app component and call the init function.

export class AppComponent {
  title = 'ngx-flags';

  constructor(private flagService: NgxFeatureFlagsService) {
    this.flagService.initialize();
  } 
}

Now save and go to the browser again for a TA-DA moment!

The library is ready so lets publish it. Lets add a readme and a license files and some more NPM scripts.

"package": "npm run build-lib && npm run copy-files && npm run npm-pack",
"debug": "npm run build-lib && ng serve",
"build-lib": "ng build ngx-feature-flags",
"copy-files": "npm run copy-license && npm run copy-readme",
"copy-license": "cp ./LICENSE ./dist/ngx-feature-flags",
"copy-readme": "cp ./README.md ./dist/ngx-feature-flags",
"npm-pack": "cd dist/ngx-feature-flags && npm pack"

Then you have to package and publish. First run npm login and complete with username, pass and email when asked. Then in root folder run

npm run package
npm publish dist/ngx-feature-flags/ngx-feature-flags-1.0.0.tgz --access public

And its done. If you don't want to publish the library, you just cant install the generated .tgz using npm install path-to-file or use my library :), it's already in NPM.

That's all. I hope you liked it, this is the project github.

sebalr / ngx-feature-flags

Feature flags Angular library

Video call with WebRTC Angular and ASP.NET Core

Sebastian Larrieu — Mon, 27 Jan 2020 01:27:08 +0000

Hi everyone, in this post we will build a basic video call web using WebRTC,Angular and ASP.Net Core. Why? because this technologies are like read meat and malbec, their just pair well (I will write a post about this). This is going to be a very basic app with a lot of point for improvement but I will focus on basics.

WebRTC 'Supports video, voice, and generic data to be sent between peers', but as in any p2p system we need a signaling communication channel so users can discover each other, we will user singlaR for that.

The git repos are at the end of the post.

Lets begin with Backend

We only need a signaling server so create a .Net Core web api project and add singalR nuget package



dotnet new webapp -o signalRtc
cd signalRtc
dotnet add package Microsoft.AspNetCore.SignalR.Core

You could remove the controller folder that is created.

Now we need a hub, as docs saids, a hub 'allows a client and server to call methods on each other', I like to think that we invoke methods from frontend and listen to event from backend. So create a hubs folder and a class that extends Hub.



using System.Text.Json;
using System.Threading.Tasks;
using Microsoft.AspNetCore.SignalR;
using signalRtc.models;

namespace signalRtc.hubs
{
    public class SignalRtcHub : Hub
    {
    }
}

There are 3 (or 4) basic actions that we need in order to make a video call app.

Every new user need to notify they arrival.
Existing users need to inform their presence to new user.
Share signaling data between peers for WebRTC.
Notify users when someone disconnect.

As I said, we are going to write task in the hub class that can be executed from the Angular project and send some data to frontend too.

First create a folder models with a UseInfo class to encapsulate user data



namespace signalRtc.models
{
    public class UserInfo
    {
        public string userName { get; set; }
        public string connectionId { get; set; }
    }
}

The connectionId it's an unique identifier that signlarR give to each connected user so we can identify they, we will need it to send messages to that specific user.

Point #1



public async Task NewUser(string username)
{
    var userInfo = new UserInfo() { userName = username, connectionId = Context.ConnectionId };
    await Clients.Others.SendAsync("NewUserArrived", JsonSerializer.Serialize(userInfo));
}

In this short piece of code we use many of the signalR great features. The task is the action that we can invoke from frontend, there we create a User object with the current user id that we get from Context. We don't want to receive our "hello I'm a new user" so we send the message to "others", that means all users connected to the hub but not me, signalR keep the list of user for us. The "NewUserArrived" string is an identifier that we will use later in frontend to receive this messages, you could write any name you like.

Point #2 When we get the "NewUser" message, we need to inform of our existence to the new user with a hello.



public async Task HelloUser(string userName, string user)
{
    var userInfo = new UserInfo() { userName = userName, connectionId = Context.ConnectionId };
    await Clients.Client(user).SendAsync("UserSaidHello", JsonSerializer.Serialize(userInfo));
}

The task receive two parameters, the username of the user that is saying hello and the user that we are saluting. In order to send a message to one user, we use Clients.Client('connectionId')... In this case, we are sending a "UserSaidHello" event to frontend.

Point #3 is simple, we want to send our signal to a user to start a p2p videocall



public async Task SendSignal(string signal, string user)
{
    await Clients.Client(user).SendAsync("SendSignal", Context.ConnectionId, signal);
}

Last but not essential, we want to inform to the group when a user disconnect, to do that we are going to override the onDisconnect task.



public override async Task OnDisconnectedAsync(System.Exception exception)
{
    await Clients.All.SendAsync("UserDisconnect", Context.ConnectionId);
    await base.OnDisconnectedAsync(exception);
}

We are almost done with backend, we need to indicate to NetCore that we are using singlaR so in the Startup.cs add singalR in configureService (also cors for angular port) and an endpoint for the singalR communication



public void ConfigureServices(IServiceCollection services)
{
    services.AddCors(options =>
    {
        options.AddPolicy(MyAllowSpecificOrigins,
            builder => builder.WithOrigins("http://localhost:4200", "https://localhost:4200")
            .AllowAnyMethod()
            .AllowAnyHeader()
            .AllowCredentials());
    });

    services.AddSignalR();
}

readonly string MyAllowSpecificOrigins = "AllowOrigins";


public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    if (env.IsDevelopment())
    {
        app.UseDeveloperExceptionPage();
    }

    app.UseRouting();
    app.UseCors(MyAllowSpecificOrigins);
    app.UseEndpoints(endpoints =>
    {
        endpoints.MapHub<SignalRtcHub>("/signalrtc");
    });

    app.Run(async(context) =>
    {
        await context.Response.WriteAsync("Hello World!");
    });
}

Lets move to Angular
First create a new Angular project and install few dependencies.
simple-peer (and its types, because we love static type checking) for WebRTC.
Bootrstap, because I know you could do everything with plain css and flex or grid, but I like bootstrap.
SignalR, to invoke the method we just wrote and receive the messages.
Remember to choose scss when cli ask.



ng new signalRtc
cd signalRtc
npm install simple-peer
npm install @types/simple-peer
npm install bootstrap
npm install @aspnet/signalr

To add sytles, open styles.scss and add "@import '~bootstrap/dist/css/bootstrap.min.css';"

First lets create a service to manage the singalR messages.



cd src/app
ng g service signalr

We need a private property to maintain the hub connection, we also need subjects and observables to encapsulate the events from signalR library. I like to have private subjects to emit values via methods and public observables to get data in components.



private hubConnection: signalR.HubConnection;

private newPeer = new Subject<UserInfo>();
public newPeer$ = this.newPeer.asObservable();

private helloAnswer = new Subject<UserInfo>();
public helloAnswer$ = this.helloAnswer.asObservable();

private disconnectedPeer = new Subject<UserInfo>();
public disconnectedPeer$ = this.disconnectedPeer.asObservable();

private signal = new Subject<SignalInfo>();
public signal$ = this.signal.asObservable();

As you can see, we have an observable for every task and some interfaces that you could write in a separate file



export interface PeerData {
  id: string;
  data: any;
}

export interface UserInfo {
  userName: string;
  connectionId: string;
}

export interface SignalInfo {
  user: string;
  signal: any;
}

Now we will write some methods, we need one to start a connection, one for response to the new user message and one to send the p2p signal

Start a connection



  public async startConnection(currentUser: string): Promise<void> {

    this.hubConnection = new signalR.HubConnectionBuilder()
      .withUrl('https://localhost:5001/signalrtc')
      .build();

    await this.hubConnection.start();
    console.log('Connection started');

    this.hubConnection.on('NewUserArrived', (data) => {
      this.newPeer.next(JSON.parse(data));
    });

    this.hubConnection.on('UserSaidHello', (data) => {
      this.helloAnswer.next(JSON.parse(data));
    });

    this.hubConnection.on('UserDisconnect', (data) => {
      this.disconnectedPeer.next(JSON.parse(data));
    });

    this.hubConnection.on('SendSignal', (user, signal) => {
      this.signal.next({ user, signal });
    });

    this.hubConnection.invoke('NewUser', currentUser);
  }

As you can see from code, we start the connection and encapsulate the message events in observables, also when we start a connection we send the 'Hello I'm a new user' message. That's the two way communication with backend, via invoke we execute task and receive data with 'on'.

Now to say hello new user and send signal data, we only need to invoke hub methods



public sendSignalToUser(signal: string, user: string) {
  this.hubConnection.invoke('SendSignal', signal, user);
}

public sayHello(userName: string, user: string): void {
  this.hubConnection.invoke('HelloUser', userName, user);
}

Now we are going to write a rtc service, similar to the signalR one, to encapsulate the simplee-peer events. We also need to maintain the list of connected users to start a conversation and the current peer we are talking to.



import { Injectable } from '@angular/core';
import { Observable, Subject, BehaviorSubject } from 'rxjs';
import { Instance } from 'simple-peer';

declare var SimplePeer: any;

@Injectable({
  providedIn: 'root'
})
export class RtcService {

  private users: BehaviorSubject<Array<UserInfo>>;
  public users$: Observable<Array<UserInfo>>;

  private onSignalToSend = new Subject<PeerData>();
  public onSignalToSend$ = this.onSignalToSend.asObservable();

  private onStream = new Subject<PeerData>();
  public onStream$ = this.onStream.asObservable();

  private onConnect = new Subject<PeerData>();
  public onConnect$ = this.onConnect.asObservable();

  private onData = new Subject<PeerData>();
  public onData$ = this.onData.asObservable();

  public currentPeer: Instance;

  constructor() {
    this.users = new BehaviorSubject([]);
    this.users$ = this.users.asObservable();
  }

}

When a user arrives, we add it to the list, and when they disconnect, we remove it (always in an immutable way), let’s add some methods in service for that



 public newUser(user: UserInfo): void {
  this.users.next([...this.users.getValue(), user]);
}

public disconnectedUser(user: UserInfo): void {
  const filteredUsers = this.users.getValue().filter(x => x.connectionId === user.connectionId);
  this.users.next(filteredUsers);
}

When we start a conversation, we need to create a peer instance. The simple peer library need and indication to know if we are initiating the p2p connection. It also provide some events that we will encapsulate (because we love observables). The most important event is 'signal', quoting the library description: 'Fired when the peer wants to send signaling data to the remote peer.

It is the responsibility of the application developer (that's you!) to get this data to the other peer' that's the whole point of signalR



  public createPeer(stream, userId: string, initiator: boolean): Instance {
    const peer = new SimplePeer({ initiator, stream });

    peer.on('signal', data => {
      const stringData = JSON.stringify(data);
      this.onSignalToSend.next({ id: userId, data: stringData });
    });

    peer.on('stream', data => {
      console.log('on stream', data);
      this.onStream.next({ id: userId, data });
    });

    peer.on('connect', () => {
      this.onConnect.next({ id: userId, data: null });
    });

    peer.on('data', data => {
      this.onData.next({ id: userId, data });
    });

    return peer;
  }

Finally, we have a method to signal a peer Instance, this actions is required by simple-peer. We have to check if exist a current peer, if it don't, it means that we are not the initiator and we have to create it because someone is staring a videocall with us



public signalPeer(userId: string, signal: string, stream: any) {
    const signalObject = JSON.parse(signal);
    if (this.currentPeer) {
      this.currentPeer.signal(signalObject);
    } else {
      this.currentPeer = this.createPeer(stream, userId, false);
      this.currentPeer.signal(signalObject);
    }
  }

public sendMessage(message: string) {
  this.currentPeer.send(message);
}

We also create a sendMessage for the chat part, because WebRTC allow to send binary data between peers. We could have used signalR but we only want it as a signaling server.

Now let's change app.component.htm, we will add an input for our username and a place for a chat. Following good practice, we will make a special component to manage the connected users list to keep a place for that.



<div class="container-fluid">
  <h1>SignalRTC</h1>
  <div class="row">
    <div class="col-5">
      <div class="row">
        <div class="col">
          <input [(ngModel)]="currentUser" required placeholder="UserName" type="text">
        </div>
        <div class="col">
          <div class="btn-group" role="group" aria-label="button group">
            <button [disabled]="!currentUser" (click)="saveUsername()" type="button"
              class="btn btn-sm btn-primary">Save</button>
          </div>
        </div>
      </div>
      <div class="row">
        <div class="col">
          <!-- user list component -->
        </div>
      </div>
    </div>
    <div class="col-7">
      <div class="row">
        <div class="col-8">
          <input [(ngModel)]="dataString" required placeholder="Write a message" type="text">
        </div>
        <div class="col-4">
          <button (click)="sendMessage()" type="button" class="btn btn-sm btn-secondary">Send</button>
        </div>
      </div>
    </div>
  </div>
</div>

This is the list component,just a simple list where we can click an user in order to start a videocall, the component will emit an event so we can react in the app component.



<ul class="list-group mt-4">
  <li class="list-group-item" (click)="userClicked(user)" *ngFor="let user of users$ | async">
    {{user.userName}}
  </li>
</ul>



 @Output() userSelected: EventEmitter<UserInfo> = new EventEmitter();

  public users$: Observable<Array<UserInfo>>;


  constructor(private rtcService: RtcService) { }

  ngOnInit() {
    this.users$ = this.rtcService.users$;
  }

  public userClicked(user: UserInfo) {
    this.userSelected.emit(user);
  }

Now you can change the app.component.html and replace the comment for the actual list component.



<app-user-list (userSelected)="onUserSelected($event)"></app-user-list>

In the component, we will use the OnInit method (in Angular we have to keep constructor clean) to suscribe to all the obserable we defined and disptach the actions we need.



ngOnInit() {
    this.subscriptions.add(this.signalR.newPeer$.subscribe((user: UserInfo) => {
      this.rtcService.newUser(user);
      this.signalR.sayHello(this.currentUser, user.connectionId);
    }));

    this.subscriptions.add(this.signalR.helloAnswer$.subscribe((user: UserInfo) => {
      this.rtcService.newUser(user);
    }));

    this.subscriptions.add(this.signalR.disconnectedPeer$.subscribe((user: UserInfo) => {
      this.rtcService.disconnectedUser(user);
    }));

    this.subscriptions.add(this.signalR.signal$.subscribe((signalData: SignalInfo) => {
      this.rtcService.signalPeer(signalData.user, signalData.signal, this.stream);
    }));

    this.subscriptions.add(this.rtcService.onSignalToSend$.subscribe((data: PeerData) => {
      this.signalR.sendSignalToUser(data.data, data.id);
    }));

    this.subscriptions.add(this.rtcService.onData$.subscribe((data: PeerData) => {
      console.log(`Data from user ${data.id}: ${data.data}`);
    }));

    this.subscriptions.add(this.rtcService.onStream$.subscribe((data: PeerData) => {
      this.userVideo = data.id;
      this.videoPlayer.nativeElement.srcObject = data.data;
      this.videoPlayer.nativeElement.load();
      this.videoPlayer.nativeElement.play();
    }));
  }

Brief explanation of each step:

When a user arrives, we add create a new user and send our hell message.
When we receive a hello, we add the user to the list.
When a user disconnect, we remove it from the list.
When when receive a signal we execute the function .signal that it's indicated in the simple-peer documentation.
When simple-peer indicate that the WeRTC signal is ready, we send it to the user.
When we receive a message, we show it.
Finally, when the videostream is ready, we show it in a video tag.

Finally, when we click a user, we create a new peer, this will eventually fire the signal event!
We also have the function to save the username and send a message via the data channel. Also unsubscribe always on the OnDestroy lifecycle hook, in this case we have only one component but following this practice we will prevent memory leaks.



public onUserSelected(userInfo: UserInfo) {
    const peer = this.rtcService.createPeer(this.stream, userInfo.connectionId, true);
    this.rtcService.currentPeer = peer;
  }

  public async saveUsername(): Promise<void> {
    try {
      await this.signalR.startConnection(this.currentUser);
      this.stream = await navigator.mediaDevices.getUserMedia({ video: true, audio: true });
    } catch (error) {
      console.error(`Can't join room, error ${error}`);
    }
  }

  public sendMessage() {
    this.rtcService.sendMessage(this.dataString);
    this.messages = [...this.messages, { own: true, message: this.dataString }];
    this.dataString = null;
  }
  ngOnDestroy() {
    this.subscriptions.unsubscribe();
  }

Okey, that's all folks. As I told you at the beginning, this is a very simple starting point. We have a lot to improve, for example you could use signalR to ask to the other user if they want to accept the call! I wanted to keep it simple.

Frontend:

sebalr / signalrtc-frontend

WebRTC client example

Backend:

sebalr / signalrtc-backend

signalR backend server for webrtc signaling

ASP.NET Core, Carter and Angular, a scalable RESTfull example for ¿beginners? (1)

Sebastian Larrieu — Sun, 09 Jun 2019 20:52:18 +0000

Hi everyone, this is my first post in DEV (or any community). It was on my pending list, but i used to think that I had nothing to write about. I'm not a native english speaker so you may find some errors in redaction, be welcome to correct me.

Let me introduce myself, I'm a software engineering from Argentina, two years ago I get my degree and get a job as a front-end developer but because of the company needs i became what i like to call middle-end developer after few months. Why middle-end? because I really enjoy getting dirty with complex problems and business logic but i'm not a big fan of databases and although I like, I'm neither UX nor UI expert.

In my job we focus on building complex solutions with Angular and ASP.NET Core. Why this technologies? because both have types and IoC out the box, two things we consider essential for building large and maintainable code.

Wait, what is CAInD?, it's a terrible name (came on, I'm a computer person) for what I think its a great stack (maybe if anyone read this, could propose a better name in comments): Carter, Angular, Inversion of Control and ASP.NET Core. I've got many good things to say about this technologies, but i don't want to make this post excessively large so I will write abut them in next days.

In this series of tutorials I will write a very basic but over engineered to-cook app (yes, like a to-do but with food). I will start with basics back-end and front-end structures and then refactor to make them ready to scale in to large projects. The original idea was to start front and back project in same post, but it will be too large so lets start with backend.

After some projects we find what we consider a good basic structure for backend projects.

DTOs to move data between frontend and backend.
Rich models (as in DDD) responsable for simple business data validation, I.E properties that can't be null, and complex operations that don't requiere injected dependencies.
Services for operations that requiere injected dependencies, like accessing database to make a validation, or are used in many modules, I.E sending a push notification.
Extension methods for reusable functions, I.E we have IncludeAllDay to ensure that the time is 23:59:49 in a DateTime var.

This topics will be cover in the tutorials serie. Stop the talking and lets write some code.

First step is install .NET Core SDK and create the project.



dotnet new web -n to-cook

then we move to solution folder and install Carter. Carter its a great tool for, quoting his creator, 'allow a more elegant routing'. In my opinion, the best about it it's that you write method inside module's constructor and have access for injected dependencies in them.



cd to-cook
dotnet add package carter

Next we need to add Carter, in startup.cs


 c#
using System;
using System.Collections.Generic;
using System.Linq;
using System.Threading.Tasks;
using Carter;
using Microsoft.AspNetCore.Builder;
using Microsoft.AspNetCore.Hosting;
using Microsoft.AspNetCore.Http;
using Microsoft.Extensions.DependencyInjection;
using to_cook.Services;

namespace to_cook
{
    public class Startup
    {
        public void ConfigureServices(IServiceCollection services)
        {
            services.AddCarter();
        }

        public void Configure(IApplicationBuilder app)
        {
            if (env.IsDevelopment())
            {
                app.UseDeveloperExceptionPage();
            }
            app.UseCarter();
        }
    }
}

We will start with recipes that we would like to cook. Create a Models folder with Recipe.cs. Properties are virtual (and recipe has an id) because later (in another post) we will add Entity Framework.


 c#
namespace to_cook.Models
{
    public class Recipe
    {
        public virtual int Id { get; set; }
        public virtual string Title { get; set; }
        public virtual string Description { get; set; }
    }
}

Now we will create a super basic "database" for this tutorial. Later we will change this for real data provider and database connection.
Create a Services folder with a RecipeProviderDB.cs.



using System.Collections.Generic;
using to_cook.Models;

namespace to_cook.Services
{
    public interface IRecipeProviderDB
    {
        ICollection<Recipe> Recipes();
    }

    public class RecipeProviderDB : IRecipeProviderDB
    {
        ICollection<Recipe> _recipes;

        public RecipeProviderDB()
        {
            _recipes = new HashSet<Recipe>()
            {
                new Recipe() { Id = 1, Title = "Hamburger pizza" },
                new Recipe() { Id = 2, Title = "Argentine Asado" },
                new Recipe() { Id = 3, Title = "Mexican Tacos" },
            };
        }

        public ICollection<Recipe> Recipes()
        {
            return this._recipes;
        }
    }
}

Why is an IRecipeProviderDB in my file? well, as I said, one of the things we like most about ASP.NET core is that it provide support for dependency injection pattern out of the box.

You can google more about dependency injection but it's a pattern where you use high level abstractions for yours dependencies so you don't have to worry about implementation details, IoC decouple dependencies making software easier to extend and test.

ASP.NET core requiere 3 steps for its DI pattern:

Define an interface (a contract).
Write a class that implements that interface.
Declare the connection between them. It will become clear in few moments, I promise.

For now you can see that IServiceProviderDB (step 1) has a method that return a collection of Recipe, so anyone who has an IRecipeProviderDB know that can ask him for a Recipe collection.
In the same file we wrote a ServiceProvicerDB class with _recipes, our super simple database, it also implements IserviceProviderDB (step 2) so we have to respect the contract (Recipes() method).

Why put both in same file?, just because it's easy when you use go to definition, but you could put interface in a separate file.

Disclaimer: this is not a real "provider". The main purpose of this tutorial is write the basic structure for a RESTfull API. Be patient.

The next step is to create a RecipeProvider in Services. Again, first we define the contract (step 1).



public interface IRecipeProvider
{
    IEnumerable<Recipe> GetAll();
    Recipe GetById(int id);
    Recipe Add(Recipe recipe);
    Recipe Update(int id, Recipe recipe);
    void Delete(int id);
}

Then we write the actual class (step 2), I will explain the class part by part.



public class RecipeProvider : IRecipeProvider
{
    private IRecipeProviderDB _recipeProviderDB;

    public RecipeProvider(IRecipeProviderDB recipeProviderDB)
    {
            _recipeProviderDB = recipeProviderDB;
    }
}

We have _recipeProvider to store the database that we receive via constructor as a dependence. Finally some concrete DI, as I mentioned early, in this particular point RecipeProvider needs an IRecipeProviderDB so it can ask him for the collection of Recipe but it don't care how, when, or why (specially how) will IRecipeProviderDB get it.

Now that we have the database, and because we are good devs, we will write code to honor the IRecipeProvider contract. Lets go one by one:

GetAll() is very simple, we just return the Recipes.



public IEnumerable<Recipe> GetAll()
{
    return this._recipeProviderDB.Recipes();
}

VERY IMPORTANT In a real world, under no circumstance you will return the actual database but a copy. Remember, the main purpose of this tutorial is describe the basic structure of the project. Also you will see that thanks to DI, the change will be transparent for services consumers.

GetById() is also very basic, we first get all recipes and then find the one with the specified id using LINQ, another super awesome c# tool, FirstOrDefault() return the first element matching the where criteria or null.



public Recipe GetById(int id)
{
    return this._recipeProviderDB.Recipes().Where(x => x.Id == id).FirstOrDefault();
}

Okey, lets go now with next in contract list Add(Recipe recipe), add a new Recipe to list and return it. The code is also very simple.



public Recipe Add(Recipe recipe)
{
    this._recipeProviderDB.Recipes().Add(recipe);
    return recipe;
}

Here come the most difficult method: Update(int id, Recipe recipe) we have to put new data in the recipe with the indicated id. In order to do that we have to check that the id is a valid id. Write code twice is a bad practice (most of times) so we reuse the GetById() method that we already have, remember that it could return null.



public Recipe Update(int id, Recipe recipe)
{
    var oldRecipe = this.GetById(id);
    if (oldRecipe != null)
    {
        oldRecipe.Title = recipe.Title;
        oldRecipe.Description = recipe.Description;
        return oldRecipe;
    }
    else
    {
        return null;
    }
}

Passing properties one by one is tedious, in next posts we will use another complex but great tool called AutoMapper.

We are close to complete the contract, last we have Delete(int id), it's similar to update()



public void Delete(int id)
{
    var recipe = this.GetById(id);
    if (recipe != null)
    {
       this._recipeProviderDB.Recipes().Remove(recipe);
    }
}

Now that we already create all we need to manipulate our recipes, we will add our first Carter module. Create a Modules folder with RecipeModule.cs in it. Carter modules are just c# class that extend CarterModule.

We need import some Carter utilities and tell CarterModule that all methods in this endpoint module will work under /recipe URL.

As you can see, we have one injected IRecipeProvider, that means a contract that said we have access to five method, at this point, we don't know how are they implemented (and we don't care).

Note that we don't need to store the provider in a variable because in Carter we write HTTP methods inside constructor so we can access injected dependencies directly. Carter allow many implementations of HTTP methods, we will use one that receive a string and a delegate that return a Task (delegates are like type-safe pointer to functions or anonymous methods).



using System.Threading.Tasks;
using Carter;
using Carter.ModelBinding;
using Carter.Request;
using Carter.Response;
using Microsoft.AspNetCore.Http;
using Microsoft.AspNetCore.Routing;
using to_cook.Models;
using to_cook.Services;

namespace to_cook.Modules
{
    public class RecipeModule : CarterModule
    {
        public RecipeModule(IRecipeProvider recipeProvider) : base("recipe")
        { 
            // Here we will write REST methods
        }
    }
}

RESTful APIs have five basic methods (as we write in our provider)

GET / to get all elements.
GET /{id} to get one element.
POST / to add one element .
PUT /{id} to update one element.
DELETE /{id} to remove one element.

We will add them where comment is. Lets begin with the first one, we use the provider to get all elements and then let Carter magically transform data in a response Json.



Get("/", ctx =>
{
    var recipes = recipeProvider.GetAll();
    return ctx.Response.AsJson(recipes);
});

This one is a little bit trickier.
First we get the id from the URL with another Carter utility, then we use the provider to search the Recipe, if you remember, GetById will give us a null value if it couldn't find an element, in that case we will return a 404.



Get("/{id:int}", ctx =>
{
    var id = ctx.GetRouteData().As<int>("id");

    var recipe = recipeProvider.GetById(id);

    if (recipe != null)
    {
        return ctx.Response.AsJson(recipe);
    }
    else
    {
        ctx.Response.StatusCode = 404;
        return ctx.Response.WriteAsync($"No recipe with id {id} was found");
    }
});

Note 1: WriteAsync will not return a Json, that's not nice, but we will fix that in next tutorials.
Note 2: Although WriteAsync is an asynchronous method, if we don't await for it (and declare our method as async), ASP.NET we will treat it as synchronous. That it's not a problem as we are not doing computationally complex functions, if we where, making our method async would be recommended.

Now lets add a Recipe to our list. First we use more Carter magic to convert the POST body in a class, after that we use the provider to save the recipe in the list. Again, this is a first step and we are assuming that all data is correct and will work without problems (real life is harder, specially if you have to deal with user's inputs), latter we will add DTOs for data transfer and some input validation.



Post("/", ctx =>
{
    var recipe = ctx.Request.Bind<Recipe>();

    var addedRecipe = recipeProvider.Add(recipe);

    return ctx.Response.AsJson(addedRecipe);
});

Next method is a http PUT to update an existing Recipe. We made some basic validation as updating an id is (usually) a very very bad idea.
We have a provider to do all the work so we just call him and return a response.



Put("/{id:int}", ctx =>
{
    var id = ctx.GetRouteData().As<int>("id");
    var newRecipe = ctx.Request.Bind<Recipe>();

    if (id != newRecipe.Id)
    {
        ctx.Response.StatusCode = 400;
        return ctx.Response.WriteAsync("Cant update Id property");
    }

    var editedRecipe = recipeProvider.Update(id, newRecipe);
    return ctx.Response.AsJson(editedRecipe);
});

Finally, we have the DELETE, this one is easy. We tell the provider to delete the Recipe but we don't want to return any information so we use a 204 http code (no content) and return a CompletedTask because, if you remember, Carter expect an anonymous method that return a Task.



Delete("/{id:int}", ctx =>
{
    var id = ctx.GetRouteData().As<int>("id");
    recipeProvider.Delete(id);
    ctx.Response.StatusCode = 204;
    return Task.CompletedTask;
});

Congrats, we almost got it. If you are still here you maybe remember that I told you that ASP.NET Core requiere 3 steps to make DI work, we never did step 3 (connect contract with implementation) and, you know, there's no time like the present..

There are 3 possible ways of making that connection

Add singleton: Create an instances in app startup and share the same instance wherever is injected in all http request.
Add scoped: Create a new instance for every http request (share instance in the request lifetime wherever is injected) .
Add transient: Create a new instance wherever is injected.

Scoped lifetime is the common choice for RESTFull APIs as, by definition, they are stateless. We don't want to share information between request.
Our database is a special case beacause we want it to survive between request, so it has to be a singleton.

In Startup.cs go to ConfigureServices and add the next two lines before services.AddCarter():



services.AddSingleton<IRecipeProviderDB, RecipeProviderDB>();
services.AddScoped<IRecipeProvider, RecipeProvider>();

Now you can finally test the solution. Just run:



dotnet build
dotnet run

Open browser and go to localhost:5000/recipe or use the great vscode plugin REST client (there is a .http in my repo with all method example) and TADA:



[{
    "id": 1,
    "title": "Hamburger pizza"
}, {
    "id": 2,
    "title": "Argentine Asado"
}, {
    "id": 3,
    "title": "Mexican Tacos"
}]

We could stop here, but we have to make one more little thing to let things ready for the integration with our future Angular frontend. The necessary buy horrible CORS. We are going to define a custom CORS policy...
Go to Startup.cs and put a



readonly string AllowSpecificOrigins = "_allowSpecificOrigins";

Then in ConfigureServices() we will add two origins, I will put default Angular port but you could write any URL you like.



services.AddCors(options =>
    {
        options.AddPolicy(AllowSpecificOrigins,
            builder =>
            {
                builder.WithOrigins("http://localhost:4200", "https://localhost:4200")
                    .AllowAnyHeader()
                    .AllowAnyMethod();
             });
    });

Last but not least, we have to tell ASP.NET to use the policy, so in configure() we add:



 app.UseCors(AllowSpecificOrigins);

Now we are done.
This is a screenshot of the project structure:

And the Github repo.

Now we can continue with frontend

ASP.NET Core, Carter and Angular, a scalable RESTfull example for ¿beginners? (2)

Sebastian Larrieu ・ Jun 9 '19

#angular #netcore #api #tutorial

ASP.NET Core, Carter and Angular, a scalable RESTfull example for ¿beginners? (2)

Sebastian Larrieu — Sun, 09 Jun 2019 20:51:10 +0000

Hi everyone again. If you are reading this maybe you finished my previous tutorial:

ASP.NET Core, Carter and Angular, a scalable RESTfull example for ¿beginners? (1)

Sebastian Larrieu ・ Jun 9 ・ 10 min read

#angular #netcore #api #tutorial

Or just want a nice example of how to write a scalabe Angular app. Remember, we are building and over engineered to-cook app (like to-do but with food) starting with some basic structure an refactoring later to make it scalable.

Here is the Github repo for this tutorial.

Let me remains you that I'm not a native english speaker so you could find some errors, please let me know and i will correct them

Let me start with some basics ideas we like to follow in my company after various Angular projects.

Core folder with basic layout components, navbar, sidebar and footer.
Shared backend services to communicate with APIs.
Modules (not only components) to encapsulate functionality I.E RecipeModule with CRUD components for recipes.
Classes (DTOs) to share data between backend and frontend (instead of interfaces).
ViewModels that encapsulate DTOs to use in .ts and .html.
Async-Await instead to make code look better.
Global exception handler to show backend error messages (instead of catching in every http request).

In this tutorial we will build the starter Angular template with some (but not all, as this is a serie) of those concepts using CLI.

Lets begin with a new Angular project. First install CLI if you don't have it, then create a new app and select yes when it ask for routing module and sass for stylesheet.

npm install -g @angular/cli
ng new cook-app
? Would you like to add Angular routing? Yes
? Which stylesheet format would you like to use? 
  CSS 
❯ Sass   [ http://sass-lang.com   ] 
  Less   [ http://lesscss.org     ] 
  Stylus [ http://stylus-lang.com ]

Now we are going to install bootstrap and crate some folders:

cd cook-app
npm install bootstrap
cd src/app
mkdir shared
mkdir dtos
cd shared
touch constants.ts
mkdir backend-services

In constants we will hold the API url for prod and dev enviroment so open file and paste:

import { environment } from 'src/environments/environment.prod';

export const apiUrl = environment.production ? 'http://localhost:5000' : 'http://localhost:5000';

Lets build te comunicaction with the API. Go to dtos folder and create a recipe.dto.ts, it will have the same properties as the backend model and a static method to generate it from a json

export class RecipeDTO {

  id: number;
  title: string;
  description: string;

  public constructor() { }

  public static prepareFromJson(json: any): RecipeDTO {
    const recipe = new RecipeDTO();

    recipe.id = json.id ? json.id : 0;
    recipe.title = json.title ? json.title : undefined;
    recipe.description = json.description ? json.description : undefined;

    return recipe;
  }

}

Now use CLI to create a service in backend-services folder.

ng g service recipeBackend

In this service we will write the method to comunicate with backend, lets start with getting all the recipes:

import { Injectable } from '@angular/core';
import { HttpClient } from '@angular/common/http';
import { apiUrl } from 'src/app/shared/constants';
import { RecipeDTO } from '../dtos/recipe.dto';

@Injectable({
  providedIn: 'root'
})
export class RecipeBackendService {

  constructor(private httpClient: HttpClient) { }

  public async getAll(): Promise<Array<RecipeDTO>> {
    const recipes = new Array<RecipeDTO>();

    const res = await this.httpClient.get<any>(`${apiUrl}/recipe`).toPromise();

    for (const item of res) {
      recipes.push(RecipeDTO.prepareFromJson(item));
    }
    return recipes;
  }

}

As i tell you before, i use await because code look cleaner that .then() chains. You may be wondering what about error as there is no try-catch. Well, for now we will asume that everything is going to work (sadly this never happen in real life), in next post we will implement an exception handler that will handle all errors in one place.

In Angular, services are singleton, we provide this service in 'root' because we want it to be available for all who need access to the API. As you can see, we have Dependency Injections in similar way we had in ASP.NET Core, here we receive a HttpClient that can make a http request to an url and we do not have to worry about how it works, or even how to create it!... This is why I love inversion of control.

Lets continue with get one recipe base on its id:

  public async getById(id: number): Promise<RecipeDTO> {
    const res = await this.httpClient.get<any>(`${apiUrl}/recipe/${id}`).toPromise();
    return RecipeDTO.prepareFromJson(res);
  }

Again, method is async because it await for the http request before continue. As you can see, we don't return a RecipeDTO but a Promise, a Promise is Typescript (or javascript) way to tell that if you call getByid, you could get a result some time in the future. That is why we have to await for the http request, we force our asynchronous code to look like a synchronous one (executing line after line).

Lets make some changes so we can see results before continue with POST, PUT and DELETE.

We are going to create the recipes module for CRUD operations. Go to src/app folder and run:

ng g module recipe
ng g component recipe
ng g service recipe
touch recipe-routing.module.ts

What have we done?

We created a new module. Yes, we can work with plain components but this is a good way of keeping our application modular.
We created the recipe component (.ts .html and .scss)
We created a recipe service, like services in backend, it will help us resolve complicated thing related to recipes.
We created a routing module, every angular module need a routing module to define its routes. (We can write all routes in app-routing.module, but that is not SOLID).

Angular CLI does some work for us, for example if you open recipe.module.ts you will see that RecipeComponent it's alredy imported.

Open recipe-routing.module.ts and write:

import { NgModule } from '@angular/core';
import { Routes, RouterModule } from '@angular/router';
import { RecipeComponent } from './recipe.component';

const routes: Routes = [{
  path: '', component: RecipeComponent,
}
];

@NgModule({
  imports: [RouterModule.forChild(routes)],
  exports: [RouterModule]
})
export class RecipeRoutingModule { }

We are telling Angular routing that if the route is empty, it should load the RecipeComponent. Now we need to import this RoutingModule in RecipeModule, so open recipe.module.ts and write RecipeRoutingModule in imports array (don't forget to import it).

import { NgModule } from '@angular/core';
import { CommonModule } from '@angular/common';
import { RecipeRoutingModule } from './recipe-routing.module';
import { RecipeComponent } from './recipe.component';

@NgModule({
  declarations: [
    RecipeComponent
  ],
  imports: [
    CommonModule,
    RecipeRoutingModule,
  ]
})
export class RecipeModule { }

We don't want our components to interact directly with the backend services, we need an abstraction layer (think like this is database access layer and we need providers), there are many reasons for this, maybe we could replace the providers for a stub implementation if we are testing. Maybe backend its not ready and we are going to use in memory info.

This is why we created a RecipeService before. This service does not have too many lines but is importat, so let me show it before explain

import { Injectable } from '@angular/core';
import { RecipeBackendService } from '../shared/backend-services/recipe-backend.service';
import { Subject } from 'rxjs';
import { RecipeDTO } from '../shared/dtos/recipe.dto';

@Injectable({
  providedIn: 'root'
})
export class RecipeService {

  private recipes = new Subject<Array<RecipeDTO>>();

  get Recipes() { return this.recipes.asObservable(); }

  constructor(private recipeBackend: RecipeBackendService) { }

  public async getAllRecipes(): Promise<void> {
    const res = await this.recipeBackend.getAll();
    if (res) {
      this.recipes.next(res);
    }
  }

  public async getRecipe(id: number): Promise<RecipeDTO> {
    const res = await this.recipeBackend.getById(id);
    return res;
  }
}

First we have a recipes Subject.

Big parentheses open Subject are like an evolved Promise, a promise only execute once (with a .then() or await) and give a result but a Subject is more like a flow, it could emit values and anyone who know the subject could receive those values. This is a very basic and poor definition but the ¿beginners? in title is because I asume some basic knowledge, there are many greats articles in this community about promises, async, observables, etc. Big parentheses close

Then we have a getter of the subject as an observable, that is because we don't want anyone outside this service to change the recipes array (only receive).

We need to communicate with backed, so we receive an RecipeBackendService, do you notice how we simple don't care how this service work?. If you remember, the backend service need a httpClient, without IoC we would have had to do something like:

const httpClient = new HttpClient(...);
const serviceBackend = new RecipeBackendService(httpClient);

Before using the serviceBackend, moreover, who knows what that HttpClient constructor need... You have to admit that IoC is a great tool.

Finally we have two methods. getById only work as a middle ware, but getAllRecipes it's a little more interesting. First it get all the recipes from the backend service and after that it pass the array to the subject (that's what next does) so everyone subscribed to the Recipes observable will get the new array.

Now that we have our provider, we could show some data. First lets import bootstrap, there are many things to do this, but I like this: go to to styles.scss in root project folder (the root scss file in app) and paste

@import '~bootstrap/dist/css/bootstrap.min.css';

We use httpClient but we don't tell Angular, so we have to do that. Like this is a global service, we only have to declare it once, so open app.module and add HttpClientModule and RouterModule to imports.

import { BrowserModule } from '@angular/platform-browser';
import { NgModule } from '@angular/core';
import { AppComponent } from './app.component';
import { RouterModule } from '@angular/router';
import { AppRoutingModule } from './app-routing.module';
import { HttpClientModule } from '@angular/common/http';

@NgModule({
  declarations: [
    AppComponent,
  ],
  imports: [
    BrowserModule,
    RouterModule,
    AppRoutingModule,
    HttpClientModule
  ],
  providers: [],
  bootstrap: [AppComponent]
})
export class AppModule { }

We had to import RouterModule because we are going to do some routing in app component. Open app.component.html and replace the content with

<header>
  <nav class="navbar navbar-expand-md navbar-dark fixed-top bg-dark">
    <a class="navbar-brand" href="#">Recipes list</a>
  </nav>
</header>
<main role="main" class="container">
  <router-outlet></router-outlet>
</main>

We just defined a basic common structure with a navbar and a main container (in future tutorials we will refactor this). In main container we put a , here Angular will load modules defined as AppModule' child. Every module could have one (in a mamushka style) where it could load its own childs.

Now we have to modify app-routing.module.ts to indicate that Recipes is a child route.

import { NgModule } from '@angular/core';
import { Routes, RouterModule } from '@angular/router';

const routes: Routes = [
  { path: '', loadChildren: 'src/app/recipe/recipe.module#RecipeModule' }
];


@NgModule({
  imports: [RouterModule.forRoot(routes)],
  exports: [RouterModule]
})
export class AppRoutingModule { }

This is the root module so we import routes with .forRoot (because Mr Angular want it this way). We are telling that if route is empty, angular should load the RecipeModule. This is a lazy import, meaning that the module is not loaded until is required by a route navigation, this is very cool for performance, some projects could have hundreds of modules, imagine if you had to wait for all the screens to be loaded and you only want to navigate to your profile module (I'm talking to you php).

We are very close to see some results. Now open recipe.component.ts and write

import { Observable } from 'rxjs';
import { RecipeService } from './recipe.service';
import { RecipeDTO } from '../shared/dtos/recipe.dto';

@Component({
  selector: 'app-recipe',
  templateUrl: './recipe.component.html',
  styleUrls: ['./recipe.component.sass']
})
export class RecipeComponent implements OnInit {

  public recipes$: Observable<Array<RecipeDTO>>;

  constructor(private recipeService: RecipeService) {
    this.recipes$ = this.recipeService.Recipes;
  }

  ngOnInit() {
    this.recipeService.getAllRecipes();
  }

}

Okey, whats going on?. First we declare a public Observable, remember observable? if you don't, is like flow of data we can suscribe to receive information. Recipes is public because we are going to use it in html and typescript compiler will complain if we use a property in html that is not public in the component (if we compile in production mode).

Then in the constructor we get the recipe observable that we declare in the RecipeService (thanks to DI, we have no idea of how this work, we just got it). After, we call the getAllRecipes to update the data flow.

The last step is show the data. Modify recipe.component.html with:

<ng-container *ngIf="recipes$ | async as recipes; else loadingTemplate">
  <ng-container *ngIf="recipes.length > 0; else noDataTemplate">
    <ul class="list-group">
      <li class="list-group-item" *ngFor="let recipe of recipes">
        {{recipe.title}}
      </li>
    </ul>
  </ng-container>
  <ng-template #noDataTemplate>No data.</ng-template>
</ng-container>
<ng-template #loadingTemplate>Loading...</ng-template>

Here many things are happening. First we use ng-container to check if the recipe exist and if it has data. The great thing about ng-container is that it don't create any html tag. We could have used div, but not everything that works is correct.

The ng-templates are like html variable, so if there are some recipes, we show them but if there aren't, we show a no data message.

Finally we are going to see some meals!, first go to the backend project root folder and run:

dotnet run

Now run the Angular project, in root folder:

npm start

Go to localhost:4200 and TADA!:

Okey, lets call it a day. In order to make the POST and PUT we should create view models, that means refactor, that means next post in this tutorial series.

I'm Sebastian Larrieu, and I support women devs.

Sebastian Larrieu — Fri, 08 Mar 2019 01:26:16 +0000

I will advocate for gender equality by...

Giving collages the space they need whenever I noticed they are not receiving the attention and respect they deserve in any project I belong.

I hope to see my developer community...

Became the best possible place for oppressed genders to be part of.

My advice for fellow allies is...

Talk to another allies when they are doing something wrong. Stop giving women opinion about how they have to fight for their rights,just listen and be supporting... We need to understand that we have a secondary role in this fight and be ok with that...