DotNetNerd's blog

Azure identity - managed identities and roles

christian@dotnetnerd.dk — Fri, 23 Jun 2023 07:41:00 +0000

For a while I have actually not had to do much configuration of app registrations, managed identities and so on, simply because I often join teams who have other people doing that part. So it has been fun and at time challenging to get back into it, as I have had to lately. So to help others, and maybe a future me I just want to write down a few notes, that will help me remember a few key details.

First of all when we are talking about a setup with a frontend application and backend api app registration, the app roles and claim mapping should be done in the backend api, with roles being defined as part of the app registration, and the mapping from e.g. groups being done in enterprise application. The roles and claims will then become available in the access token, once a user logs in using the clientid for the frontend application, that uses the backend API.

In most we cases we will then also need to have services that should be able to call our API. Authenticating using managed identity makes this quite simple, with the caviat being that roles can only be assigned using a script.

To run e.g. a Functions app that should be allowed access you need to configure a managed identity and add the role to it using a powershell script like below. User assigned managed identity can be used if you wish to use it for multiple services, however things like access to key vault using keyvault references require a system managed identity - so you will likely need to either use a system managed identity and configure it for each service, or have both kinds of managed identity configured.

$objectIdForManagedIdentity = "insert object (principal) id from managed identity"
$enterpriseApplicationObjectId = "insert enterprise applications object id"
$roleIdGuid = "insert role id"

$uri = "https://graph.microsoft.com/v1.0/servicePrincipals/$objectIdForManagedIdentity/appRoleAssignments"
$body = @{
    principalId = $objectIdForManagedIdentity
    resourceId = $enterpriseApplicationObjectId
    appRoleId = $roleIdGuid
} | ConvertTo-Json
az rest --method POST --url $uri --body $body

After that when fetching a token using DefaultAzureCredentials the .default scope should be used and the ManagedIdentityClientId should be set to ensure it uses the user assigned identity.

Putting API Managemement in front of blob storage

christian@dotnetnerd.dk — Mon, 13 Feb 2023 09:12:00 +0000

A nice and simple way to expose static files is through Azure blob storage. If you are already using API Management you might want to have requests to through there, in order to ensure you can move it to somewhere else in the future. It requires a few steps to get it to work though.

First of all Managed Identities should be enabled in API management and Access Control (IAM) should be configured for the container to allow API management to access the file. In API management the endpoint is added with authentication-managed-identity policy to allow authentication is passes through. After that a number of headers should be removed and the x-ms-version, which is required to do AD authentication, should be set when forwarding the request from API Management to the blob storage endpoint.

In my case I also wanted to avoid the .json extension in the endpoint, so the configuration ended up looking something like this.

<policies>
    <inbound>        
        <set-header name="Ocp-Apim-Subscription-Key" exists-action="delete" />
        <set-header name="Sec-Fetch-Site" exists-action="delete" />
        <set-header name="Sec-Fetch-Mode" exists-action="delete" />
        <set-header name="Sec-Fetch-Dest" exists-action="delete" />
        <set-header name="Accept" exists-action="delete" />
        <set-header name="Accept-Encoding" exists-action="delete" />
        <set-header name="Referer" exists-action="delete" />
        <set-header name="X-Forwarded-For" exists-action="delete" />
        <set-header name="x-ms-version" exists-action="override">
            <value>@{string version = "2017-11-09"; return version;}</value>
        </set-header>        
        <rewrite-uri template="/settings.json" copy-unmatched-params="true" />
        <authentication-managed-identity resource="https://storage.azure.com/" />
    </inbound>
    <backend>
        <base />
    </backend>
    <outbound>
        <base />
    </outbound>
    <on-error>
        <base />
    </on-error>
</policies>

Updating API management from Azure Devops Pipeline

christian@dotnetnerd.dk — Wed, 14 Dec 2022 12:32:00 +0000

Recently I needed to update Azure Management API based on the swagger specifications when our services were deployed. It seems like a pretty standard thing that there would be a task for, but it turned out to require a bit of Powershell - it i still fairly simple though.

A general function to acccomplish it could look like this bit of code.

[CmdletBinding()]
Param(
    [string] [Parameter(Mandatory=$true)] $ResourceGroupName,
    [string] [Parameter(Mandatory=$true)] $ServiceName,
    [string] [Parameter(Mandatory=$true)] $ApiName,
    [string] [Parameter(Mandatory=$true)] $SpecificationFilePath
)

$apiMgmtContext = New-AzApiManagementContext -ResourceGroupName $ResourceGroupName -ServiceName $ServiceName
$api = Get-AzApiManagementApi -Context $apiMgmtContext -ApiId $ApiName

if ($null -eq $api) {
    Write-Error "Failed to get API with name $ApiName"
    exit(1)
}

$apiVersionSetId = $api.ApiVersionSetId.Substring($api.ApiVersionSetId.LastIndexOf("/")+1)
$apiVersionSet = Get-AzApiManagementApiVersionSet -Context $apiMgmtContext -ApiVersionSetId $apiVersionSetId

Import-AzApiManagementApi -Context $apiMgmtContext `
                        -SpecificationUrl $SpecificationFilePath `
                        -SpecificationFormat 'OpenApi' `
                        -Path $api.Path `
                        -ApiId $api.ApiId `
                        -ServiceUrl $api.ServiceUrl`
                        -ApiVersionSetId $apiVersionSet.Id

This can of course be used locally, but to run it from a release pipeline, the cleanest way I have found, is to add it to a separate repository, and include it as an artifact. From there we just need a Azure Powershell build step, configured as shown by the YAML below.

variables:
  swaggerUrl: 'https://my_appservice.azurewebsites.net/swagger/1.0.0/swagger.json'

steps:
- task: AzurePowerShell@5
  displayName: 'Azure PowerShell script: Update API Management'
  inputs:
    azureSubscription: 'xxx'
    ScriptPath: '$(System.DefaultWorkingDirectory)/_MyCompany.BuildScripts/UpdateApiManagement.ps1'
    ScriptArguments: '-ResourceGroupName "resource_group_name" -ServiceName "management_api_service_name" -ApiName "unique_api_id" -SpecificationFilePath $(swaggerUrl)'
    azurePowerShellVersion: LatestVersion

And that is all that is required, to automate it and make it update along with the build. Nice and easy.

Rolling my own OAuth 1.0 client

christian@dotnetnerd.dk — Tue, 24 Mar 2020 08:18:00 +0000

OAuth is one of those things where I always wonder about how bad the state of libraries etc are. It seems like a problem pretty much everyone will tackle, but I am still not able to find a simple, library that works well with .NET Core HttpClient without being a whole framework in itself or at least very framework dependent. Recently I needed just that for OAuth 1.0a, but ended up rolling my own. It is just the very basics, but I wanted to put it out there, because I guess others might have use for it, or I will some time in the future.

public class OAuth1
{
private static string validChars = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789";
private static Random random = new Random();

    public string SignatureBase(string method, string url, Dictionary<string, string> oauthParams)
    {
        return method + "&" + Uri.EscapeDataString(url) + "&" + Uri.EscapeDataString(string.Join("&", oauthParams.OrderBy(p => p.Key).Select(p => $"{p.Key}={p.Value}")));
    }

    public string Signature(string consumerSecret, string tokenSecret, string signatureBase)
    {
        var encoding = new ASCIIEncoding();
        string key = Uri.EscapeDataString(consumerSecret) + "&" + (string.IsNullOrEmpty(tokenSecret) ? "" : Uri.EscapeDataString(tokenSecret));
        byte[] keyBytes = encoding.GetBytes(key);
        byte[] messageBytes = encoding.GetBytes(signatureBase);

        using (HMACSHA1 SHA1 = new HMACSHA1(keyBytes))
        {
            var hashed = SHA1.ComputeHash(messageBytes);
            return Convert.ToBase64String(hashed);
        }
    }

    public string OAuthHeader(Dictionary<string, string> oauthParams)
    {
        return "OAuth " + string.Join(", ", oauthParams.Select(p => $@"{p.Key}=""{p.Value}"""));
    }

    public string GenerateTimeStamp()
    {
         TimeSpan ts = DateTime.UtcNow.Subtract(new DateTime(1970, 1, 1, 0, 0, 0, 0));
        return ((int)Math.Floor(ts.TotalSeconds)).ToString();
    }

    public string Nonce(int length = 32)
    {
        var nonceString = new StringBuilder();
        for (int i = 0; i < length; i++)
        {
            nonceString.Append(validChars[random.Next(0, validChars.Length - 1)]);
         }

return nonceString.ToString();
}

    public async Task<string> Request(string url, IDictionary<string, string> otherParams, string oAuthHeader)
    {
        using (var httpClient = new HttpClient())
        {
            httpClient.DefaultRequestHeaders.Add("Authorization", oAuthHeader);

string fullUrl = otherParams.Any() ? (url + "?" + string.Join("&", otherParams.Select(p => $"{p.Key}={p.Value}"))) : url;

HttpResponseMessage httpResp = await httpClient.GetAsync(fullUrl);

            return await httpResp.Content.ReadAsStringAsync();
        }
     }
}

With this in place we can do requests with the correct headers like this.

string _consumerKey = "aaa";
string _consumerSecret = "bbb";
string _accessToken = "ccc";
string _accessTokenSecret = "ddd";

var oAuth = new OAuth1();

string url = "http://myfancysite.com/api/cars/register";

string timestamp = oAuth.GenerateTimeStamp();
string nonce = oAuth.Nonce();

Dictionary<string, string> oAuthParams = new Dictionary<string, string>()
     {
         { "oauth_consumer_key", _consumerKey },
         { "oauth_nonce", nonce },
         { "oauth_signature_method", "HMAC-SHA1" },
          { "oauth_timestamp", timestamp.ToString()},
         { "oauth_token", _accessToken },
         { "oauth_version", "1.0"},
     };

Dictionary<string, string> otherParams = new Dictionary<string, string>()
     {
         { "email", "johnny@madsen.dk" },
         { "make", "Skoda" },
         { "model", "Fabia" },
         { "firstname", "Johnny" },
         { "lastname", "Madsen" }
    };

string signatureBase = oAuth.SignatureBase("GET", url, oAuthParams.Concat(otherParams.Select(p => new KeyValuePair<string, string>(p.Key, Uri.EscapeDataString(p.Value)))).ToDictionary(p => p.Key, p => p.Value));

string signature = oAuth.Signature(_consumerSecret, _accessTokenSecret, signatureBase);

oAuthParams.Add("oauth_signature", signature);

string oAuthHeader = oAuth.OAuthHeader(oAuthParams);

var result = await oAuth.Request(url, otherParams, oAuthHeader);

This side up please

christian@dotnetnerd.dk — Thu, 05 Mar 2020 11:29:00 +0000

On my current project we started seeing issues with images, especially when taken using an IPhone, that were shown as being rotated. Reading up on it I found that this is due to IOS using EXIF orientation, which is not always handled the same way on eg. Windows.

I found a couple of functions, that I modified to work with our TypeScript codebase, so that it utilizes async/await and has a minimum of type information. I suspect they might be useful for others, or myself later on, so here they are.

First there is a function that takes an image as a blob and returnes the orientation.

const getOrientataion = async (file: Blob) : Promise<number> => {

    return await new Promise<any>(resolve => {
         const reader = new FileReader();
        reader.onload = (event: any) => {
            if (event.target === null || event.target.result === null) return;
            const view = new DataView(event.target.result as ArrayBuffer);

if (view.getUint16(0, false) != 0xFFD8) return resolve(-2);

let length = view.byteLength,
offset = 2;

            while (offset < length) {
                const marker = view.getUint16(offset, false);
                offset += 2;

                if (marker == 0xFFE1) {
                    if (view.getUint32(offset += 2, false) != 0x45786966) {
                         return resolve(-1);
                    }
                    const little = view.getUint16(offset += 6, false) == 0x4949;
                     offset += view.getUint32(offset + 4, little);
                    const tags = view.getUint16(offset, little);
                    offset += 2;

                    for (let i = 0; i < tags; i++)
                        if (view.getUint16(offset + (i * 12), little) == 0x0112)
                             return resolve(view.getUint16(offset + (i * 12) + 8, little));
                }
                else if ((marker & 0xFF00) != 0xFF00) break;
                else offset += view.getUint16(offset, false);
            }
            return resolve(-1);
         };
        reader.readAsArrayBuffer(file.slice(0, 64 * 1024));
    });
}

Next is a small helper for converting the blob into a base64 encoded url.

const blobToBase64Url = async (file: Blob) : Promise<string> => {
    const reader = new FileReader();
     return await new Promise<any>(resolve => {
        reader.onload = (e: any) => resolve(e.target.result);
        reader.readAsDataURL(file);
    });
}

Lastly a function that takes a base64 encoded image url and an orientation, and returnes a new base64 encoded image that is the right way up.

const resetOrientation = async (srcBase64: string, srcOrientation: number) : Promise<string> => {
    return await new Promise<any>(resolve => {
         const img = new Image();
        img.onload = () => {
             let width = img.width,
                height = img.height,
                canvas = document.createElement('canvas'),
                 ctx = canvas.getContext("2d");

if (ctx == null) return;

            if (4 < srcOrientation && srcOrientation < 9) {
                canvas.width = height;
                 canvas.height = width;
            } else {
                canvas.width = width;
                canvas.height = height;
             }

            switch (srcOrientation) {
                 case 2: ctx.transform(-1, 0, 0, 1, width, 0); break;
                case 3: ctx.transform(-1, 0, 0, -1, width, height); break;
                case 4: ctx.transform(1, 0, 0, -1, 0, height); break;
                case 5: ctx.transform(0, 1, 1, 0, 0, 0); break;
                case 6: ctx.transform(0, 1, -1, 0, height, 0); break;
                case 7: ctx.transform(0, -1, -1, 0, height, width); break;
                case 8: ctx.transform(0, -1, 1, 0, 0, width); break;
                default: break;
            }
            ctx.drawImage(img, 0, 0);
             resolve(canvas.toDataURL());
        };
        img.src = srcBase64;
    });
}

And that is it.

Copying data on Azure in code

christian@dotnetnerd.dk — Wed, 05 Feb 2020 09:04:00 +0000

I have recently been looking at copying entire collections of data on Azure, in a way that should run as either Azure Functions or Webjobs. This is useful for backups, and simply moving data between environments. I didn't come across too many good samples of how to do this, so I expect it can be a useful topic for others who need to do the same thing.

Copying blob storage containers

As always we first need the basics in place. So we spin up CloudBlobClients for the source and the target.

CloudStorageAccount sourceStorageConnectionString = CloudStorageAccount.Parse(_connectionStringSettings.AzureStorageConnection);
CloudStorageAccount targetStorageConnectionString = CloudStorageAccount.Parse(_connectionStringSettings.AzureStorageBackupConnection);
CloudBlobClient sourceCloudBlobClient = sourceStorageConnectionString.CreateCloudBlobClient();
CloudBlobClient targetCloudBlobClient = targetStorageConnectionString.CreateCloudBlobClient();

Then we get the CloudBlobContainers and ensure that the target exists.

string container = "my-super-duper-dumpster";

CloudBlobContainer sourceContainer = sourceCloudBlobClient.GetContainerReference(container);
CloudBlobContainer targetContainer = targetCloudBlobClient.GetContainerReference(container);

await targetContainer.CreateIfNotExistsAsync();

Now we need a way to iterate through all the blobs. It is quite useful to be able to do this for a variety of operations. Besides copying, we can use it to delete or modify certain blobs. So for this purpose I created this method, that runs through each item and takes some action.

private async Task ForeachBlob(CloudBlobContainer container, Func<CloudBlockBlob, Task> action)
{
    BlobContinuationToken blobContinuationToken = null;
    do
    {
        var resultSegment = await container.ListBlobsSegmentedAsync(
             prefix: null,
            useFlatBlobListing: true,
             blobListingDetails: BlobListingDetails.None,
            maxResults: null,
            currentToken: blobContinuationToken,
             options: null,
            operationContext: null
         );

        blobContinuationToken = resultSegment.ContinuationToken;
        foreach (CloudBlockBlob item in resultSegment.Results)
        {
            await action(item);
        }
    } while (blobContinuationToken != null);
}

With this in place we can start copying. In my case the containers are private, so we need to get a SAS token, so it takes a bit of code like this.

await ForeachBlob(sourceContainer, async item => {
CloudBlockBlob sourceBlob = sourceContainer.GetBlockBlobReference(item.Name);

That gives us all the pieces we need. One small addition that I made was to time and log each operation I did. Putting Stopwatch start, stop etc calls around everything becomes quite ugly and drowns out the more important part of the code, so I made a runner like this, that can handle the minutiae of timing and logging.

public class Runner<T>
{
readonly ILogger<T> _logger;

    public Runner(ILogger<T> logger)
    {
        _logger = logger;
    }
    public async Task Run(Func<Task> func, Func<Stopwatch, string> logTextFactory)
    {
        var sw = Stopwatch.StartNew();
        await func();
        sw.Stop();
        var logText = logTextFactory(sw);
        _logger.LogInformation(logText);
    }
}

Then all it takes is to e.g. move the code that does the actual copying into its own method and wrap it like so.

await _runner.Run(async () => {
await CopyBlobs(targetCloudBlobClient, container, sourceContainer);
}, sw => $"Copying from \"{sourceContainer.Uri}\" to \"{targetContainer.Uri}\" took {sw.Elapsed.ToString("c")}");

Copying CosmosDB collections

In the same way as I copied blob storage containers, I also needed to copy CosmosDB collections. It is simpler, especially because of the BulkExecutor which has been made for these kinds of scenarios, but I will include a sample here for completeness.

Again we do the basics and spin up source and target clients.

var jsonSerializerSettings = new JsonSerializerSettings { DateParseHandling = DateParseHandling.DateTimeOffset };

DocumentClient sourceClient = new DocumentClient(
    new Uri(_connectionStringSettings.DocumentDBConnection), _settings.DocumentStorageSettings.DocumentDbKey,
    jsonSerializerSettings, new ConnectionPolicy { ConnectionMode = ConnectionMode.Direct, ConnectionProtocol = Protocol.Tcp });

DocumentClient targetClient = new DocumentClient(
new Uri(_connectionStringSettings.DocumentDBBackupConnection), _settings.DocumentStorageSettings.DocumentDbBackupKey,
jsonSerializerSettings, new ConnectionPolicy { ConnectionMode = ConnectionMode.Direct, ConnectionProtocol = Protocol.Tcp });

With those in place we set up the BulkExecutor.

targetClient.ConnectionPolicy.RetryOptions.MaxRetryWaitTimeInSeconds = 30;
targetClient.ConnectionPolicy.RetryOptions.MaxRetryAttemptsOnThrottledRequests = 9;

IBulkExecutor bulkExecutor = new BulkExecutor(targetClient, documentCollection);
await bulkExecutor.InitializeAsync();

targetClient.ConnectionPolicy.RetryOptions.MaxRetryWaitTimeInSeconds = 0;
targetClient.ConnectionPolicy.RetryOptions.MaxRetryAttemptsOnThrottledRequests = 0;

Then we are ready to read all the documents in batches and pass each to the bulk executor.

var documentQuery = sourceClient.CreateDocumentQuery(
UriFactory.CreateDocumentCollectionUri(_settings.DocumentStorageSettings.DatabaseName, "MySuperDuperCollection"),
new FeedOptions() {/*MaxItemCount = 2000*/ }).AsDocumentQuery();

while (documentQuery.HasMoreResults)
{
    var feed = await documentQuery.ExecuteNextAsync();

    BulkImportResponse bulkImportResponse = await bulkExecutor.BulkImportAsync(
      documents: feed.ToArray(),
      enableUpsert: false,
      disableAutomaticIdGeneration: true,
      maxConcurrencyPerPartitionKeyRange: null,
      maxInMemorySortingBatchSize: null);
}

Like in the first sample, we could wrap this part in a method and use the runner to do timing and logging.

To give a complete overview these are the libraries and versions used in my case.

Online tools and resources

christian@dotnetnerd.dk — Wed, 09 Oct 2019 08:25:54 +0000

Every once in a while you run into a great online tool or resource, and makes life as a developer easier. Moving between companies as I do, I often see that people are using services that provide lots of value, but are not necessarily well known by most. So in this post I will start by sharing a few of the services that I have come accross lately.

Docs and helpers

https://docs.microsoft.com/en-us/dotnet/api – API browser for all Microsofts .NET API’s.

https://regexr.com – best quick regex testing site I know of.

https://cronexpressiondescriptor.azurewebsites.net – simple way of testing cron expressions.

http://rxwiki.wikidot.com/101samples – 101 RX samples for guidance.

Image manipulation

https://tinypng.com and https://squoosh.app – two fast and easy solutions for image compression.

https://www.base64-image.de – drag and drop to convert images to base64.

Slides and prototyping content

https://unsplash.com and https://pixabay.com – quickly search and download tons of free beautiful photos.

https://picsum.photos – lorem ipsum with images.

http://officeipsum.com, https://hipsum.co, https://pirateipsum.me and https://slipsum.com – my favorite ipsum generators.

Email

https://temp-mail.org – temporary email for testing and catching spam.

Azure AD B2C easy auth across frontend and backend

christian@dotnetnerd.dk — Tue, 02 Apr 2019 17:02:00 +0000

Recently I had the need to setup easy auth using Azure B2C to authenticate users across a frontend Azure Web App and an Azure Functions backend. Allthough it sounds like a regular scenario, the documentation I found could have been better. I don’t have the time to write the complete docs, but this blogpost will outline the steps, so I can remember it for next time, and hopefully to enable you to do the same kind of setup. Let’s get cracking.

Applications

I will assume the Azure AD B2C has been provisioned, and if it is not, there is pleanty of documentation on that part. From there you first need to set up the frontend and backend as seperate applications in the AD.

In the Azure portal go to the Azure AD B2C and select applications. Here we have to setup the frontend and the backend respectively. Click add and enter a name for the application and choose “include web app / web API” for both applications.

For each application select it in the application list and setup the reply URL to point to the call back. The url should point to https.//<mysitesurl>/.auth/login/aad/callback.

For the frontend select the keys section and generate a key. Write it down, as you cannot retrieve it later and it is needed at a later step.

For the backend provide an App Id URI

Published scopes and API Access

Next the backend is setup to define access scopes. To do this select the backend application and go to published scopes.

Enter a name for a new scope and write down the full scope value, which you will need later.

To require access to the backend the frontend needs to set up API Access. To do this select the frontend application and go to API acces.

Click add and select the api you you just published. Check the scopes you wish to have access to.

User flows custom design

As an optional step, but something you will most likely need we will now set up a custom design.

Upload the custom design to blob storage using the portal by going to the storage account and selecting blobs. Create one if it does not already exist. Upload the static design files and note down the url’s for the login and reset pages.

From the Azure AD B2C overview choose user flows.

Create a Sign in v2 flow. Select the identity providers you need to support. Select the claims that you need. Most often it would be display name, email addresses and identity provider.

Under Page Layouts select “Use custom page content”.

Enter the url for the customized layout for the login.

Setup easy auth from the CLI

Now everything is setup and we are ready to turn on easy auth.

Setting up easy auth is as simple as a oneliner using the Azure CLI. It needs to be run for both the frontend and backend application.

az webapp auth update --name $appname --resource-group $ResourceName --enabled true --action LoginWithAzureActiveDirectory --aad-client-id $aadClientId --aad-allowed-token-audiences $url + "/.auth/login/aad/callback" --aad-client-secret $secret --aad-token-issuer-url $issuerurl

$aadClientId is the Azure AD ClientId that must be obtained from the AD

$url is the url for the app

$secret is the key generated in the AD B2C

$issuerurl is the url for the user flow in the AD (e.g. https://myad.b2clogin.com/myad.onmicrosoft.com/v2.0/.well-known/openid-configuration?p=B2C_1_SignInFlow)

Last kind of strange step

Lastly we need to set additionalLoginParams for the frontend app. Strangely this is not well supported via the CLI or Portal, so we need to use resource explorer to get the job done (https://resources.azure.com). Pick your subscription and navigate to resourceGroups/<resourcegroup>/providers/Microsoft.Web/sites/<fontendapp>/config/authsettings

Add an additionalLoginParams value with the required scopes. These are likely to be openid, offline_access and the full scope value defined in the AD B2C for the backend (e.g. "scope=openid%20offline_access%20https%3A%2F%2Fmyad.onmicrosoft.com%2Fapi%2FmyApi.ReadWrite"). Notice this needs to be url encoded.

Now you are all set. To make an http request to the backend you need to add a bearer token. This is retrieved from the /.auth/me route on the frontend. Here you also see refresh tokens and the claims that you requested.

And done…

Why cloud native is a gamechanger

christian@dotnetnerd.dk — Fri, 09 Nov 2018 11:25:09 +0000

Cloud native is one of those words that make some people shake their heads and call BS. In some contexts I am one of those people. It does however also have its place, because building solutions that are cloud centric does come with a number of benefits and enables solutions that were very hardif not impossible pre-cloud.

Sure, you can script the setup of a server from scratch, but it requires quite a bit of work, it takes time to execute and you still end up with an environment that requires updates and patching as soon as the script is a week old. In a cloud setup good practices, in the form of DevOps mainly using the CLI makes this very obtainable. Actually the current environment I am working with combines an ARM template and a few lines of script so we can spin up an entire environment in about 15 minutes. The only manual step is setting up the domain and SSL cert, but even that could be scripted if I wanted to.

Simplicity through serverless

Serverless is of course also a feature of cloud technology. It has quickly become one I love because it is, in a sence, the single responsibility principle taken to its conclusion. Building a regular WebAPI does not make you fall into the pit of success, simply because structuring functions well is difficult, and pretty much always leads to breaking the SRP in some degree. Creating one function at a time, with only the required dependencies and zero ceremony is likely to give you a much better foundation. A main focus of good software design really is dependency management, so being nudged in the right direction is hugely important.

In our case we went all in on JavaScript, and for our use case just having one language and especially one way if modeling has made life easy. We don't have too many complex rules or models, so here simplicity wins over having a more expressive language. The awesome thing is that in any case, we can adapt, because we are free to write some functions in eg C# if the need arises.

No more “SQL Server for everything”

Polyglot persistence is another paradigme that wins out by a cloud setup. If you have to install and maintain a bunch if databases yourself or wait for your it-department to do it, you will with good reason be reluctant to do it. When you can provision different databases as PaaS services it is trivial to do, and maintenance is no longer an issue. Simply put it allows you to pick the right tool for the job, without making you suffer for it.

I used to do what most developers did, and based everything on SQL server, because it allowed for rich querying, transactions and a fair amount of flexibility. It clearly came at the cost if spending a lot of time managing schemas, mapping data and solving performance issues, but there was no better way available at the time.

On Azure I get CosmosDB, which with the SQL API lets us save json, which means deeply nested models in the same shape as objects. So we spend less time bridging technologies, which makes us perform better, while the queries also perform better. We still have rich querying capabilities, transactions and we can even choose different API's if we need table or graph models. This in itself is important, but for the overall architecture the ability to add Redis for caching, table storage for huge amounts of tabular data or even a good old SQL database for doing BI is the real gamechanger.

Lastly there are all the other services that are available and can quickly be added as needed. An example I often think of is all the times I have seen solutions with custom "queues" implemented on SQL server. Again this was done to avoid adding a server that should be maintained, but at the cost of performance and not least bugs, because making a robust queue is not trivia. I am so glad those days are over! On top of all this comes Azure Vault, SignalR, IoT, ML, mobile, logic apps and I could go on and on listing specialized services, but suffice to say I love how architecture is no longer about limiting yourself, but about choosing the right tools.

UI testing done right with Cypress.IO

christian@dotnetnerd.dk — Thu, 11 Oct 2018 12:07:40 +0000

Finally, someone has written a UI testing tool for the web and done it right! For at least 5 years I have been envious of the UI testing tools that were written for native application development. I have tried various tools for UI testing websites, but they all relied on selenium, which sucks harder than my vacuum cleaner. No matter how much lipstick you put on a pig, it is still a pig, so the brittle nature of selenium would bleed through, and require you to do updates to drivers as well as handle very low level things like timing between a click and the actual page being re-rendered. So working with those tools has been slow and painful.

By coincidence I stumbled on cypress.io a few days ago, and right how I think it is the best thing since sliced bread.

Getting set up is litterally one single npm install, and they you are ready to go. The tests are written using mocha, chai and sinon, like we are used to. To there is no learning curve there.

Controlling the browser actions is done through an API that is so simple that my first test worked right off the bat, and it is very well documented. On top of that it includes the jquery, lowdash, moment, minimatch, blob and promise libraries that are all well known for most of us working with javascript.

Running the tests is done using the equally well documented and easy to use cypress cli, which can either run the tests directly using a headless browser, or it can open the cypress application, where you get a well designed UI. In the UI you can pick exactly which tests to run, you see them running I a browser window and the steps are listed. Not only that but you get time travel by hovering each step, so you will see exactly what the pages looked like at that point in time. On top of this it records video and takes screenshots when an error occurs, so you can add that to your bug report.

The ability to do this using a headless browser means that it is really easy to integrate into your CI build. Actually they have comprehensive guides for all the big CI solutions. It also includes reporters, so you get a nice report as part of your overall CI report.

So it is safe to say that I am very impressed and I can't wait to use this for my current project. Oh and I mention it is free, as in beer.

There is one downside currently that I ha e to call out. It is the fact that currently it is limited to the different versions of chrome browsers. No IE, no Edge and no Firefox. I believe it is being worked on, from what I read on the website, so we will get there, but for now that means it does not solve cross browser testing.