DEV Community: Nicola Biancolini

Micro frontends and Blazor Server, the beginning of the journey

Nicola Biancolini — Wed, 01 Jun 2022 07:21:35 +0000

I was recently asked to make a spike¹ to evaluate the feasibility of implementing a micro frontends architecture with Blazor Server.

I'll tell you right now that it was a failure; but let's go in order, first analyzing the declension of the term failure and the reasons that led me to use it and then try to recapitulate what emerged from this exploration that led me to this conclusion.

I really like the definition he gives Treccani.

Riconoscere l'inutilità dei propri sforzi, l'impossibilità e incapacità di raggiungere gli scopi fissati, rinunciando definitivamente alla lotta, all'azione.

-- Treccani

Which translated, hoping to do it correctly, would be "Recognizing the futility of one's efforts, the impossibility and inability to achieve the set goals, definitely giving up the struggle, action."

I find it particularly proper because it uses the term fixed scopes, and so what are those purposes?

Context matters.

Nothing is done by accident, and this is certainly no exception. The work done is part of a larger context involving the need to migrate a number of ASP.NET MVC 5 applications to ASP.NET Core combined with a desire to make the current architecture more flexible by introducing the concept of modular-programming².

Without getting around too much, the ultimate goal was to measure the feasibility of "realizing" a micro frontends architecture rendered server-side thanks to Blazor Server.

In this regard on Martin Fowler's blog there is a nice article by Cam Jackson in which an overview of this architecture is given and from which I have translated their definition of micro frontends

An architectural style where independently deliverable frontend applications are composed into a greater whole.

-- Thoughtworks su martinfowler.com

I put realize in quotes since the deployment of the various sites would only ever be done in a unified manner.

Perhaps we would address this issue in a future post.

Not all donuts come out with a hole.

Don't you know what it means?
A clear explanation of what this Italian saying means I found in Clozemaster at point 4.
Anyway, in two words it means that despite failure there is still something left to eat!

Getting straight to the point, the main reason for the failure is related to the inability to give complete autonomy to the teams, for two main distinct reasons.

Homonymy in support for pages and views Razor.

To compose the site each frontends is contained within a Razor class library which also holds the view that is responsible for doing hosting of the Blazor application.

This is made possible by the functionality exposed by the SDK that allows a web app to use Razor views, pages, or layouts from class libraries and, as defined in the official documentation, in case of homonymy, precedence is given to the view, page, layout present in the web app.

In my case I am in a situation like this

where both modules internally make use of layouts contained at the /Pages/Shared/_Layout.cshtml path.

Here, what would happen in this case is that one of the two teams would be displeased since, if it went well it would see its application rendered inside another layout, in the worst case one part or all of the views would go wrong (e.g., a view tries to enhance a section not declared in the layout).

And we note well that both modules executed independently would behave as expected.

Routes, the basic route that does not want to work.

I have that at least I could not get it to work.

Again, following the principle of autonomy, the desired was to separate the module routes from the container routes, for example within Module A we would find / or /index while from the container perspective the routes would be /module-a/ or /module-a/index.

What I found was a "short blanket," when internal navigation within the module worked, route generation using Anchor Tag Helper did not work (remember that this spike is the result of a migration process), as I used the middleware UsePathBaseMiddleware for the implementation of the requirement.

This resulted in the generation of links within the module to the outside always adding the /module-a at the top of the address even as the link should have simply pointed to the container.

Otherwise using middleware I would have been forced to use the module name at the top of all @page directives.

Conclusions.

Summing up what has been done and reasoning with a cool mind I could say that something good we can still take home, in fact, by not enabling support for Razor pages and views in a RCL³ and avoiding the use of Anchor Tag Helper in the HTML markup that contributes to view rendering we would not run into these problems.

A spike is a product development method originating from extreme programming that uses the simplest possible program to explore potential solutions. Source Wikipedia. ↩
Modular programming is a software design technique that emphasizes separating the functionality of a program into independent, interchangeable modules, such that each holds everything necessary to execute only one aspect of the desired functionality. Source Wikipedia. ↩
Razor Class libraries (RCLs) were introduced in ASP.NET Core 2.1 as a way to package and distribute UI components to be referenced and consumed within a host application. ↩

That time I tasted a frog

Nicola Biancolini — Fri, 18 Feb 2022 21:52:58 +0000

I started working in remote mode in March 2020, the reason I guess we all know.

However, if an extra-terrestrial were to read this post, he can find more information here https://wikipedia.org/wiki/COVID-19.

My experience has been the same as that of so many others, a maximum and indiscriminate use of communication platforms and smoking ears at the end of the day.

This working mode went on for about a year and a half, 16 months to be precise, until July 2021 when I joined managed/designs.

Here I found a different environment, which some would call smart. Devoted to personal growth and continuous improvement where autonomy and trust are two pillars on which the daily collaboration is based.

Prologue.

I've never been a user of to-do lists, perhaps due to inexperience or perhaps due to some belief unknown to me. The fact is that the systematic failure to follow the shopping list is proof of it "Nicola is not able to manage the lists".

Once I became aware of this, I started looking for possible patterns and/or methodologies by identifying some that have accompanied me for a couple of months.

My inbox is not the email.

I realized that what I need is not a list of tasks to do but rather a list of things that I would like to do or that somehow pique my interest. I suspect that on a subconscious level, my brain takes optimistically to the presence of that "would like" that removes the pressure for things that shouldn't be there.

I have three emails, the corporate one and two other historical ones that I've been carrying around for at least a decade, all three of which follow the philosophy of Inbox Zero by Merlin Mann. I currently flip through them twice a day, roughly before lunch and before the end of the day, these slots are recurring appointments on the calendar until next June 29, so we'll see if they will be extended, but I think so.

The rule is very easy:

it is important and must be executed at a specific time: an appointment is created on the calendar and archived in the corresponding inbox
it is important: it ends up in the inbox and archived
it interests me: it ends up in the inbox and deleted
it doesn't interest me: it ends up in the trash

In this way, I always have free inboxes and can keep my attention on those ten or so emails.

If an email comes in requesting an active response, I won't run it right away, but like the others, it will follow the rules above.

One frog a day is enough.

The other enlightening technique for me was the discovery of the 1-3-5 rule¹ based on the practice of eating a frog as soon as you wake up². Obviously not physically, I never want to wake up, and I've also been getting very little sleep lately!

So the day before I make a list of what I'd like to do the next day, applying some sort of empirical prioritization of activities of the moment while always making sure there's at least one frog and possibly other filler activities.

Epilogue.

I have to be honest, at first I was skeptical about taking the time to plan my tomorrow. I have to reconsider. The benefits of freeing my brain from the burden of thinking about what to do so that I don't run the risk of losing it forever is something to be reckoned with.

Right now, the rigidity of the calendar and the flexibility that the 1-3-5 list leaves me with are a good match. Only time will tell if it is a winning choice for me.

Why You Never Finish Your To-Do Lists at Work (And How to Change That) by Alex Cavoulacos ↩
Eat That Frog: Brian Tracy Explains the Truth About Frogs by Brian Tracy ↩

Develop integrated solutions with Active Directory B2C and Azure Event Grid.

Nicola Biancolini — Fri, 14 Jan 2022 11:35:52 +0000

We will see how it is possible to create a solution that integrates Azure Active Directory B2C to save on Blob Storage dummy data at user registration.

Solution overview.

The solution is composed as follows:

read-customer-details-identity-la: represents the API whose purpose is to retrieve the content of the blob from customersstgacc (the storage account)
customer-register-tpc: is the topic in which are collected the events of the creation of a new user
customer-identity-details-filler-la: it represents the API that is in charge of generating fictitious data that will be saved inside a blob on the customersstgacc
contoso-b2c: is the access and identity management service offered by Azure

Introduction to Azure Event Grid.

In Azure there is an implementation of the publish/subscribe pattern designed to facilitate integration and resource management via an event-driven development paradigm.

Through the Event Grid will be possible to subscribe to built-in message sources via a set of handlers.

If this is not enough, it is possible to create custom _topics to which you can subscribe to receive events.

Creating a custom topic.

You can refer to this guide to create a topic.

One choice to make when creating the topic concerns the scheme of the HTTP request content used. Currently, supported schemas are:

Event Grid Schema
Cloud Event Schema
Custom Input Schema this schema will require the creation of an association between the properties of the input object and those required by the Event Grid Schema

The message used in this case has the following structure

[
    {
        "data": {
            "objectId": "25100647-0dcc-4571-b7b4-b03e4ce72d02" // unique user identifier
        },
        "id": "25100647-0dcc-4571-b7b4-b03e4ce72d02", // unique message identifier, the same of `data.objectId` in this case
        "eventType": "Microsoft.ActiveDirectory", 
        "subject": "contosob2cqtofmpm.onmicrosoft.com",
        "dataVersion": "1.0",
        "metadataVersion": "1",
        "eventTime": "2021-12-03T21:04:03.8504745Z",
        "topic": "/subscriptions/{your-subscription-id}/resourceGroups/{your-resource-group}/providers/Microsoft.EventGrid/topics/{your-event-grid-topic}"
    }
]

Issuing the registration event.

Sending events to the topic is done using a RESTful technical profile.

<TechnicalProfile Id="AAD-UserEmitRegistrationEvent">
    <DisplayName>Emit user registration event to Event Grid.</DisplayName>
    <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.RestfulProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
    <Metadata>
        <Item Key="ServiceUrl">{Settings:CustomerRegisteredTopicUrl}</Item>
        <Item Key="AuthenticationType">ApiKeyHeader</Item>
        <Item Key="SendClaimsIn">Body</Item>
        <Item Key="ClaimUsedForRequestPayload">userRegisterEvent</Item>
        <Item Key="DefaultUserMessageIfRequestFailed">Cannot process your request right now, please try again later.</Item>
    </Metadata>
    <CryptographicKeys>
        <Key Id="aeg-sas-key" StorageReferenceId="B2C_1A_CustomerRegisteredTopicSas" />
    </CryptographicKeys>
    <InputClaimsTransformations>
        <InputClaimsTransformation ReferenceId="GetSystemDateTime" />
        <InputClaimsTransformation ReferenceId="GenerateRegistrationEventRequest" />
    </InputClaimsTransformations>
    <InputClaims>
        <InputClaim ClaimTypeReferenceId="userRegisterEvent" />
    </InputClaims>
    <PersistedClaims>
        <PersistedClaim ClaimTypeReferenceId="systemDateTime" />
    </PersistedClaims>
    <UseTechnicalProfileForSessionManagement ReferenceId="SM-AAD" />
</TechnicalProfile>

This fragment of markup translated into curl command, for more explicability, would look like this:

curl -X POST -H "aeg-sas-key: $key" -d "$event" $endpoint

where the authentication requirements are met by the AuthenticationType metadata to which is associated the cryptographic key aeg-sas-key whose value is retrieved from the key B2C_1A_CustomerRegisteredTopicSas present in the collection of policy keys.

"TL;DR"
The choice of the topic template in this example was guided by the limitations currently imposed by the RESTful technical profile regarding the possibilities of building the HTTP request, in fact for a combination of criteria it is not possible to pass information in the headers and the body of the request at the same time.

This makes it impossible to send towards a topic schemes of type Cloud Event since the protocol, in version 1.0 requires the presence of a mandatory header.

Much more complex is the creation of the body of the request for which it is necessary:

use the InputClaimsTransformation
add two statements inside the baggage userRegisterEvent and systemDateTime both of type string.

Finally, the technical profile has been added among the technical validation profiles of LocalAccountSignUpWithLogonEmail so that the event is issued only when a user is registered.

Using claim transformations.

During the creation of custom criteria we could have the necessity to execute calculations, as the number of attempts of authentication, that even if very simple would result impossible without the execution of functions.

This requirement finds expressivity through the ClaimsTransformation whose reference of the transformations of the claims contains the complete list of the transformations usable.

In the example the methods GetCurrentDateTime and GenerateJson were used

<ClaimsTransformation Id="GetSystemDateTime" TransformationMethod="GetCurrentDateTime">
    <OutputClaims>
        <OutputClaim ClaimTypeReferenceId="systemDateTime" TransformationClaimType="currentDateTime" />
    </OutputClaims>
</ClaimsTransformation>

The purpose of GetSystemDateTime is to enhance the systemDateTime claim.

<ClaimsTransformation Id="GenerateRegistrationEventRequest" TransformationMethod="GenerateJson">
    <InputClaims>
        <InputClaim ClaimTypeReferenceId="objectId" TransformationClaimType="0.data.objectId" />
        <InputClaim ClaimTypeReferenceId="objectId" TransformationClaimType="0.id" />
        <InputClaim ClaimTypeReferenceId="systemDateTime" TransformationClaimType="0.eventTime" />
    </InputClaims>
    <InputParameters>
        <InputParameter Id="0.dataVersion" DataType="string" Value="1.0" />
        <InputParameter Id="0.eventType" DataType="string" Value="Microsoft.ActiveDirectory" />
        <InputParameter Id="0.subject" DataType="string" Value="{Settings:Tenant}" />
    </InputParameters>
    <OutputClaims>
        <OutputClaim ClaimTypeReferenceId="userRegisterEvent" TransformationClaimType="outputClaim" />
    </OutputClaims>
</ClaimsTransformation>

GenerateRegistrationEventRequest has instead the burden of constructing the JSON and enhancing the userRegisterEvent claim.

Conclusions.

In this article, we have seen how through Identity Experience Framework it is possible to integrate a B2C tenant with our infrastructure and open possible interesting development scenarios.

To do this we touched on Azure Event Grid and how to create an Event Grid Topic.

Finally how you can manipulate attestations and use them within technical profiles.

If you are interested in the complete example you can find it at https://github.com/binick/samples/tree/master/src/enrich-a-jwt-token-with-ief.

How to include code coverage in Azure DevOps pipeline?

Nicola Biancolini — Sat, 16 Jan 2021 19:20:32 +0000

By code coverage we mean the action of trying to measure how much of our code has been executed by our tests.
This sound like

TL;DR

Untested code is a broken code.
Definitely a strong statement but true in a way, we don't always manage to get enough coverage.
Often this happens because we don't have time, other times because despite having written tests we are not able to read the metrics.

So, how we can "humanize" code coverage metrics? And how we can generate its?

To answer at these questions I usually use two libraries.

coverlet-coverage / coverlet

Cross platform code coverage for .NET

to gather metrics, and

danielpalme / ReportGenerator

ReportGenerator converts coverage reports generated by coverlet, OpenCover, dotCover, Visual Studio, NCover, Cobertura, JaCoCo, Clover, gcov or lcov into human readable reports in various formats.

for generate human-readable reports.

How can set-up coverlet?

I usually include coverlet.msbuild by MSBuild .targets Files - Visual Studio | Microsoft Docs.

For alternative ways to include coverlet into yout test project see also coverlet-coverage/coverlet: Cross platform code coverage for .NET (github.com).

How can set-up ReportGenerator?

In keeping with above to include ReportGenerator by MSBuild .targets Files - Visual Studio | Microsoft Docs.

Also this tool offer a various way to use it, you can find all ways onto official documentation ReportGenerator - converts coverage reports generated by coverlet.

How to wire-up all that?

To make everything work we need to add another MSBuild file.

And include this into your test project, something like this

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>net5.0</TargetFramework>
  </PropertyGroup>

  <Import Project="Tests.targets" />

</Project>

Now everything you are able to run dotnet test you will able to inspect and analyze something like this

I think that is an amazing tool to understand at a glance which codes are covered and which not.

And now, how I can put it into Azure DevOps pipeline?

It would be nice if this report came was published into the Build pipeline report, don't you think? Maybe even include branch policies for it.

Well that's possible by use Publish Code Coverage Results task, something like this:

- task: PublishCodeCoverageResults@1
  displayName: Publish Code Coverage Results
  inputs:
    codeCoverageTool: 'cobertura'
    summaryFileLocation: '$(Build.SourcesDirectory)/artifacts/TestResults/$(_BuildConfig)/Reports/Summary/Cobertura.xml'
    continueOnError: true
    condition: always()

We notice the summaryFileLocation argument, this means that we will push only one file to Azure DevOps why?

One unwrite note of Publish Code Coverage Results task or limitation, I don't know, is that the sum of covered lines, when we publish more reports, is take from the first file

This results in an unreliable result.

To fix that problem we can marge multiple reports into a summary reports so that can be publish it only one. One way to make it is the follow

and run MSBuild project into the pipeline with

- script: dotnet msbuild SummaryReportGenerator.proj /p:Configuration=$(Configuration)
  name: GenerateCodeCoverageSummary
  displayName: Generate code coverage summary

Once you've done this the sum of covered lines on Build pipeline will true.

SqlServer, EFCore, JSON 👀

Nicola Biancolini — Thu, 22 Oct 2020 18:10:35 +0000

Sometimes we have been forced to work with json stored on table columns, it will have happened to you too!.

In this post I want to show you how work with that using EntityFramework Core

dotnet / efcore

EF Core is a modern object-database mapper for .NET. It supports LINQ queries, change tracking, updates, and schema migrations.

Clearly this is one of many possible ways.

We could talk for a long time about the choice to store JSON into RDBMS is a good or bad choice, but the intent of this post isn't make rant.

Ok, well. First of all take a look to JSON that we want to persist into table column

Our application has a requirement that makes it necessary to query the database with the name of the retailer that has stored in the JSON.

The retailer is the one who has the car we want to rent.
The car is represented by the class

The Car entity has a property public string NameOfRetailer { get; } that is computed by the Computed columns functionality.

With this instruction efcore will inflate property with value returned by JSON_VALUE(Metadata, '$.Retailer.Name') expression, for more information about JSON_VALUE see at JSON_VALUE

To make it work, we need to persist the JSON into table column Metadata.

We can use the other usefull Value conversions functionality of efcore.

Now, after that model configurations we are able to resolve this simple query var car = await context.Cars.MaterializeAsync(car => car.NameOfRetailer == "Car Auto Orvieto").ConfigureAwait(false); without materialize the entire dataset on the client. 🚀

If you want to learn more you can find the sample on my github repo ef-core-json

Happy coding!🐱‍👤