signalr – Michał Sakwa – Blog programistyczny

SignalR w ASP.NET Core i Angular – implementacja po stronie klienta

20 maja 2017 Michał Sakwa 1 komentarz

Dzisiaj pora na kolejny post dotyczący wykorzystania SignalR w ASP.NET Core. Ostatnim razem pisałem o implementacji po stronie serwera, tym razem zajmiemy się klientem aplikacji z wykorzystaniem frameworka Angular. Poniżej zamieszam odnośniki do powiązanych postów.

Część pierwsza: SignalR w ASP.NET Core – instalacja i uruchomienie

Część druga: SignalR w ASP.NET Core i Angular – przykładowa implementacja

Połączenie z serwerem

Gdy pisałem o konfiguracji, podałem na przykładzie w jaki sposób możemy połączyć się z serwerem. W tym celu wykorzystałem tzw. resolver w Angularze. Działa on na takiej zasadzie, że zapytanie wykonane w nim wykonuje się przed załadowaniem naszego komponentu, czyli np. planszy do gry. Poniżej przedstawię trochę inny przykład, gdzie ręcznie wywołujemy funkcję odpowiedzialną za połączenie. Na początek dodajemy fabrykę, która potrafi utworzyć nam nowe połączenie.

//Connection factory
import { SignalR, ISignalRConnection } from '../../lib/ng2-signalr';
import { Injectable } from '@angular/core';

@Injectable()
export class SignalRConnectionFactory {

    constructor(private _signalR: SignalR) { }

    createConnection(): Promise<ISignalRConnection> {
        return this._signalR.connect();
    }
}

//Connection factory

import { SignalR, ISignalRConnection } from '../../lib/ng2-signalr';

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

@Injectable()

export class SignalRConnectionFactory {

constructor(private _signalR: SignalR) { }

createConnection(): Promise<ISignalRConnection> {

return this._signalR.connect();

}

Fabrykę wykorzystujemy tylko do nawiązania nowego połączenia. Jeżeli będę chciał wykorzystywać inne konfigurację niż standardowa, nie chcę dodawać tego kodu do klasy odpowiedzialnej za samo przetwarzanie komunikatów.

Dwustronna komunikacja

Następnie dodaję serwis, który będzie przetrzymywał otwarte połączenie z serwerem oraz rozsyłał komunikaty do komponentów w Angularze. Cały klient będzie miał tylko jedno otwarte połączenie, ponieważ otwarcie takiego połączenia jest czasochłonne. Dodatkowo nie ma sensu obciążać serwera wieloma połączeniami w ramach jednej aplikacji klienckiej. Poniżej przedstawiam taką klasę, która obsługuje dwa typy zdarzeń:

Połączenie klienta do serwera, inicjowane prze klienta
Zmiana drużyny która wykonuje ruch, inicjowane prze serwer

//Game hub
import { Injectable } from '@angular/core';
import { Observable } from 'rxjs/Observable';
import { SignalRConnectionFactory } from '../../core/signalr/signalr-connection.factory';
import { ISignalRConnection, BroadcastEventListener } from '../../lib/ng2-signalr';
import { TeamChanged } from "../game.models";

@Injectable()
export class GameHubService {

    private connection: ISignalRConnection;    
    private onSubscribed$: BroadcastEventListener<string>;
    private onTeamChanged$: BroadcastEventListener<TeamChanged>;

    constructor(private connectionFactory: SignalRConnectionFactory) { }

    connect() {
        return Observable
            .fromPromise(this.connectionFactory
                .createConnection())
            .map((connection) => {
                this.connection = connection;
                return true;
            });
    }

    public subscribeToGame(gameId: number) : Promise<string> {
        return this.connection
            .invoke("Subscribe", gameId);
    }

    public teamChanged(onTeamChanged: (args: TeamChanged) => void) {
        if (!this.onTeamChanged$)
            this.onTeamChanged$ = this.connection.listenFor('TeamChanged');

        this.onTeamChanged$.subscribe(onTeamChanged);
    }

    public subscribed(onSubscribed: (message: string) => void) {
        if (!this.onSubscribed$)
            this.onSubscribed$ = this.connection.listenFor('Subscribed');
        
        this.onSubscribed$.subscribe(onSubscribed);
    }

    disconnect() {
        if (this.onSubscribed$)
            this.onSubscribed$.unsubscribe();
    }
}

//Game hub

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

import { Observable } from 'rxjs/Observable';

import { SignalRConnectionFactory } from '../../core/signalr/signalr-connection.factory';

import { ISignalRConnection, BroadcastEventListener } from '../../lib/ng2-signalr';

import { TeamChanged } from "../game.models";

@Injectable()

export class GameHubService {

private connection: ISignalRConnection;

private onSubscribed$: BroadcastEventListener<string>;

private onTeamChanged$: BroadcastEventListener<TeamChanged>;

constructor(private connectionFactory: SignalRConnectionFactory) { }

connect() {

return Observable

.fromPromise(this.connectionFactory

.createConnection())

.map((connection) => {

this.connection = connection;

return true;

});

}

public subscribeToGame(gameId: number) : Promise<string> {

return this.connection

.invoke("Subscribe", gameId);

}

public teamChanged(onTeamChanged: (args: TeamChanged) => void) {

if (!this.onTeamChanged$)

this.onTeamChanged$ = this.connection.listenFor('TeamChanged');

this.onTeamChanged$.subscribe(onTeamChanged);

}

public subscribed(onSubscribed: (message: string) => void) {

if (!this.onSubscribed$)

this.onSubscribed$ = this.connection.listenFor('Subscribed');

this.onSubscribed$.subscribe(onSubscribed);

}

disconnect() {

if (this.onSubscribed$)

this.onSubscribed$.unsubscribe();

}

Posiada ona kilka funkcji, omówię krótko każdą z nich.

connect – odpowiada za nawiązanie połączenia w ramach klienta. Połączenie jest przechowywanie w hubie i dzielone pomiędzy wszystkie komponenty.
disconnect– analogicznie do funkcji powyżej, zamyka ono połączenie z serwerem.
subscribeToGame – zdarzenie inicjowane po stronie klienta. Za jej pomocą dołączamy do kanału obecnej gry, dzięki temu otrzymamy komunikaty powiązane z grą.
subscribed – zdarzenie inicjowane po tym, jak nowy klient zapisze się do naszej gry.
teamChanged – zdarzenie inicjowane po tym, gdy jedna z drużyn wykona ruch, który spowoduje zmianę kolejki na inną drużynę.

Wykorzystanie serwisu w aplikacji

Gdy mamy już gotowy serwis, możemy wykorzystać go w naszej aplikacji. Na początek w głównym komponencie gry wywołujemy połączenie z serwerem.

//Main game component.
private connectToGame(gameId: number) {
    this.gameHub.connect()
        .mergeMap(connected => {
            if (connected) {
                return this.gameHub
                    .subscribeToGame(gameId)
            }
            Observable.throw("Could not connect to game hub");
        })
        .mergeMap(connectionId => {
            return this.gameService
                .getGame(gameId);
        })
        .subscribe(result => {
            this.game = result;
            this.board.initialize(this.game);
            this.sideNav.initialize(this.game);
        });
}

//Main game component.

private connectToGame(gameId: number) {

this.gameHub.connect()

.mergeMap(connected => {

if (connected) {

return this.gameHub

.subscribeToGame(gameId)

}

Observable.throw("Could not connect to game hub");

})

.mergeMap(connectionId => {

return this.gameService

.getGame(gameId);

})

.subscribe(result => {

this.game = result;

this.board.initialize(this.game);

this.sideNav.initialize(this.game);

});

}

Dzięki jej wywołaniu kolejno:

nawiązujemy połączenie z serwerem
zapisujemy się do gry
ładujemy dane gry
inicjalizujemy komponenty

Przykładem komponentu wykorzystującego ten serwis może być menu boczne aplikacji. Z jego poziomu drużyna może pominąć kolejkę, co będzie skutkowało zmianą obecnie aktywnej drużyny. Dodatkowo, gdy nastąpi zmiana drużyny, będziemy mogli nasłuchiwać na takie zdarzenie i wyświetlić drużynę wykonującą obecnie ruch.

//Sidenav component
import { Component, Input } from '@angular/core';

import { GameHubService, GameService } from '../services/game-services.imports';
import { Game, TeamChanged } from '../game.models';

@Component({
    selector: 'game-sidenav',
    templateUrl: './game-sidenav.component.html',
    styleUrls: ['./game-sidenav.component.scss']
})
export class GameSidenavComponent {

    game: Game;

    constructor(private gameHub: GameHubService,
        private gameService: GameService) { }

    private skipRound() {
        this.gameService
            .skipRound(this.game.id);
    }

    onTeamChanged(event: TeamChanged) {
        console.log(`Team changed. New team: ${event.newTeamId}. Previous team: ${event.lastTeamId}.`);
    }

    initialize(game: Game) {
        this.game = game;
        this.gameHub.teamChanged(this.onTeamChanged);
    }
}

//Sidenav component

import { Component, Input } from '@angular/core';

import { GameHubService, GameService } from '../services/game-services.imports';

import { Game, TeamChanged } from '../game.models';

@Component({

selector: 'game-sidenav',

templateUrl: './game-sidenav.component.html',

styleUrls: ['./game-sidenav.component.scss']

})

export class GameSidenavComponent {

game: Game;

constructor(private gameHub: GameHubService,

private gameService: GameService) { }

private skipRound() {

this.gameService

.skipRound(this.game.id);

}

onTeamChanged(event: TeamChanged) {

console.log(`Team changed. New team: ${event.newTeamId}. Previous team: ${event.lastTeamId}.`);

}

initialize(game: Game) {

this.game = game;

this.gameHub.teamChanged(this.onTeamChanged);

}

Mamy tutaj trzy elementy na które należy zwrócić uwagę:

initialize – tutaj komponent zgłasza chęć otrzymywania komunikatów związanych ze zmianą aktywnej drużyny. teamChanged przyjmuje funkcję, która wykona się za każdym razem, gdy takie zdarzenie nastąpi.
onTeamChanged – wspomniana wyżej funkcja, która wykona się po wystąpieniu zdarzenia zmiany drużyny. Tutaj wyświetlony zostanie tylko komunikat w konsoli.
skipRound – pominięcie tury. Nie odwołujemy się tutaj bezpośrednio do SignalR’a, ale wykonujemy zwykłe zapytanie do serwera. On później roześle informacje o zmianie aktywnej drużyny

Podsumowanie

Wydaje mi się, że w tych trzech wpisach pokazałem, jak wykorzystać w naszej aplikacji bibliotekę SignalR i tworzyć aplikacje działające w czasie rzeczywistym. Zachęcam do wypróbowania jej we własnym zakresie. Jeżeli jednak miałbym być szczery, to na chwilę obecną proponuję wykorzystanie tej biblioteki w starszej wersji frameworka, chyba że tak jak ja chcecie po prostu pobawić się z nowszą wersją frameworka .NET. Co prawda, pojawił się już ASP.NET Core Preview 1, ale nie jest to wersja stabilna. Taka pojawi się dopiero pod koniec obecnego roku.

SignalR w ASP.NET Core i Angular – przykładowa implementacja

17 maja 201722 maja 2017 Michał Sakwa 1 komentarz

Niedawno opublikowałem wpis na temat instalacji biblioteki SignalR w projekcie ASP.NET Core z wykorzystaniem Angulara. Dzisiaj chciałem kontynuować ten temat na przykładzie z mojego projektu. Zademonstruję działającą implementację po stronie serwera.

Link do poprzedniego wpisu: SignalR w ASP.NET Core – instalacja i uruchomienie

Konfiguracji ciąg dalszy

Chociaż konfiguracja jaką podałem w ostatnim wpisie wystarczała do działania, w moim rozwiązaniu musiałem dodać jeszcze kilka ustawień. Na pierwszy ogień poszedł CamelCasePropertyNamesContractResolver, dobrze znany wszystkim, którzy tworzyli kiedyś API w Asp.Net. Dzięki niemu, obiekty zwracane są z API w notacji CamelCase. Jest to domyślne ustawienie w .NET Core, ale jako że my mamy podpiętą bibliotekę ze starszej wersji frameworka, musimy ustawić to ręcznie. Przykładowa implementacja poniżej.

using Microsoft.AspNet.SignalR;
using Microsoft.AspNet.SignalR.Infrastructure;
using Newtonsoft.Json;
using Newtonsoft.Json.Serialization;
using System;
using System.Reflection;

namespace WordHunt.WebAPI.Config
{
    public class SignalRContractResolver : IContractResolver
    {

        private readonly Assembly assembly;
        private readonly IContractResolver camelCaseContractResolver;
        private readonly IContractResolver defaultContractSerializer;

        public SignalRContractResolver()
        {
            defaultContractSerializer = new DefaultContractResolver();
            camelCaseContractResolver = new CamelCasePropertyNamesContractResolver();
            assembly = typeof(Connection).Assembly;
        }

        public JsonContract ResolveContract(Type type)
        {
            if (type.Assembly.Equals(assembly))
            {
                return defaultContractSerializer.ResolveContract(type);

            }

            return camelCaseContractResolver.ResolveContract(type);
        }

        public static void RegisterSerializer()
        {
            var settings = new JsonSerializerSettings 
                               { ContractResolver = new SignalRContractResolver() };
            var serializer = JsonSerializer.Create(settings);

            GlobalHost.DependencyResolver
                              .Register(typeof(JsonSerializer), () => serializer);
        }

    }
}

using Microsoft.AspNet.SignalR;

using Microsoft.AspNet.SignalR.Infrastructure;

using Newtonsoft.Json;

using Newtonsoft.Json.Serialization;

using System;

using System.Reflection;

namespace WordHunt.WebAPI.Config

{

public class SignalRContractResolver : IContractResolver

{

private readonly Assembly assembly;

private readonly IContractResolver camelCaseContractResolver;

private readonly IContractResolver defaultContractSerializer;

public SignalRContractResolver()

{

defaultContractSerializer = new DefaultContractResolver();

camelCaseContractResolver = new CamelCasePropertyNamesContractResolver();

assembly = typeof(Connection).Assembly;

}

public JsonContract ResolveContract(Type type)

{

if (type.Assembly.Equals(assembly))

{

return defaultContractSerializer.ResolveContract(type);

}

return camelCaseContractResolver.ResolveContract(type);

}

public static void RegisterSerializer()

{

var settings = new JsonSerializerSettings

{ ContractResolver = new SignalRContractResolver() };

var serializer = JsonSerializer.Create(settings);

GlobalHost.DependencyResolver

.Register(typeof(JsonSerializer), () => serializer);

}

Następnie rejestrujemy nasz serializator w pliku Startup.cs.

// Konfiguracja
public void ConfigureServices(IServiceCollection services)
{
    SignalRContractResolver.RegisterSerializer();
	...
}

// Konfiguracja

public void ConfigureServices(IServiceCollection services)

{

SignalRContractResolver.RegisterSerializer();

...

}

Rozsyłanie eventów z poziomu backendu aplikacji

Wysłanie zdarzenia z serwera może odbyć w dwóch przypadkach:

Bezpośrednio z naszej klasy, dziedziczącej po Hub, w momencie gdy klient wywołuje zdalną metodę na serwerze
Po wywołaniu zwykłej metody HTTP w API, pośrednio poprzez Hub

O ile w pierwszym przypadku jest to bardzo proste, to ten drugi wymaga dodatkowego nakładu pracy. Załóżmy że nasz Hub ma tylko jedną metodę.

using Microsoft.AspNet.SignalR;
using Microsoft.AspNet.SignalR.Hubs;
using WordHunt.Data.Events;

namespace WordHunt.WebAPI.Hubs
{    
    [HubName("broadcaster")]
    public class Broadcaster : Hub<IEventClient>, IEventServer
    {
        public string Subscribe(int gameId)
        {
            Groups.Add(Context.ConnectionId, gameId.ToString());

            return Context.ConnectionId;
        }
    }
}

using Microsoft.AspNet.SignalR;

using Microsoft.AspNet.SignalR.Hubs;

using WordHunt.Data.Events;

namespace WordHunt.WebAPI.Hubs

{

[HubName("broadcaster")]

public class Broadcaster : Hub<IEventClient>, IEventServer

{

public string Subscribe(int gameId)

{

Groups.Add(Context.ConnectionId, gameId.ToString());

return Context.ConnectionId;

}

Klient, w momencie gdy wywoła metodę Subscribe, zapisze się do grupy odpowiadającej identyfikatorowi gry. Zwrócone mu zostanie id jego połączenia. Wewnątrz klasy Broadcaster możemy wysłać zdarzenie o nowej subskrypcji do wszystkich klientów. Taki przykład podałem w poprzednim poście, dlatego tutaj to pomijam (nie jest to potrzebne w moim przypadku). Efekt który chcemy tutaj osiągnąć to wysłanie do każdego klienta informacje o tym, że gracz wykonał ruch. Jako przykład posłuży tutaj zakończenie tury przez gracza.

[Authorize]
[Route("api/game")]
public class GameModificationController : Controller
{
    private readonly ITokenUserContextProvider userProvider;
    private readonly IGameMoveManager gameMoveManager;

    public GameModificationController(ITokenUserContextProvider userProvider,
        IGameMoveManager gameMoveManager)
    {
        this.userProvider = userProvider;
        this.gameMoveManager = gameMoveManager;
    }

    [Authorize]
    [HttpGet("{gameId}/skipround")]
    public async Task<IActionResult> SkipRound(int gameId)
    {
        var currentUser = userProvider.GetContextUserInfo();

        var result = await gameMoveManager.SkipRound(gameId, currentUser.Id);

        return Ok(result);
    }
}

[Authorize]

[Route("api/game")]

public class GameModificationController : Controller

{

private readonly ITokenUserContextProvider userProvider;

private readonly IGameMoveManager gameMoveManager;

public GameModificationController(ITokenUserContextProvider userProvider,

IGameMoveManager gameMoveManager)

{

this.userProvider = userProvider;

this.gameMoveManager = gameMoveManager;

}

[Authorize]

[HttpGet("{gameId}/skipround")]

public async Task<IActionResult> SkipRound(int gameId)

{

var currentUser = userProvider.GetContextUserInfo();

var result = await gameMoveManager.SkipRound(gameId, currentUser.Id);

return Ok(result);

}

Podczas wywołania tej akcji kontrolera, wywołujemy metodę SkipRound. Wewnątrz niej, po tym jak nastąpi zmiana kolejki, chcielibyśmy poinformować wszystkich graczy o tym fakcie. Nasz Hub to nie jest zwykła klasa, którą można po prostu wstrzyknąć do naszych obiektów. W tym celu musimy odwołać się do klasy ConnectionManager dostarczonej przez SignalR.

using Microsoft.AspNet.SignalR;
using WordHunt.Data.Events;
using WordHunt.Games.Broadcaster;

namespace WordHunt.WebAPI.Hubs
{
    public class EventBroadcaster : IEventBroadcaster
    {
        public void TeamChanged(TeamChanged args)
        {
            HubContext.Clients.Group(args.GameId.ToString()).TeamChanged(args);
        }

        IHubContext<IEventClient> HubContext { get; } 
        = GlobalHost.ConnectionManager.GetHubContext<Broadcaster, IEventClient>();
    }
}

using Microsoft.AspNet.SignalR;

using WordHunt.Data.Events;

using WordHunt.Games.Broadcaster;

namespace WordHunt.WebAPI.Hubs

{

public class EventBroadcaster : IEventBroadcaster

{

public void TeamChanged(TeamChanged args)

{

HubContext.Clients.Group(args.GameId.ToString()).TeamChanged(args);

}

IHubContext<IEventClient> HubContext { get; }

= GlobalHost.ConnectionManager.GetHubContext<Broadcaster, IEventClient>();

}

Dodałem klasę EventBroadcaster, która będzie odpowiedzialna za przekazywanie informacji do klientów bezpośrednio z serwera. Posiada ona obiekt HubContext, który umożliwia takie działania. Dostępny jest po wywołaniu metody GlobalHost.ConnectionManager.GetHubContext. Ponieważ jej wywołanie jest dosyć czasochłonne, klasę EventBroadcaster rejestrujemy w systemie jako singleton.

public static IServiceCollection RegisterWebApiDependencies(this IServiceCollection services)
{
    ...
    services.AddSingleton<Games.Broadcaster.IEventBroadcaster, Hubs.EventBroadcaster>();
    ...
}

public static IServiceCollection RegisterWebApiDependencies(this IServiceCollection services)

{

...

services.AddSingleton<Games.Broadcaster.IEventBroadcaster, Hubs.EventBroadcaster>();

...

}

Dzięki temu, w dowolne miejsce aplikacji możemy dodać obiekt implementujący IEventBroadcaster i wysyłać do klientów interesujące nas zdarzenia. Przykład poniżej.

//Moves 
public class GameMoveManager : IGameMoveManager
{
    // Other dependencies ...
    private readonly IEventBroadcaster eventBroadcaster;

    public GameMoveManager(
	...
	IEventBroadcaster eventBroadcaster)
    {
        this.eventBroadcaster = eventBroadcaster;
    }

    public async Task<TeamChanged> SkipRound(int gameId, int userId)
    {
		//Game logic...

        eventBroadcaster.TeamChanged(teamChanged);

        return teamChanged;
    }
}

//Moves

public class GameMoveManager : IGameMoveManager

{

// Other dependencies ...

private readonly IEventBroadcaster eventBroadcaster;

public GameMoveManager(

...

IEventBroadcaster eventBroadcaster)

{

this.eventBroadcaster = eventBroadcaster;

}

public async Task<TeamChanged> SkipRound(int gameId, int userId)

{

//Game logic...

eventBroadcaster.TeamChanged(teamChanged);

return teamChanged;

}

Podsumowanie

Dzisiaj zademonstrowałem przykładową implementację rozsyłania zdarzeń w aplikacji po stronie serwera aplikacji. W kolejnym wpisie zajmiemy się implementacją po stronie klienta w Angularze. Dzięki za uwagę i zapraszam ponownie!

Co nowego w projekcie – aktualizacja

12 maja 201712 maja 2017 Michał Sakwa Zostaw komentarz

Od ostatniej aktualizacji minęły prawie dwa tygodnie, więc pora na krótkie podsumowanie tego, co udało mi się zrobić przez ten czas. Niestety dla projektu, przez dwa ostatnie weekendy byłem poza domem, więc nie wszystko co sobie zaplanowałem zostało zrealizowane. Jakieś postępy jednak są, dlatego zapraszam do lektury!

post-background

Exception handling w WebAPI

Przechwytywanie błędów to było coś, co mi się nie podobało w moim rozwiązaniu. Wiadomo, na początku nie było to istotne, ale w miarę jak ilość elementów aplikacji rosła, trzeba było pomyśleć nad czymś sensownym. Domyślnie, gdy w aplikacji pojawiał się błąd, wyświetlana była strona z jego treścią, standardowe zachowanie. Jako, że w API nie jest to pożądane, dodałem do aplikacji middleware który przechwytuje wszystkie wyjątki. W ten sposób nie trzeba się bawić w przekazywanie statusów z metod domeny do kontrolera – gdy trzeba rzucamy wyjątek odpowiedniego typu, a resztą zajmie się właśnie ten fragment kodu.

// Exception handling
public class ExceptionHandlingMiddleware
{
    private readonly RequestDelegate next;

    public ExceptionHandlingMiddleware(RequestDelegate next)
    {
        this.next = next;
    }

    public async Task Invoke(HttpContext context)
    {
        try
        {
            await next(context);
        }
        catch (Exception ex)
        {
            await HandleExceptionAsync(context, ex);
        }
    }

    private static Task HandleExceptionAsync(HttpContext context, 
                                                  Exception exception)
    {
        // 500 if unexpected
        var code = HttpStatusCode.InternalServerError; 

        if (exception is ArgumentException)
            code = HttpStatusCode.BadRequest;

        var result = JsonConvert
                       .SerializeObject(new { error = exception.Message });
        context.Response.ContentType = "application/json";
        context.Response.StatusCode = (int)code;
        return context.Response.WriteAsync(result);
    }
}

// Exception handling

public class ExceptionHandlingMiddleware

{

private readonly RequestDelegate next;

public ExceptionHandlingMiddleware(RequestDelegate next)

{

this.next = next;

}

public async Task Invoke(HttpContext context)

{

try

{

await next(context);

}

catch (Exception ex)

{

await HandleExceptionAsync(context, ex);

}

private static Task HandleExceptionAsync(HttpContext context,

Exception exception)

{

// 500 if unexpected

var code = HttpStatusCode.InternalServerError;

if (exception is ArgumentException)

code = HttpStatusCode.BadRequest;

var result = JsonConvert

.SerializeObject(new { error = exception.Message });

context.Response.ContentType = "application/json";

context.Response.StatusCode = (int)code;

return context.Response.WriteAsync(result);

}

Teraz tylko dodajemy tą klasę do pipeline w ASP poprzez metodę UseMiddleware<ExceptionHandlingMiddleware>() i gotowe. Wszystkie wyjątki zostaną przechwycone i zwrócone do klienta. W zależności od rodzaju wyjątku, zwrócony zostanie inny status błędu.

// Register middleware
public void Configure(IApplicationBuilder app,
    IHostingEnvironment env,
    ILoggerFactory loggerFactory,
    IDBInitializer initializer,
    IAuthConfiguration authConfig)
{
    loggerFactory.AddConsole(configuration.GetSection("Logging"));
    loggerFactory.AddDebug();

    app.UseCorsConfig(env)
        .UseIdentity()
        .UseJwtBearerTokenAuthentication(authConfig)
        .UseMiddleware<ExceptionHandlingMiddleware>()
        .UseSignalR2()
        .UseMvc()
        .UseSwagger()
        .UseSwaggerUI(s => 
           s.SwaggerEndpoint("/swagger/v1/swagger.json", "WordHunt WebAPI"));

    initializer.InitDatabase().Wait();
}

// Register middleware

public void Configure(IApplicationBuilder app,

IHostingEnvironment env,

ILoggerFactory loggerFactory,

IDBInitializer initializer,

IAuthConfiguration authConfig)

{

loggerFactory.AddConsole(configuration.GetSection("Logging"));

loggerFactory.AddDebug();

app.UseCorsConfig(env)

.UseIdentity()

.UseJwtBearerTokenAuthentication(authConfig)

.UseMiddleware<ExceptionHandlingMiddleware>()

.UseSignalR2()

.UseMvc()

.UseSwagger()

.UseSwaggerUI(s =>

s.SwaggerEndpoint("/swagger/v1/swagger.json", "WordHunt WebAPI"));

initializer.InitDatabase().Wait();

}

Obsługa SignalR

Mój poprzedni post jest w całości poświęcony tej tematyce, a w szczególności wspominam tam o wszystkich problemach jakie mnie spotkały podczas dodawania tej biblioteki. Warto jednak o tym tutaj wspomnieć. Dzięki temu moja aplikacja będzie mogła działać w czasie rzeczywistym, rozsyłając komunikaty pomiędzy wszystkich klientów. O tym, jak dokładnie zostało to zaimplementowane po stronie klienta i serwera opowiem w kolejnych postach.

Praca nad widokiem aplikacji

W miarę jak dodaje kolejne elementy, powoli buduje interfejs użytkownika. Na razie ten element wyraźnie kuleje, ale nie jest to najistotniejsze w tym momencie. Wygląd na tą chwilę nie jest istotny, ważne żeby dokładać kolejne elementy funkcjonalne. Obecnie pracuje nad planszą do gry. Jest to dosyć problematyczne zadanie, ponieważ staram się żeby była możliwość gry na tabletach i smartfonach. Ciężko pomieścić tak wiele pól na małych ekranach tak, żeby były one czytelne. Do tego CSSy to nie jest moja mocna strona… Na razie poprawki tego fragmentu zostawiam na później. Nie będę się także chwalił obecnym wyglądem aplikacji, myślę że w przyszłym tygodniu coś już pokażę.

Dalsza praca z Dapperem

Tej technologii też poświęciłem już cały wpis, ale chciałem pokazać kolejną metodę którą udostępnia. Jest to QueryMultipleAsync. Tak bardzo mi się to spodobało, że postanowiłem o tym tutaj wspomnieć. Po wejściu na planszę klient chce pobrać informacje o obecnej grze: pola, status, drużyny etc. W tym celu odpytuje API. Zamiast wielu zapytań do bazy danych, całą tą operację da się zrobić w jednym zapytaniu. Można by to wydzielić na wiele mniejszych zapytań, ale stwierdziłem że to dobry moment na wykorzystanie tej metody. Poniżej implementacja.

//Get game info
public async Task<Models.Games.Access.Game> GetCompleteGameInfo(int gameId)
{
    using (var connection = connectionFactory.CreateConnection())
    {
        StringBuilder query = new StringBuilder();
        query.AppendLine(AccessQueries.GetGameQuery);
        query.AppendLine(AccessQueries.GetGameFieldsQuery);
        query.AppendLine(AccessQueries.GetGameTeamsQuery);
        using (var multiQuery = await connection.QueryMultipleAsync(query.ToString(), new { GameId = gameId }))
        {
            var game = await multiQuery.ReadFirstAsync<Models.Games.Access.Game>();
            game.Fields = await multiQuery.ReadAsync<Models.Games.Access.Field>();
            game.Teams = await multiQuery.ReadAsync<Models.Games.Access.Team>();

            return game;
        }
    }
}

//Get game info

public async Task<Models.Games.Access.Game> GetCompleteGameInfo(int gameId)

{

using (var connection = connectionFactory.CreateConnection())

{

StringBuilder query = new StringBuilder();

query.AppendLine(AccessQueries.GetGameQuery);

query.AppendLine(AccessQueries.GetGameFieldsQuery);

query.AppendLine(AccessQueries.GetGameTeamsQuery);

using (var multiQuery = await connection.QueryMultipleAsync(query.ToString(), new { GameId = gameId }))

{

var game = await multiQuery.ReadFirstAsync<Models.Games.Access.Game>();

game.Fields = await multiQuery.ReadAsync<Models.Games.Access.Field>();

game.Teams = await multiQuery.ReadAsync<Models.Games.Access.Team>();

return game;

}

AccessQueries w powyższym przykładzie to po prostu treści zapytań SQL. Z wielu małych zapytań generowane jest jedno wielkie. Wyniki są mapowane do poszczególnych elementów obiektu Game. W SQL Server Profilerze wyraźnie widać, wszystko wykonane w jednej operacji, bardzo miła sprawa.

Sql Server Profiler - wynik zapytania QueryMultipleAsync

Zrzut ekranu z SQL Server Profiler

Podsumowanie

Podkręciłem ostatnio tempo pracy nad projektem, dodatkowo zapowiada mi się pierwszy wolny weekend w tym miesiącu, dlatego mam spore oczekiwania względem tego, co uda mi się zrobić w najbliższych dniach! Stay tuned!

SignalR w ASP.NET Core – instalacja i uruchomienie

6 maja 201722 maja 2017 Michał Sakwa 6 komentarzy

Dzisiaj chciałem podzielić się moimi doświadczeniami z użyciem biblioteki SignalR w projekcie .NET Core. Co prawda, nie mam jeszcze za dużo przykładów użycia w projekcie, ponieważ dopiero udało mi się zmusić ją do działania. Wydaje mi się jednak, że to co tutaj opiszę przyda się komuś, jeżeli napotka na podobne problemy co ja.

signalr sign and pretty tree

Co to jest SignalR?

SignalR to biblioteka pozwalająca na tworzenie aplikacji aktualizujących dane w czasie rzeczywistym. Co to znaczy? W standardowym scenariuszu, po uruchomieniu strony czy aplikacji pobierane są dane. Jeżeli chcemy je odświeżyć, musimy przeładować stronę lub wywołać jakąś akcję która odświeży dane (np. ponowne przefiltrowanie listy). W taki czy inny sposób wysyłamy żądanie na serwer i otrzymujemy od niego odpowiedź. Tutaj mamy do czynienia z czymś innym. To serwer informuje klienta o tym, że dane zostały zmienione. Dzięki temu natychmiast możemy mieć dostęp do interesujących nas informacji. W tym celu stosowane jest na przykład API WebSockets, czyli komunikacja dwukierunkowa klient-serwer. Do naszej dyspozycji jest także HTML5 Server-Sent Events. Tutaj komunikacja jest tylko jednokierunkowa, z serwera do klienta. Bywa jednak, że przeglądarki nie wspierają obu tych rozwiązań. Wtedy z pomocą przychodzi SignalR. Korzystając z niego nie interesuje nas w jaki sposób przebiegać będzie komunikacja, framework zajmie się tym za nas. Jeżeli tak jak wspomniałem przed chwilą, przeglądarka nie dostarcza nam tych rozwiązań, wykonane zostaną po prostu zwykłe zapytania. Ale to już jest dla programisty mało ważne, stanie się to automatycznie. To tyle w skrócie, nie są to technologie nowe, dlatego po więcej szczegółów zachęcam do dalszej lektury we własnym zakresie.

SignalR w .NET Core

Na początek pokaże, co zrobić żeby wszystko ładnie działało po stronie API naszej aplikacji. Największym problemem na jaki napotkałem był brak implementacji biblioteki pod .NET Core. Jest ona jeszcze w przygotowaniu, i żeby mieć tą wersję, trzeba ją pobrać ze specjalnego źródła, gdzie wrzucane są wersje dopiero rozwijane. Stwierdziłem, że nie będę się katował wersjami testowymi tej technologi. Sami autorzy tego nie zalecają. Do tego musiałbym podnieść wersję samego .NET Core, a tego nie chciałem robić. Wystarczą mi problemy, które mam z wersją stabilną… Jako, że byłem zmotywowany do użycia tej technologi i nie chciałem po prostu odpytywać serwera co chwilę o to, czy pozostali gracze nie wykonali ruchu, znalazłem inne rozwiązanie. Postanowiłem, że użyję frameworka .NET w wersji 4.6.2. Nie wiązało się to z przepisywaniem aplikacji od nowa. Moja aplikacja dalej pisana jest w .NET Core, ale mam możliwość korzystania ze sprawdzonych bibliotek poprzedniej wersji .NET. Wystarczy zmienić trochę plik .csproj naszej aplikacji.

//CSPROJ

<PropertyGroup>
  <TargetFramework>net462</TargetFramework>  
  <!-- <TargetFramework>netcoreapp1.1</TargetFramework> -->
</PropertyGroup>

//CSPROJ

</PropertyGroup>

Zamiast netcoreapp1.1, jako TargetFramework podajemy net462. Reszta aplikacji pozostaje w zasadzie bez zmian. Dzięki temu, dalej korzystamy z nowego .NET Core, ale możemy dodać zależności do sprawdzonego Microsoft.AspNet.SignalR.Core. W ten sposób omijamy pierwszą przeszkodę, czyli wersję biblioteki. To jednak nie wszystko.
Żeby móc podpiąć SignalR do pipeline’u naszej aplikacji, musimy dodać następujące extension methods.

//IApplicationBuilder extensions

public static IApplicationBuilder UseAppBuilder(this IApplicationBuilder app, Action<IAppBuilder> configure)
{
    app.UseOwin(addToPipeline =>
    {
        addToPipeline(next =>
        {
            var appBuilder = new AppBuilder();
            appBuilder.Properties["builder.DefaultApp"] = next;

            configure(appBuilder);

            return appBuilder.Build<AppFunc>();
        });
    });

    return app;
}

public static IApplicationBuilder UseSignalR2(this IApplicationBuilder app)
{
    app.UseAppBuilder(appBuilder => 
    {
        appBuilder.UseAesDataProtectorProvider();
        appBuilder.MapSignalR("/api/signalr", new Microsoft.AspNet.SignalR.HubConfiguration());
    });

    return app;
}

//IApplicationBuilder extensions

public static IApplicationBuilder UseAppBuilder(this IApplicationBuilder app, Action<IAppBuilder> configure)

{

app.UseOwin(addToPipeline =>

{

addToPipeline(next =>

{

var appBuilder = new AppBuilder();

appBuilder.Properties["builder.DefaultApp"] = next;

configure(appBuilder);

return appBuilder.Build<AppFunc>();

});

return app;

}

public static IApplicationBuilder UseSignalR2(this IApplicationBuilder app)

{

app.UseAppBuilder(appBuilder =>

{

appBuilder.UseAesDataProtectorProvider();

appBuilder.MapSignalR("/api/signalr", new Microsoft.AspNet.SignalR.HubConfiguration());

});

return app;

}

Kluczowe tutaj było dodanie do pipeline UseAesDataProtectorProvider. Bez tego, SignalR działał lokalnie, ale już w środowisku produkcyjnym nie chciał nawiązać połączenia. Objawiało się to błędem Error during negotiation request.... Po wykonaniu tych czynności możemy dodać SignalR do naszej aplikacji!

//Configure in Startup.cs
app.UseCorsConfig(env)
  .UseIdentity()
  .UseJwtBearerTokenAuthentication(authConfig)
  .UseMiddleware<ExceptionHandlingMiddleware>()
  .UseSignalR2()
  .UseMvc();

//Configure in Startup.cs

app.UseCorsConfig(env)

.UseIdentity()

.UseJwtBearerTokenAuthentication(authConfig)

.UseMiddleware<ExceptionHandlingMiddleware>()

.UseSignalR2()

.UseMvc();

A poniżej pierwszy Hub, którym testowałem, czy komunikacja działa. Nie robi nic innego, niż tylko przekazanie wszystkim połączonym klientom otrzymanej wiadomości.

//SignalR Hub
public interface IBroadcaster
{
    void HandleMessage(string message);
}

[HubName("broadcaster")]
public class Broadcaster : Hub<IBroadcaster>
{
    public void HandleMessage(string message)
    {

        Clients.All.HandleMessage("Joined: " + message);
    }
}

//SignalR Hub

public interface IBroadcaster

{

void HandleMessage(string message);

}

[HubName("broadcaster")]

public class Broadcaster : Hub<IBroadcaster>

{

public void HandleMessage(string message)

{

Clients.All.HandleMessage("Joined: " + message);

}

SignalR w Angular

Kolejne problemy, na szczęście mniejsze, pojawiły się po stronie frontendu aplikacji. Jak zwykle jakąś rolę odegrał tutaj Webpack, ale do tego już się przyzwyczaiłem. Do komunikacji z serwerem użyłem biblioteki ng2-signalr, która dostarcza implementacje pod Angulara. Problem polegał na tym, że nie widziała ona dodanych do projektu bibliotek jQuery oraz signalr, które są konieczne do jej działania. Do obejścia tego problemu w pliku webpack.config.js należało dodać nowy plugin, który automatycznie ładuje moduły do wybranego identyfikatora. Dodatkowo w app.module.ts należało dodać importy tych bibliotek. Dzięki temu problem zniknął.

//plugin
...
plugins: [...,
new webpack.ProvidePlugin({ jQuery: 'jquery', $: 'jquery', jquery: 'jquery' })]
...
//app.module.ts
...
import 'expose-loader?jQuery!jquery';
import 'signalr';
...

//plugin

...

plugins: [...,

new webpack.ProvidePlugin({ jQuery: 'jquery', $: 'jquery', jquery: 'jquery' })]

...

//app.module.ts

...

import 'expose-loader?jQuery!jquery';

import 'signalr';

...

Teraz można przejść do właściwej implementacji naszego rozwiązania. Dodajemy resolver połączenia do SignalR, który już na starcie komponentu zwraca nam obiekt połączenia. W obecnej implementacji, zawsze łączy się do tego samego Huba.

//signalr-connection.resolver.ts
import { Resolve } from '@angular/router';
import { SignalR, SignalRConnection } from 'ng2-signalr';
import { Injectable } from '@angular/core';

@Injectable()
export class SignalRConnectionResolver implements Resolve<SignalRConnection> {

    constructor(private _signalR: SignalR) { }

    resolve() {
        console.log('ConnectionResolver. Resolving...');
        return this._signalR.connect();
    }
}

//signalr-connection.resolver.ts

import { Resolve } from '@angular/router';

import { SignalR, SignalRConnection } from 'ng2-signalr';

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

@Injectable()

export class SignalRConnectionResolver implements Resolve<SignalRConnection> {

constructor(private _signalR: SignalR) { }

resolve() {

console.log('ConnectionResolver. Resolving...');

return this._signalR.connect();

}

Połączenie tworzone jest na podstawie domyślnej konfiguracji, która jest podawana podczas deklaracji modułu SingalR. Oto implementacja funkcji, podającej domyślną konfigurację.

//signalr.config.ts
import { isDevMode } from '@angular/core';

import { DevConfig, ProdConfig } from './app.config';
import { IConfig } from './app.iconfig';
import { SignalRConfiguration } from 'ng2-signalr';

export function CreateSignalRConfig() {

    let signalrConfiguration: SignalRConfiguration = new SignalRConfiguration();
    signalrConfiguration.hubName = "broadcaster";

    var cfg: IConfig;
    if (isDevMode()) {
        cfg = new DevConfig();
        signalrConfiguration.logging = true;
    }
    else {
        cfg = new ProdConfig();
        signalrConfiguration.logging = false;
    }

    signalrConfiguration.url = cfg.API_URL + 'signalr';
    
    return signalrConfiguration;
}

//signalr.config.ts

import { isDevMode } from '@angular/core';

import { DevConfig, ProdConfig } from './app.config';

import { IConfig } from './app.iconfig';

import { SignalRConfiguration } from 'ng2-signalr';

export function CreateSignalRConfig() {

let signalrConfiguration: SignalRConfiguration = new SignalRConfiguration();

signalrConfiguration.hubName = "broadcaster";

var cfg: IConfig;

if (isDevMode()) {

cfg = new DevConfig();

signalrConfiguration.logging = true;

}

else {

cfg = new ProdConfig();

signalrConfiguration.logging = false;

}

signalrConfiguration.url = cfg.API_URL + 'signalr';

return signalrConfiguration;

}

Korzystam z tego samego mechanizmu, który wykorzystałem do konfiguracji całej aplikacji. Inne połączenie stosowane jest lokalnie, a inne na serwerze. Taką domyślną konfigurację przekazujemy w pliku app.module.ts.

//app.module.ts signalr config
...
import { CreateSignalRConfig } from './config/signalr.config';
import { SignalRModule, SignalRConfiguration } from 'ng2-signalr';

@NgModule({
    imports: [
...
        SignalRModule.forRoot(CreateSignalRConfig)
    ],
...
})
export class AppModule {
}

//app.module.ts signalr config

...

import { CreateSignalRConfig } from './config/signalr.config';

import { SignalRModule, SignalRConfiguration } from 'ng2-signalr';

@NgModule({

imports: [

...

SignalRModule.forRoot(CreateSignalRConfig)

...

})

export class AppModule {

}

Do funkcji connect obiektu SingalR w naszym resolverze możemy przekazać dodatkowe opcje, które nadpiszą te domyślne. W ten sposób możemy przekazać na przykład tylko nazwę Huba, do którego chcemy się połączyć. Serwer pobrany zostanie wtedy z domyślnej konfiguracji, jest to bardzo wygodne. W samym komponencie możemy teraz dostać obiekt połączenia do serwera w funkcji ngOnInit, o ile w deklaracji routingu dodaliśmy resolve przy pomocy wcześniej zaimplementowanego resolvera.

//App.routing.module.ts
...
{
 path: 'game/:id',
 loadChildren: './game/game.module#GameModule',
 canActivate: [AuthGuard],
 resolve: { connection: SignalRConnectionResolver }
}
...

//Component in Angular
connection: ISignalRConnection;

ngOnInit() {
 this.connection = this.route.snapshot.data['connection'];
}

//App.routing.module.ts

...

{

path: 'game/:id',

loadChildren: './game/game.module#GameModule',

canActivate: [AuthGuard],

resolve: { connection: SignalRConnectionResolver }

}

...

//Component in Angular

connection: ISignalRConnection;

ngOnInit() {

this.connection = this.route.snapshot.data['connection'];

}

Podsumowanie

Na tą chwilę w aplikacji udało mi się zrobić tylko tyle w kwestii SignalR’a. Teraz mogę przejść do konkretnej implementacji mojego rozwiązania. Na pewno w kolejnych postach podzielę się jak ona wygląda.