DEV Community: Georg Müller

Branding a multitenated application using CSS

Georg Müller — Sun, 09 Jan 2022 14:20:43 +0000

A friend of mine had an interesting challenge. He wanted to have a public part of an B2B application brandable in the color of its customers and asked me how I would do it. This post describes what I told him.

The application basically is a simple form and a summary describing the data the user will submit.

Base setup in the CSS

Use CSS variables for the colors and use them consistently where you want the brands colors to be applied.

:root{
  --brand-color-1:rgb(66,153,225);
  --brand-color-2:rgb(255,255,255);
}

I this case I created a themable button:

button {
  background-color: var(--brand-color-1);
  border-color: var(--brand-color-2);
  color: var(--brand-color-2);
  border-radius: 3.5rem;
  border-style: solid;

  padding: 6px 10px 6px 10px;
}

Looks like this:

Use CSS inheritance to override the color

In CSS properties are inherited from the root element to its child elements.
In this case I would override it on body as I would like to have all elements using the overridden colors, eg like this:

<body style="--brand-color-1: #48BB78">

Now you can override the color on the html using your web framework of choice.

If you are rendering on the server you should be aware of caching. You would probably like to cache by tenant and make sure you invalidate when changing the colors, but that is out of scope for this post.

If you want to play around with this solution I made a codepen:

Concluding

This is a solution by a backend developer :-). Do you know of a better solution?

Modularize ASP.NET DI configurations using Autofac

Georg Müller — Sun, 14 Nov 2021 16:27:29 +0000

When working on a monolith in ASP.NET the Startup.cs tends to get messy as more and more services are added.

Nevertheless, with the Microsoft.Extensions.DependencyInjection being the new and good default for libraries to provide means for configuration, I want to use these extension methods to setup my dependency injection container of choice, which is Autofac.

Modularizing the configuration in Autofac

Autofac always provided means to easily modularize its configuration using Modules.

Basically you add a new class inheriting from Module and override Load.

public class AModule : Module
{
    protected override void Load(ContainerBuilder builder)
    {
        builder.RegisterType<MyType>();
    }
}

Then you are registering the module in the configuration.

builder.RegisterAssemblyModules(typeof(Startup).Assembly); // Register all modules in assembly
builder.RegisterModule(typeof(AModule)); // Register single module
builder.RegisterModule<AModule>(); // Register single module using generics

Integrating Microsoft.Extensions.DependendyInjection registrations with Autofac Modules

Autofacs integration with Microsofts DependencyInjection (https://github.com/autofac/Autofac.Extensions.DependencyInjection) adds an PopulateServices extension that allows to add all services in an IServiceCollection to the Autofac configuration.

When adding Autofac to an ASP.NET application this method is used at the end to integrate the Microsoft.Extensions.DependencyInjection services into Autofac.

public static void Populate(
            this ContainerBuilder builder,
            IEnumerable<ServiceDescriptor> descriptors)

This method can also be used in modules to add additional services to the container in a modular fashion. Here an example for a ValidationModule that adds FluentValidation to the application:

public class ValidationModule : Module
{
    protected override void Load(ContainerBuilder builder)
    {
        var services = new ServiceCollection();

        services.AddFluentValidation(fv => fv.RegisterValidatorsFromAssembly(ThisAssembly));

        builder.Populate(services);
    }
}

This method allows you to use extension methods provided by libraries for an easier integration into the .NET ecosystem in a modular, clean way located close to the code that needs it.

Conclusion

I have shown how I integrate Autofacs Module configuration with Microsoft.Extensions.DependencyInjection.

I use this method to modularize the configuration for my monolithic applications.

How are you managing your growing Startup.cs? Have you found another way to manage your dependencies in a better way?

Running Linux Containers on WSL using Nomad

Georg Müller — Sat, 28 Aug 2021 16:15:09 +0000

Hashicorp Nomad is a workload orchestration engine that allows you to deploy and operate workloads on multiple machines or VMs.

As such Nomad is a direct competitor to Kubernetes. In contrast to Kubernetes, Nomad allows to orchestrate not only containerized workloads, but also all kinds of non-containerized workloads like simple Linux processes, Java applications, Windows (IIS) applications, ... .

While it is flexible, it is also more simple than Kubernetes.

So recently I started looking into Nomad.

I set up Nomad on my Windows machine using chocolatey using

choco install nomad

Starting Nomad using, to setup a development agent

nomad agent -dev

While this successfully started Nomad, it did not start its Docker Task Driver, which allows to place Docker container in the Nomad Cluster. The error in the log was:

Docker is configured with Linux containers; switch to Windows containers

Searching for a solution I found this issue in the repo: Support Linux images in Docker for Windows

Basically the issue says, that the integration should work, but it is not being verified in tests. It also seems like some people got it to work while some are not.

I really don't see however, how someone could get this to run, as the fingerprinter of the docker container driver always throws an error: fingerprint.go

Some weeks later, I decided to take a different approach installing Nomad directly into the WSL Linux distribution. This allowed me to run Linux containers, while not having to launch an additional VM. These are the required steps.

Steps to get the Docker Task Driver working

Install Docker for Desktop
Start Docker for Desktop and make sure you have the Linux Kernel package installed; Docker will open a Microsoft website where you can find the download
Make sure you have the WSL2 backend enabled in Docker for Desktop - Settings
Download a Linux Distro from Microsoft Store, I have been using Ubuntu 20.04
Install Ubuntu
Make sure Ubuntu is the Default Linux Distro in WSL using

wsl -s Ubuntu-20.04

Enable WSL integration for Ubuntu in the Docker for Desktop settings; you find it in Settings > Resources > WSL integration
Install Nomad in Ubuntu (see Nomad docs)
Start it using

nomad agent -dev --bind=0.0.0.0

This successfully started Nomad (1.1.3 at time of writing)
A look in the log confirmed the Docker Task Driver started

[DEBUG] client.driver_mgr: detected drivers: drivers="map[healthy:[raw_exec docker] undetected:[exec java qemu]]"

If Docker is not detected at this point check your user is in the docker group using

groups

If you cannot see the docker group, add it using

sudo usermod -aG docker $USER

Then restart WSL by exiting the shell.

Test

Finally a quick test, its very easy to test if you can deploy a container to Nomad.

nomad init

This creates a example.nomad file, that includes all configurations to deploy a Linux Redis container.

Running

nomad run example.nomad

starts the deployment and successfully starts the container:

  ✓ Deployment "d3935b56" successful

    2021-08-04T14:13:54+02:00
    ID          = d3935b56
    Job ID      = example
    Job Version = 0
    Status      = successful
    Description = Deployment completed successfully

    Deployed
    Task Group  Desired  Placed  Healthy  Unhealthy  Progress Deadline
    cache       1        1       1        0          2021-08-04T14:23:52+02:00

Nice !!!!

Checklist

Make sure

you have an update version of Nomad, I am using 1.1.3 at the time of writing,
WSL2 mode is activated in Docker settings,
the distro is activated for WSL integration in Docker settings,
and (not WSL specific, but I always tend to forget it) add your user to the Docker group in WSL

Conclusion

After several failed attempts, using this checklist I managed to successfully start Nomad jobs on 2 different PCs.

Deep Dive - Autofac Integration in ASP.NET Core Dependency Injection

Georg Müller — Sun, 06 Sep 2020 15:54:36 +0000

One thing that seemingly remains consistent, is that the integration of Autofac with ASP.NET keeps changing. Starting with ASP.NET Core 3.0 this changed, because the generic host was introduced.

I will quickly explore the usage of Autofac in ASP.NET and then dive a bit into the details of its core. Together with the implementation in ASP.NET Dependency Injection it is an interesting design, although not quite as obvious.

Installation and Usage

Installation is simple. Reference Autofac.Extensions.DependencyInjection in your ASP.NET application.

To use Autofac in your application, go to the class that creates our Host, typically this is your Program.cs and insert .UseServiceProviderFactory(new AutofacServiceProviderFactory()).

It could look like this:

public class Program
  {
    public static void Main(string[] args)
    {
      var host = Host.CreateDefaultBuilder(args)
        .UseServiceProviderFactory(new AutofacServiceProviderFactory())
        .ConfigureWebHostDefaults(webBuilder => webBuilder.UseStartup<Startup>())
        .Build();

      host.Run();
    }
  }

This enables Autofac as DI container in your ASP.NET Core Application.

Then you can add a ConfigureContainer method to your Startup class and configure the container using the ContainerBuilder you are used to as Autofac user.

public void ConfigureContainer(ContainerBuilder builder){
    builder.RegisterAssemblyModules(typeof(Startup).Assembly);
}

The integration also supports taking dependencies on registration in the IServiceCollection. So if you have on library that only supports registration with the ASP.NET Dependency Injection you do not have to worry. You can use it in your application.

These methods also support environment based naming conventions. I am not a fan of them but you can find the conventions in the Autofac docs.

What is registered?

The core of the integration is the AutofacServiceProviderFactory.

A ServiceProviderFactory is a abstraction within ASP.NET Dependency Injection. It allows Dependency Injection Frameworks to be used with ASP.NET, combining the advantage of having the an unified configuration for dependencies (useful for frameworks, so they only have to support one style of configuration), with the power of existing DI containers out there.

So it has two purposes.

First: It creates the DI container builder and populates it with dependencies from the ASP.NET ServiceCollection. The developer can then configure additional dependencies or replace the dependencies registered using the Autofac mechanisms.

Second: It builds the container and wraps it as ServiceProvider to be used in the framework.

Adding scopes

Working with DI containers and ASP.NET you will know that there are different scopes for objects and their dependencies.

The basic cases are Singleton and PerDependency, where Singleton is on object per application is instantiated and PerDependency creates an object for every dependency that requires the object.

In a HTTP framework you want to share some state application wide, but some dependencies should be once per request.

An example would be an UnitOfWork from an ORM. Once a dependency required it on the request, it should stay the same UnitOfWork for the whole request.

Therefore a LifetimeScope (in Autofac terminology) or ServiceScope (ASP.NET terminology) exists.

It is created when a new Request starts and is disposed when the request is completed.

ASP.NET needs a factory to create these ServiceScopes. When populating the ContainerBuilder Autofac adds this factory (AutofacServiceScopeFactory) to itself, so that ASP.NET can resolve it.

Its also interesting how this is integrated in ASP.NET. When the HttpContext of a Request is constructed it gets a reference to the ServiceScopeFactory.

The first time a service is resolved from the request it instantiates the ServiceScope, thus resolving all the dependencies configured for this scope.

Conclusion

The Autofac integration is implemented as it is expected from a DI container implementation for ASP.NET Core.

What is most interesting, is how the container registers its own implementations in itself, in order for ASP.NET to resolve it.

When debugging this a few months ago I missed this detail, thus suspecting an error of mine to be in the DI integration. Obviously I was wrong...