Forem: Nicolai Ringbæk

Creating a chatroom using WebSockets and SignalR

Nicolai Ringbæk — Fri, 22 May 2020 12:50:25 +0000

Since WebAssembly/WASM has finally gotten past the 1.0 milestone including official support in the most common browsers, it's time to take a quick dive into the world of interactive and real-time browser applications. To be more specific, one of the enabling web technologies that I think will impact the WASM based applications -> Web Sockets.

Some of the common use-cases where websockets are being used today includes live-tracking services for things like stock tickers and cloud server loads. With the addition of WASM to the browsers toolbox, we can expect performance- and graphically heavy web applications, for example online games directly in the browser. A perfect use-case for websockets enabling the underlying networking needs.

Why SignalR?

SignalR is built for real-time, 2-way communication and is backed by web sockets. It's possible to implement web sockets without, but by using SignalR, we gain some nice benefits out of the box.

Usually scaling can be a trouble with websockets since it requires much more than simple tcp requests. Cloud providers like Azure offers dedicated instances designed for SignalR applications. In addition to this, the load can be spread over multiple instances using caching layers, which gives a shared knowledge between all application instances of all the connected clients.

Another great benefit is the built-in client connection handling (and fallback to old-school polling, in case web sockets are not supported by the client browser) and the custom SignalR message protocol. Out of the box, web sockets simply sends a message to the server and that's it. SignalR enables the developer to write custom event-based handling by defining methods on both the server and client. These can then be invoked directly when interacting with the SignalR connection. This is a great addition to reduce initial development time and speeding up the process of creating prototypes!

The application

Backend / .NET Core

Enabling SignalR is easy. In fact, the SignalR package is included by default in newer versions of .ASPNET Core. To enable SignalR, the services needs to be registered and the hub endpoint defined. The SignalR hub is then the "interface" used when the server receives messages from the clients.

public void ConfigureServices(IServiceCollection services)
{
        // ...

    services.AddSignalR();
}

public void Configure(IApplicationBuilder app)
{
        // ...

    app.UseEndpoints(endpoints =>
    {
        endpoints.MapRazorPages();
        endpoints.MapHub<ChatHub>("/_ws/chat");
    });
}

For the hub itself, we've overridden the Connected and Disconnected events for clients. The client connection state is handled by SignalR, including the possibility to add reconnection logic out of the box.

We've added a method named Send. Whenever a client wishes to send a new message to our server, they simply call invoke on the current connection and pass the name of the given event - in this case, send, which looks like connection.invoke('send', username, messageInput.value);. The arguments for the Send-method is likewise passed down as arguments for the Hub Send method.

public class ChatHub : Hub
{
    public override async Task OnConnectedAsync()
    {
        var name = Context.GetHttpContext().Request.Query["name"];
        await Clients.All.SendAsync("user.connected", name, Context.ConnectionId);
    }

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

    public async Task Send(string name, string message)
    {
        await Clients.All.SendAsync("message.received", name, message);
    }
}

Frontend / JavaScript

The frontend client uses the SignalR JavaScript library @microsoft/signalr. Add it as a reference and it's ready to go.

For our frontend, a simple UI has been created which contains a list of connected users, a box for all received messages and an input field to type and send the messages. The enabling JavaScript behind sets up our chatroom by creating a SignalR connection to our server at the specified hub endpoint.

The method connection.on(...) sets up our supported events for which the client will react to when a message is received. This definition of named events is a part of the SignalR layer that sits on top of web sockets.

document.addEventListener('DOMContentLoaded', function () {
    var username = 'person_' + Math.floor((Math.random() * 1000) + 1);

    function sendMessage(event) {
        var messageInput = document.getElementById('sendInput');
        connection.invoke('send', username, messageInput.value);
        messageInput.value = '';
        messageInput.focus();
        event.preventDefault();
    }

    var connection = new signalR.HubConnectionBuilder()
        .withUrl('/_ws/chat?name=' + username)
        .build();

    connection.start()
        .then(function () {
            document.getElementById('sendBtn').addEventListener('click', sendMessage);
        })
        .catch(error => {
            console.error(error.message);
        });

    connection.on('user.connected', function (name, id) {
        var usersElement = document.getElementById('connectedUsers');
        var newUserElement = document.createElement('li');
        newUserElement.id = id;
        newUserElement.innerHTML = name;

        usersElement.appendChild(newUserElement);
    });

    connection.on('user.disconnected', function (id) {
        document.getElementById(id).remove();
    });

    connection.on('message.received', function (name, message) {
        var messageElement = document.createElement('article');
        var content = '<p><strong>' + name + '</strong><br>' + message + '</p>';

        messageElement.classList.add("media");
        messageElement.innerHTML = '<figure class="media-left"><p class="image is-64x64"><img src="/media/placeholder.png"></p></figure><div class="media-content"><div class="content messageContent">' + content + '</div></div>';

        document.getElementById('messages').appendChild(messageElement);
    });
});

In action

When ws request is initiated by the browser/client, it creates an upgrade request with the expectation of the server to accept and open a socket.

When accepted and connected, Chrome keeps track on received messages. Normal requests would simply contain a response, but web sockets are different. This flow contains 2 clients connecting and sending messages to each other. This also gives insight into how SignalR handles messages between the server and client.

Localization in Angular with DevOps and Crowdin

Nicolai Ringbæk — Fri, 24 Apr 2020 10:37:47 +0000

It's not uncommon for projects to require localization at some point. Setting up and using localization over time, including translation management, can become a tedious and time-consuming task if not done properly.

This post will dig into the localization setup needed for Angular and how to integrate Crowdin and DevOps to automate as many boring tasks as possible.

DevOps is Microsofts DevOps services
Crowdin is an online localization tool to manage translations

The POC project

The project we want to enable localization for, is a simple Angular 9.1 solution. It contains one component with some sample text.

The gist of enabling localization in Angular is to ng add @angular/localize and utilize the i18n-tag. This enables the Angular tooling to extract and create translation source files.

The angular.json-file can then be extended for our project to include our localization setup regarding what locales that should be supported. In combination with this, we can add two npm tasks to simply localization support.

"i18n": {
    "sourceLocale": "en-US",
    "locales": {
      "da": "src/locale/da/messages.xlf"
    }
  }

"scripts": {
  "ng": "ng",
  "build": "ng build --prod --localize",
  "localize": "ng xi18n --output-path src/locale"
}

The localize tasks builds and extracts any strings in our application that supports localization using the Angular CLI command xi18n. It uses our setup from our angular.json-file. In this case, it extracts text with the expectation of it being en-US and places it in the file src/locale/messages.xlf.

The build command with the --locale argument builds our application and outputs a compiled application for each locale defined. Metadata such as the <base>-tag and i18nLocale is automatically applied, which reduces the need to create customized build configurations for each supported locale in most cases - required in previous Angular versions.

Crowdin integration

The setup for Crowdin is somewhat straight forward. Within integrations, we can enable Azure Repos and setup our branch target and configuration. This creates a crowdin.yml-file in our repository with the given translation targets.

files:
  - source: /src/src/locale/messages.xlf
    translation: /src/src/locale/%two_letters_code%/%original_file_name%

At this point, our strings is now ready to be translated in the Crowdin portal.

Crowdin automatically detects when new translations has been created. It then creates a pull-request with the updated translations ready to be merged.

The result

Our translation is handled by Crowdin and automatic synchronization has been enabled between our repository and Crowdin. To serve our different locales locally, we need to add locale-specific configuration targets in our angular.json-file.

"build": {
  "configurations": {
    "da": {
      "localize": ["da"]
    }
  }
},
"serve": {
  "configurations": {
    "da": {
      "browserTarget": "loca:build:da"
    }
  }
}

We can now start a local instance of our application. The -c argument specifies our target configuration. Our port defaults to 4200 for our setup, so to run multiple instances, we need to specify a free port.

ng serve -c=da
ng serve --port=4201

Future of Angular localization

A much wanted feature for Angular is to add native support for localization in component/TS code. We're getting closer and closer. According to an issue on GitHub, the support can be expected to land with the release of Angular 10... Fingers crossed - until then, we can add our translation definitions in template code using the i18n-tag and apply the same id across to map at compile-time.

The syntax will utilize the $localize command. Support for the command itself is already added with the ng add @angular/localize import.

This boils down to a syntax looking like the following with the i18n ID explicitly defined.

title = $localize`:@@title:Localization demo`;

Kickstarting DevOps pipelines

Nicolai Ringbæk — Fri, 20 Mar 2020 10:04:00 +0000

So, Azure DevOps... during these hard times with lockdowns and a spreading virus, it gets increasingly important and relevant to reflect upon the bus-factor. Not only from the perspective of a software team, but from a business critical point-of-view. Besides, faster and consistent delivery is a great bonus.

It's time to deploy DevOps principles, such that what was once a manual process, is automated and integrated into well-behaving workflows and single-click-or-less releases.

The issue

We have this project. What started out as an idea from the accountants at the upper floor, has grown into a critical application that supports their current workflow. Releases are manual and only when new changes are requested. The project know-how is limited to the single developer which had the idea pitched and with that, how the application is being built and released.

The basics

We got the source code and some post-it notes from the developer on how to publish the project.

New territory, let's make some ground. First step is to create a new project for our application named Financial Dashboard.

Which then leads to the welcome screen for the project

A quick TL:DR for each section available

Overview
- Your Dashboard. Can be customized with things like project information and widgets
Boards
- Project management tools like backlogs, boards, sprints
Repos
- Code repositories (a DevOps project can contain multiple repositories), branches and pull request management
Pipelines
- Build and Release pipeline management
Test Plans
- Feature-rich testing platform
Artifacts
- Artifact feeds for package platforms like NuGet, NPM, Pip etc

We will focus on Repos and Pipelines features during this post.

Empty repository. Add some code!

Our codebase is a newly created ASPNET Core application with an Angular frontend (dotnet new angular). The Angular application has been slightly updated to support test and code coverage in our DevOps build pipeline.

Next step is to create our code repository and prepare it to be integrated with our upcoming automated build and testing pipeline. By default, DevOps creates an empty repository with multiple options on how to initialize it. A side-note on DevOps is its ability to support multiple repositories inside the same project.

We created our Financial Dashboard with Git support. Use your favorite Git tool to push your code to the newly created repository.

Let the automation begin

Code in place - check. Time to introduce CI/CD principles. For now, we will keep things simple by only being concerned about the master branch and ignoring other things like pull requests.

Automatic build on push

First step is to create a build pipeline that triggers, when new code is pushed to our repository. The language used to describe these steps is called YAML.

The defined pipeline is a separated into 2 stages. The first one runs two jobs in parallel (if supported), a dotnet and a npm job, where both builds and runs any related tests. During so, we can speed up our initial stage and verify both our backend and frontend at the same time.

If the first stage succeeded and all tests completed successfully, the 2. stage is initiated. This stage calls dotnet publish to create our final compiled application and then copies the output to our artifact staging directory. This can be seen as our build pipeline output, which we later on will use in our release pipeline, when deploying the application.

trigger:
- master

pool:
  vmImage: 'windows-latest'

variables:
  dotnetConfiguration: 'Release'
  angularConfiguration: '--prod'
  angularClientSrc: 'src/YourOrg.FinancialDashboard/ClientApp'
  dotnetBackendSrc: 'src/YourOrg.FinancialDashboard/YourOrg.FinancialDashboard.csproj'

stages:
- stage: BuildAndTest
  jobs:
  - job: 'Dotnet'
    steps:
    - task: DotNetCoreCLI@2
      displayName: 'dotnet restore'
      inputs:
        command: restore
        projects: 'src/**/*.csproj'

    - task: DotNetCoreCLI@2
      displayName: 'dotnet build'
      inputs:
        command: build
        projects: 'src/**/*.csproj'
        arguments: '--configuration $(dotnetConfiguration)'

    - task: DotNetCoreCLI@2
      displayName: 'dotnet test'
      inputs:
        command: test
        projects: 'src/**/*Tests/*.csproj'
        arguments: '--configuration $(dotnetConfiguration)'

  - job: 'Npm'
    steps:
    - task: Npm@1
      displayName: 'npm install'
      inputs:
        command: 'install'
        workingDir: '$(angularClientSrc)'

    - task: Npm@1
      displayName: 'build angular client'
      inputs:
        command: custom
        customCommand: run build -- $(angularConfiguration)
        workingDir: '$(angularClientSrc)'

    - task: Npm@1
      displayName: 'angular client test'
      inputs:
        command: 'custom'
        workingDir: '$(angularClientSrc)'
        customCommand: 'run test -- --watch=false --code-coverage'

    - task: PublishCodeCoverageResults@1
      displayName: 'publish angular client code coverage results'
      condition: succeededOrFailed()
      inputs:
        codeCoverageTool: Cobertura
        summaryFileLocation: '$(angularClientSrc)/coverage/cobertura-coverage.xml'
        reportDirectory: '$(angularClientSrc)/coverage'
        failIfCoverageEmpty: true

    - task: PublishTestResults@2
      displayName: 'publish angular client test results'
      condition: succeededOrFailed()
      inputs:
        testResultsFormat: 'JUnit'
        testResultsFiles: 'TESTS*.xml'
        searchFolder: '$(angularClientSrc)/junit'
        failTaskOnFailedTests: true
        testRunTitle: 'Angular'

- stage: PublishApplication
  jobs:
  - job: PublishApplication
    steps:
    - task: DotNetCoreCLI@2
      displayName: 'dotnet publish'
      inputs:
        command: 'publish'
        publishWebProjects: true
        arguments: '--configuration $(dotnetConfiguration) --runtime win-x86 --output $(Build.ArtifactStagingDirectory)'
        zipAfterPublish: false

    - task: PublishBuildArtifacts@1
      displayName: 'public artifacts'
      inputs:
        pathtoPublish: '$(Build.ArtifactStagingDirectory)' 
        artifactName: 'financial-dashboard'

When the build pipeline is running, we can follow the status of each individual stage and task. In addition to this, the output for each task is collected during execution. When completed, we end up with an output artifact containing our published application.

Deployment trigger

With out published artifact ready, it's time to create the deployment pipeline. For this, we will be using the newly created build artifact.

The published artifact is created as a self-contained application targeting win-x86. For this specific deployment, the we will utilize FTP, since the hosting machine is external without access to the IIS. If you're using any Azure-hosted services or have access to the IIS, specific deployment tasks exists that manages and publishes our artifacts, while handling things like managing instances, setting release variables and temporarily stopping any running applications.

We don't have any database in our example, but you can easily manage deployments to these servers too. Using Entity Framework? Create a migration update script during build, use the built-in database deployment task and you're done.

Interested in DevOps?

And that's it. We've now implemented DevOps concepts such that when we push code to our repository, it automatically triggers a build which runs and verifies the tests. If successful, the generated artifact is then handed over to the deployment pipeline which automatically releases our application. I started our with single-click releases... but how about no-click releases ;)

If you have any questions about DevOps, have questions or want to learn more about specific stages, feel free to comment below

From service classes to request pipelines

Nicolai Ringbæk — Fri, 24 Jan 2020 07:45:13 +0000

Not only platforms and frameworks change over time. The application may be separated into multiple sub-applications (microservices) or have parts of its logic shared with other applications.

Defining and integrating architectural values can help keep the system stand the test of time. This post will focus on the values testability, modularity, development time. In addition to this, the overall goal is a way to enforce input validation and authorization of the executed logic, without relying on platform/framework features. The more declarative, transparent and easy to implement these steps are, the better.

The software pattern mediator has a lot to say in designing the solution for this case. The gist of it is, that it encapsulates logic and decreases coupling inside the system. A side effect is, that it enables us to build a request pipeline, which can process the request and perform several checks, before calling the actual logic. One downside is discoverability of request classes compared to a service classes. Shout-out to the library MediatR for a great implementation.

The pipeline

The model validation and authorization checks could be a part of the method's initial statements. However, it decreases transparency of the method, when what we're actually interested in, is a way to perform pre-flight checks before lift-off.

As inspiration, we can look at how ASPNET handle its request pipeline in a simplified manner. The pipeline itself consist of ordered middlewares. Each request received calls the initial middleware after which it traverses through the registered stack of middlewares. For each middleware, it has the ability to modify the context, return a response or call the next middleware in line.

The idea is to build a logical pipeline when executing code/requests, where each part makes sure that the request continues to be valid and can be performed. The pipeline implementations for Ramble is ValidationPipeline and AuthorizationPipeline.

The integration

When a solution grows in size and large projects gets divided into multiple sub-projects, it can get hard to keep track on the dependencies and what each of them require to operate. With improvements to .NET's Host-concepts and how well-integrated DI has become, it's a natural step to utilize some of these concepts to simplify registration, even outside the usual applications like ASPNET.

The RambleServiceBuilder gives us our own extension point to simplify discoverability between projects. The AddRambleCoreServices method sets up the pipeline, including any other needed services for that specific layer. Other projects, while referencing our pipeline defining project, can then continue to add service registrations using this builder. An example on this is the AddStandaloneFeature() extension method from the separate project.

public static RambleServiceBuilder AddRambleCoreServices<TContext>(
    this IServiceCollection services,
    Action<RambleServiceCoreOptions> options) where TContext : IRequestContext
{
    var rambleOptions = new RambleServiceCoreOptions();
    options.Invoke(rambleOptions);

    services.AddSingleton(options);
    services.AddScoped(typeof(IRequestContext), typeof(TContext));

    services.AddMediatR(typeof(RambleCoreBuilderExtensions));

    if (rambleOptions.Pipeline.EnableRequestValidation)
        services.AddScoped(typeof(IPipelineBehavior<,>), typeof(ValidationPipeline<,>));

    if (rambleOptions.Pipeline.EnableRequestAuthorization)
        services.AddScoped(typeof(IPipelineBehavior<,>), typeof(AuthorizationPipeline<,>));

    return new RambleServiceBuilder(services);
}

public void ConfigureServices(IServiceCollection services)
{
    // Rest of the setup removed for brevity

    services.AddRambleCoreServices<HttpRequestContext>(options =>
    {
        options.Pipeline.GlobalAuthorizationRules.Add(new IsAuthenticatedRule());
    })
    .AddStandaloneFeature();
}

The IRequestContext is a per-application implementation. It defines how the application can construct the request context, which contains a reference to the IServiceProvider and the RequestIdentity. The RequestIdentity instance can be seen as an alias for the current authenticated user. If it's an ASPNET application, it's usually going to be constructed via IHttpContextAccessor. CLI and other application types may have other ways of defining the context. Besides, the goal was to reduce coupling with platforms/frameworks. This means that utilizing IHttpContextAccessor via DI inside the requests, will limit the code to environments where the instance is available (ASPNET).

public class HttpRequestContext : IRequestContext
{
    public RequestIdentity Identity { get; }
    public IServiceProvider ServiceProvider { get; }

    public HttpRequestContext(IHttpContextAccessor contextAccessor)
    {
        ServiceProvider = contextAccessor.HttpContext.RequestServices;
        Identity = contextAccessor.HttpContext.User.Identity.IsAuthenticated
            ? GetAuthenticatedIdentity(contextAccessor)
            : RequestIdentity.Anonymous();
    }

    private RequestIdentity GetAuthenticatedIdentity(IHttpContextAccessor contextAccessor)
    {
        var userId = contextAccessor.HttpContext.User.FindFirstValue(ClaimTypes.NameIdentifier);

        var roles = contextAccessor.HttpContext.User.Claims
            .Where(e => e.Type == ClaimTypes.Role)
            .Select(e => e.Value)
            .ToList();

        var properties = new Dictionary<string, object>
        {
            { "name", contextAccessor.HttpContext.User.FindFirstValue(ClaimTypes.Name) },
            { "email", contextAccessor.HttpContext.User.FindFirstValue(ClaimTypes.Email) }
        };

        return RequestIdentity.Authenticated(
            userId: userId,
            roles: roles,
            properties: properties
        );
    }
}

In action

Defining a request

The request class defines the method signature with its properties as arguments. To extend the behavior of the request, the Validator and Authorizer sub-classes define requirements in a declarative, without cluttering the actual business logic (deleting the wall). Such separation simplifies development, since authorization rules can be shared between multiple requests. Each step (validation, authorization and method execution) can be tested individually, making the testing process more focused and easier to write and validate.

As a side-note to the request and its authorizer. Some authorization checks can't be declared solely on its own, since it plays a central part in the business logic. An example on this is, if we wanted to get a list of all posts, but we only had access to see text entries, not images. This would require filtering of the result, which could be implemented as a post-processing action of the logic. However, I think that in most (all) cases, this adds unneeded overhead and complexity, including the possibility to degrade system performance (fetching all entries, then filtering locally).

public class DeleteWall : Request<DeleteWall>
{
    public int WallId { get; }

    public DeleteWall(int wallId)
    {
        WallId = wallId;
    }

    public class Validator : RequestValidator<DeleteWall>
    {
        public Validator()
        {
            RuleFor(e => e.WallId).GreaterThan(0);
        }
    }

    public class Authorizer : RequestAuthorizer<DeleteWall>
    {
        public Authorizer()
        {
            AddRule(wall => new CanAdministerWallRule
            {
                WallId = wall.WallId
            });
        }
    }
}

Validation and Authorization

To add validation and/or authorization checks, a class inheriting from RequestValidator or RequestAuthorizer can be created. Both classes share the same declarative way of defining the rules via the constructor.

Behind the scene, the validator uses the library FluentValidation. Works great and can handle advanced cases where DataAnnotation attributes fall short.

Regarding the authorizer, the implementation can be divided into rule arguments (the instance added in the Authorizer class) and rule engines, which contains the authorization logic. Mediator pattern to the rescue, since we need to add rules without complex constructors, while keeping the ability to transform a Request object to the given Rule for that sweet reusability value. The engine itself is then created when needed and includes the needed DI capabilities - neat.

public class CanAdministerWallRule : IAuthorizationRule
{
    public int WallId { get; set; }
}

public class CanAdministerWallRuleEngine : AuthorizationRuleEngine<CanAdministerWallRule>
{
    private readonly RambleDbContext _dbContext;
    private readonly IRequestContext _requestContext;

    public CanAdministerWallRuleEngine(RambleDbContext dbContext, IRequestContext requestContext)
    {
        _dbContext = dbContext;
        _requestContext = requestContext;
    }

    public override async Task<bool> IsAuthorized(CanAdministerWallRule rule)
    {
        var wall = await _dbContext.Walls.FirstOrDefaultAsync(e => e.Id == rule.WallId);
        return wall != null && wall.CreatorId == _requestContext.Identity.UserId;
    }
}

Request logic

When the request has been created and the validation/authorization steps passed, the time for executing the actual request logic begins. Since this part has been guarded before being executed, we know that the request is valid and the identity executing it is authorized. This simplifies our code as seen below. In addition to this, since each RequestHandler is based on its own class, we can DI only what's needed. Compared to traditional service classes, which needs to DI everything needed to construct the instance at once, regardless of what the called method(s) needs. This helps to increase transparency of the code.

It may initially seem like we're hitting the DB twice, both times asking for the same object. However, Entity Framework caches the Wall entity with the initial request, after which it is fetched locally for the proceeding requests. This is due to the context having a scoped lifetime in our DI container and its query tracking behavior enabled, which is on by default.

public class DeleteWallHandler : RequestHandler<DeleteWall>
{
    private readonly RambleDbContext _dbContext;

    public DeleteWallHandler(
        RambleDbContext dbContext, ILogger<DeleteWallHandler> logger) : base(logger)
    {
        _dbContext = dbContext;
    }

    public override async Task<RequestResult> Handle(
        DeleteWall request, CancellationToken cancellationToken)
    {
        var wall = await _dbContext.Walls.FirstOrDefaultAsync(e => e.Id == request.WallId);
        if (wall == null)
            return Error(RequestResultErrorCode.NotFound);

        _dbContext.Walls.Remove(wall);
        await _dbContext.SaveChangesAsync();

        return Success();
    }
}

The application interface

With everything in place, the pipeline is ready to be used. In this case, we have an ASPNET API controller which handles the creation of walls.

The controller knows the interface/protocol between the application and the user, not our pipeline. By that definition, it's the applications responsibility to create the correct form of response to return to the user. The result from our pipeline is wrapped in a Result object which, besides the result itself, contains basic information regarding the state. Do consider using a DTO instead of the Request class directly as API argument to separate concerns.

[HttpPost("")]
public async Task<ActionResult<int>> CreateWall(CreateWall model)
{
    var result = await Mediator.Send(model);
    if (result.IsError)
        return BadRequest();

    return Ok(result.Value);
}

Testability

So how does this hold up regarding testability? First of all, the separation of authorization and request logic simplifies writing the tests and makes it easier to accommodate the possible outcomes of the code being tested.

When an authorization rule has been created and tested, it can safely be used for other requests when needed. No need to test for those outcomes again.

public class DeleteWallTests : IDisposable
{
    private readonly RambleDbContext _dbContext;

    public DeleteWallTests()
    {
        _dbContext = new RambleDbContext(new DbContextOptionsBuilder<RambleDbContext>()
            .UseInMemoryDatabase(Guid.NewGuid().ToString()).Options);

        _dbContext.Walls.Add(new WallEntity
        {
            Id = 1,
            Name = "Test",
            CreatorId = Guid.NewGuid().ToString()
        });

        _dbContext.SaveChanges();
    }

    [Fact]
    public async Task DeleteWall_FoundEntity_Succesful()
    {
        var handler = new DeleteWallHandler(_dbContext, NullLogger<DeleteWallHandler>.Instance);
        var result = await handler.Handle(new DeleteWall(1), default);

        Assert.True(result.IsSuccess);
        Assert.Empty(await _dbContext.Walls.ToListAsync());
    }

    [Fact]
    public async Task DeleteWall_NotFoundEntity_Error()
    {
        var handler = new DeleteWallHandler(_dbContext, NullLogger<DeleteWallHandler>.Instance);
        var result = await handler.Handle(new DeleteWall(2), default);

        Assert.True(result.IsError);
        Assert.NotEmpty(await _dbContext.Walls.ToListAsync());
    }

    // IDisposable support removed for brevity
}

public class CanAdministerWallRuleTests : IDisposable
{
    private readonly RambleDbContext _dbContext;

    public CanAdministerWallRuleTests()
    {
        _dbContext = new RambleDbContext(new DbContextOptionsBuilder<RambleDbContext>()
            .UseInMemoryDatabase(Guid.NewGuid().ToString()).Options);

        _dbContext.Walls.Add(new WallEntity
        {
            Id = 1,
            Name = "Test",
            CreatorId = Guid.NewGuid().ToString()
        });

        _dbContext.SaveChanges();
    }

    [Fact]
    public async Task WallNotFound_ReturnsFalse()
    {
        var requestContextMock = new Mock<IRequestContext>();
        var ruleEngine = new CanAdministerWallRuleEngine(_dbContext, requestContextMock.Object);
        var result = await ruleEngine.IsAuthorized(new CanAdministerWallRule { WallId = 2 });

        Assert.False(result);
    }

    [Fact]
    public async Task IdentityIsCreator_ReturnsTrue()
    {
        var requestContextMock = new Mock<IRequestContext>();
        var userId = await _dbContext.Walls.Select(e => e.CreatorId).FirstAsync();
        requestContextMock.Setup(e => e.Identity)
            .Returns(RequestIdentity.Authenticated(userId, new List<string>()));

        var ruleEngine = new CanAdministerWallRuleEngine(_dbContext, requestContextMock.Object);
        var result = await ruleEngine.IsAuthorized(new CanAdministerWallRule { WallId = 1 });

        Assert.True(result);
    }

    [Fact]
    public async Task IdentityNotCreator_ReturnsFalse()
    {
        var requestContextMock = new Mock<IRequestContext>();
        requestContextMock.Setup(e => e.Identity)
            .Returns(RequestIdentity.Authenticated(Guid.NewGuid().ToString(), new List<string>()));

        var ruleEngine = new CanAdministerWallRuleEngine(_dbContext, requestContextMock.Object);
        var result = await ruleEngine.IsAuthorized(new CanAdministerWallRule { WallId = 1 });

        Assert.False(result);
    }

    // IDisposable support removed for brevity
}

Source code

Interested to see more? Ramble is a personal, public faced project of mine, used to experiment and validate my thoughts related to software (and architecture), in the land of .NET and Angular. In the end, the successful parts get introduced/integrated in real world-projects.

nringbaek / ramble

Ramble

Readme content to be added

Environment setup

Required

.NET Core 3.1 SDK

https://dotnet.microsoft.com/download

NodeJS (includes NPM)

https://nodejs.org/en/

Install the Angular CLI

Run the command npm install -g @angular/cli

Optional

Get both Visual Studio and Visual Studio Code.

https://visualstudio.microsoft.com/

Git (and optionally a GUI client)

Build the project

Building the Angular client

Navigate to the folder \src\Ramble.Web\ClientApp
Run the command npm install
Run the command ng build

Building the .NET Backend

Navigate to the folder \src\Ramble.Web
Run the command dotnet build

View on GitHub

Values of Software Architecture

Nicolai Ringbæk — Fri, 10 Jan 2020 07:03:16 +0000

Software architecture. Besides being one of my favourite aspects in the industry, it’s a topic that seems to keep evolving in both importance and the knowledge surrounding it. As a disclaimer, this is my take on software architecture in a modern, ever evolving and chaotic world. It’s based on several years of experience and a personal hunt for the optimal architecture, hence containing a lot of “I think…”.

This post is a 2-part series, with this being part 1. It will reflect on software architecture with a theoretical- and business-oriented mindset and highlight some of the architectural values that I find especially important. Part 2 will have a practical take on those values and a complete demo project including source code available on Github.

Many definitions exist on what software architecture is. Selecting one over others is no fun, especially when this is the perfect opportunity for me to expose my own (biased) definition.

A series of design- and technical choices, which shapes the system and its ability to support ongoing development and daily operation, such that both negative/positive properties of the system are minimized/maximized in a balanced way.

Which is a vague definition compared to others, but don’t worry. Now’s the time to explain and concretize. First it's important to get a grasp on what’s important for the system by defining a series of architectural properties followed by splitting up the architecture into areas of responsibility.

Trying to define the important values of modern software architecture without context is a (NP-)hard problem. This leads to the need of initially defining the context and its properties. I’ve defined 3 ownership groups, each containing a short list of important properties.

PRODUCT	BUSINESS	DEVELOPMENT
Functionality	Cost of operation	Reusability
Quality	Adaptable	Testability
Performance	Modular	Development time
Scaling	Time to market

These definitions can be applied across multiple architectural levels based on the given level of detail, from a general system overview to concrete features and how they’re integrated. While a technical document may be non-existing (like most documentation in the world of software), keeping these properties in mind during the process of defining and developing the tasks, they can elevate the final product and reduce future risks and issues.

In a naive world, software architecture can be divided into two groups, each with their own responsibilities – micro and macro. The infrastructure, supporting CI/CD and selected technologies lay the foundation of the system. The point of the macro group in software architecture is to enable developers and business operations to perform better and faster while minimizing obstacles. The micro group of software architecture then reflects on the concrete implementation of features in the system – it’s code, logical structure and the patterns used.

PRODUCT

From a user’s point of view, functionality, quality and (at some level) performance is what defines the product and how satisfied the user is. It’s important for keeping user retention and the business case of the system. Selecting the right front-end technologies and frameworks can position the development of the system to more easily accomplish these properties.

Scaling can be a harder property to nail since it’s usually followed by negative side effects regarding cost, complexity and development time. The easiest answer is to simply not deal with it and not do early optimizations, unless it’s needed or expected to be needed soon. However, this doesn’t mean one should neglect the aspect of scaling.

Many cloud providers today enable customers to automatically scale ressources up/down. Besides the obvious benefits of being able to scale up, scaling down based on load can be an effective cost-reducing tool for the business. However, while scaling is related to system load in which the infrastructure plays an important role, the available scaling options is usually dependent on how the system is built. Things such as preserving the user session over multiple requests can affect this – which in general can be shortened to state vs stateless systems.

BUSINESS

Cost of operations. Urgh – even though building systems is fun, the business aspects are a vital part of the system. A system without a viable business case (negative revenue/ROI) usually result in the system being decommissioned over time. This is not a sob story though. We as developers can do much to improve the viability of the business case simply by understanding that systems cost money. Optimizing bad performing code (CPU time), selecting cost-optimized infrastructure and implementing methods for adaptive scaling is just a few strategies to reduce cost of the system. In hindsight, these optimizations may increase the available budget and by that increase flexibility and the potential to invest in new features. It’s unfortunately not a topic that’s talked a lot about but if Feature A increases revenue by 50 and optimizing existing infrastructure/application performance reduces cost of operation by 100, the business case is strong for the latter.

Adaptability and modularity. One may think that this is a developer thing and has nothing to do with the business. However, if the business requirements never change, the need for adaptability and modularity usually following a similar pattern of not being needed. In a worst-case scenario, a high level of inflexibility of the system may result in new requirements and features being postponed or denied.

Ever heard about that bug? The users became annoyed. The bug resulted in data errors which later would require additional time to fix. Good thing all it took was 1 hour to fi… wait 3 months till next planned release? Time to market is usually a combination of two things – automated builds and release systems (CI/CD) and an optimized process where incremental improvements weights higher than a fictive release number. It may initially be scary to release often if one is not used to it, but if the infrastructure can handle short TTM, so can potential bugfixes and since each release is incremental, the changes in each update is easier to test and verify beforehand. If not for TTM improvements, then the usage of CI/CD internally for improving system development by automation and integration with source control usually affects code quality in a positive way.

DEVELOPMENT

Reusability not only reduces the amount of code needed to complete features, but it also reuses existing components that has already been tested. It’s a win. You want to know what’s not a win? Fixing an issue 3 different places in code, all with similar logic, but forgetting the fourth.

One of my favourite things to focus on early, is how to reduce development time. This is especially true, if the architectural optimizations have no negative consequences on other aspects of the architecture. Two of the common pitfalls that affects development time across all skill levels is startup time to debug and complex code increasing development time in general – that’s why we should refactor code.

An example of a time-reducing strategy is hot reloading. Being able to make changes to the code without restarting the system is infinitely time reducing. A feature could be that the system is able to generate PDF files. Creating the template can be time consuming while nailing the UI. If the templates are loaded from an external source (file on disk), it can at debug time be read every time the PDF is generated hence removing the need to restart the system. At production time, the template can be cached.

And when we are talking about reducing development time, then how about completely removing the need to start up the application to debug? Testability of the written code gives not just the ability to run isolated tests against logic, but also secures that the same methods stays functional over time. Writing tests is like if technical description and continuous integration had a child. The child is well-behaved unless you mess with its methods such that the tests fails. If so, it will annoy you until you either fixed the bug you introduced or update the technical description (the tests). That’s of course only if the code is written to be testable to begin with.

What’s next and the chosen tech stack

Part 2 in this series will have a practical take on software architecture based on several of the defined architectural properties from this post. The system being built is a blog platform with public “walls” and posts backed by a CMS requiring user authentication. Some of the primary properties the system tries to fulfill is related to testability, modularity and minimizing development time.

The tech stack for the system will depend primarily on the following technologies

Angular 9
.NET Core 3.1 (ASPNET)
Mediator + CQRS