DEV Community: gopkumr

Move azure resources between resource groups

gopkumr — Tue, 12 Oct 2021 06:20:59 +0000

Problem

While working with Azure cloud platform, often there will be instances where resources needs moving across resource groups for maintenance reasons or because of re-organizing of products. There might even cases where the resource may need to be moved across subscriptions.

Solution

In Azure resources can be moved across resource groups from the portal UI or Azure CLI or powershell or from the rest APIs. Moving the resource using the portal UI is as easy as going through a wizard like steps and clicking finish at the end of it. The process also validates if the resource can be moved or not, for example an Azure SQL Database cannot be moved without moving the SQL Server instance, and when a SQL Server instance is moved across, all the databases gets moved automatically.

From the UI, there are three ways of getting to the wizard.

Azure Resource Mover service
Move option at the top of the Resource Group Screen
Move option at the top of the Resource Screen.

All the above options lead to the same wizard screen when you can choose the destination subscription and resource group and initiate the move. This will validate if the resource support moving as well as if all the criteria is satisfied for the resource to be moved.

You can find all the information regarding what resources currently support moving here. Also the criteria that any resource that supports moving needs to satisfy to be able to move can be found here

The move does not copy over the role assignments to the destination resource, so all the role assignments will have to redone after the move is completed. There is no downtime to the usage of the resource, but the resource will be locked for few hours to any changes even though the move is completed in lesser time.

Powershell command Move-AzResource can be used to execute the move from Powershell

Azure CLI command az resource move can be used to execute move from any CLI that has Azure CLI installed.

Rest Endpoint POST https://management.azure.com/subscriptions/{source-subscription-id}/resourcegroups/{source-resource-group-name}/moveResources?api-version={api-version}

Details Here can be used to trigger the source move passing the payload with resources ids and the target resource group names.

{
 "resources": ["<resource-id-1>", "<resource-id-2>"],
 "targetResourceGroup": "/subscriptions/<subscription-id>/resourceGroups/<target-group>"
}

The Azure resource mover also bring in the capability of moving the resources across regions more about it can be found here

Cloud Resume Challenge - Azure Serverless

gopkumr — Sun, 27 Jun 2021 23:18:48 +0000

I recently came across the site https://cloudresumechallenge.dev/ and decided to give it a try using Azure services. To start simple I decided to ignore the DB, CDN part etc and just have the the UI and the middler layer of the app. Below is the high level architecture.

The front end of the app will be hosted a static web site in Azure Blob storage. Backend will be an Azure function that will feed the resume data to the frontend over HTTP, the azure function will be a HTTP triggered function.
Currently the resume data in JSON format hardcoded in the Azure Function code. As an upgrade to the app, the JSON data can be moved to a CosmosDB instance and put an Azure CDN in front of the UI to deliver content fast to users.

Development Environment

Frontend: Blazor WebAssembly
Backend: Azure Function using C# (Function Auth)
IDE: VS Code
IAC: Azure ARM Template
Source Control: Github
CI/CD: Github Actions

The App project

The project is divided into 3 parts.

Core: A dotnet standard 2.0 library project that contains all the entities used in the application. It also contains the interfaces and implementation of services, the classes that contains all the logic to get the data ready for the caller.
Created using

dotnet new classlib --framework netstandard2.0

The one service class that currently resides in the core project is the ResumeService, which calls the Function backend and deserialized the JSON to its class instance and return. This service is injected in the frontend to complete the rendering the data.

Frontend: Blazor WebAssemly project, which contains all the UI rendering logic. The projects refers to the Core project to get the resume data.
Created using

dotnet new blazorwasm --framework net5.0

For now the function will respond to HTTP calls with a JSON representing the resume data.

Backend: Azure Function project
Created using

func init backend --dotnet func new --name backend --template "HTTP trigger" --authlevel "function"

Infrastructure as code (IAC)

The infrastructure for deploying the application is coded using Azure Resource manager template for repeatable deployment, this makes it east to setup an azure environment quickly and without human errors. Also the infrastructure can be version controlled reviewed and provisioned as part of the CI/CD pipeline.

referred the Azure ARM template quick start github here to get started with the azure services.

The ARM template has the Azure Static website and Azure Function configured.

CI/D

There are two github actions workflow, one is to deploy the infrastructure and another to deploy the code. The infrastructure is deployed manually as we don't want to spin up new infrastructure element automatically on any event. The
source code gets deployed on any commit on the master branch in the github repository.

Deploying Infrastructure

To execute the workflow on Azure, we need to register github actions as an Azure AD and use the client credentials authentication flow to get access to create resources. Also, while creating a service principle for github actions, give permission on to one resource group to have maximum restrictions on.

use the below command to create an Azure service principle and copy the returned JSON into Github secrets of your repo and call it AZURE_CREDENTIALS. substitute the subscription id, resource group name and the app name.

az ad sp create-for-rbac --name ResumeAppGithub --role contributor --scopes /subscriptions/{subscriptionId}/resourceGroups/{MyResourceGroup} --sdk-auth

In the YAML file to deploy the ARM template we use the azure/arm-deploy@v1 which taken in subscriptionid and resourcegroupname as input, so store those too in the repo secret so that you don't have to expose the values into the code.

You can check the ARM template here and the YAML file to deploy it here

Deploying the backend azure function

Deploying the function app is easy as the github action can already login to Azure as an app. So all we are have to do is publish the app and upload it to the function service using the Azure/functions-action@v1 action.

You can check the yaml file here.

Deploying the frontend static web app

Deploying Blazor project follows two steps, one is to publish the project and next is to upload all the published files to the static web app. Both these tasks can be done by using the Azure/static-web-apps-deploy@v1 action, which uses microsoft/oryx to build the Blazor project and copy over the content to the azure static app website.

You can check te yaml file here

Conclusion

The app currently implements just an azure function that returns a hardcoded JSON data that represents the resume and a Blazor app thats deployed on azure static web app to render the resume.
The next revision of the app would be to add a Azure CDN service to cache the resume UI and also to return the content faster to whoever accesses it from where ever in the world. Azure function returns a hard coded JSON string which needs a change and have the resume stored as a document in the document in cosmos DB.

The full source code, IAC templates and the actions YAML files can be found in the github repository

Implementing custom feature flags - Azure App Configuration

gopkumr — Mon, 21 Jun 2021 23:18:48 +0000

This is a continuation from the previous article on feature flags implemented using Azure App configuration service to maintain the flags. Just to reiterate, feature management can be implemented using config files but this article is trying to implement feature flags connecting to Azure App configuration service.

Introduction

The previous article described about implementing a boolean feature flag to turn on/off a feature. In this article I am trying to implement a custom feature flag. Microsoft provides few predefined custom feature flags or feature filters (as they are called) Targeting, TimeWindow, and Percentage (more about it here), which covers most usecases, however, there might be situations where you find the predefined ones falling short. In this article I am building a filter ground up with a made up custom logic.

Code Updates

Create a customer filter is as simple as creating a class and implementing the Microsoft.FeatureManagement.IFeatureFilter, override the EvaluateAsync method add the logic to decide if feature should be enabled. Thats it! What i want to show is how do we wire up this class into the application flow and configure the flag in Azure app configurations.

Below is our feature filter class and some supporting class for logic implementation



//The feature filter will be known my this name in the configuration.
[FilterAlias("ShortTimeFeature")]
public class SecondsFeatureFilter : Microsoft.FeatureManagement.IFeatureFilter
    {
        private readonly IMinuteFeaturePropertyAccessor minuteFeatureContextAccessor;

        //The IMinuteFeaturePropertyAccessor is an implementation that I have used to capture first load 
        // time of the application. The IMinuteFeaturePropertyAccessor is loaded as a singleton in DI.
        public SecondsFeatureFilter(IMinuteFeaturePropertyAccessor minuteFeatureContextAccessor)
        {
            this.minuteFeatureContextAccessor = minuteFeatureContextAccessor;
        }

        public Task<bool> EvaluateAsync(FeatureFilterEvaluationContext context)
        {
            //The logic is to disable the feature after configured seconds the user has used the application
            //The seconds is configured as parameter in the feature flag.
            var EnabledSeconds = int.Parse(context.Parameters.GetSection("EnabledSeconds").Value);
            if (DateTime.Now.Subtract(minuteFeatureContextAccessor.GetStartTime()).TotalSeconds > EnabledSeconds)
            {
                return Task.FromResult(false);
            }
            return Task.FromResult(true);
        }
    }

    public class MinuteFeturePropertyAccessor : IMinuteFeaturePropertyAccessor
    {
        readonly DateTime startTime;
        public MinuteFeturePropertyAccessor()
        {
            startTime = DateTime.Now;
        }

        public DateTime GetStartTime()
        {
            return startTime;
        }
    }

    public interface IMinuteFeaturePropertyAccessor
    {
        DateTime GetStartTime();
    }

Once the feature filter is create, it needs to be added into the feature management middleware. The middleware will make sure that the filter class is invoked when the flag check is triggers in the application flow (navigation link, action filter, filtermanager check).

Below the configure service method, where the feature filter is added as well as the supporting classes in my sample.



 public void ConfigureServices(IServiceCollection services)
        {
            services.AddSession();
            services.AddHttpContextAccessor();
            services.AddControllersWithViews();
            services.AddSingleton<IMinuteFeaturePropertyAccessor, MinuteFeturePropertyAccessor>();
            services.AddFeatureManagement().AddFeatureFilter<SecondsFeatureFilter>();
            services.AddAzureAppConfiguration();
        }

The ways feature flag can be used in the app is exactly same as described in the previous article. The feature flag is going to called TimeLimit. example code is as below



 [FeatureGate("TimeLimit")]
 public async Task<IActionResult> Index()
    {
        return View();
    }

Rest of the startup and program class will be same as the previous article, which basically implements Azure app configuration integration.

To create the configuration entry in Azure, we use the feature explorer in Azure App configuration service.

Add a feature flag, enter a feature name same as what was used in the code TimeLimit and check Use feature filter and select Custom.
In the custom feature filter name, enter the FeatureFilter name as given in the FeatureFilter alias attribute ShortTimeFeature.
Click the three dots and edit parameters and enter the parameter name and value used in the feature filter implementation EnabledSeconds and 60 Also, remember to have the Azure App Configuration connection string to be added/updated in the config filer of the application and make sure that the feature flag is enabled in the feature explorer.Now we have wired up the feature flag and dependent configurations and the app is ready to executed.

Conclusion

This code now will make your feature enabled for 60secs after the user has opened the application. Post 60secs the feature will get disabled, like short preview of a beta code. As mentioned earlier this is just to demonstrate how easy it is to implement a custom feature flag and control features based on different business needs.

Implementing feature flags - Azure App Configuration

gopkumr — Sat, 15 May 2021 23:00:48 +0000

Feature flag is a very popular practice in modern application development, which is used to specifically hide features implemented that are not yet ready to be used by wider audience, and when ready can be enabled by a flip of a switch. The flags can also be used as a kill switch for application feature when it not working as expected.

With feature flags implemented, it would be effective to have the features enabled or disabled from a location outside of the application infrastructure or configuration, this way we can have features spanning across applications be controlled via a centralized flag. Azure has feature management as part of the Azure App configuration service which can manage feature flags and maintain it separate from your hosting model and will act as a centralized repository for feature flags. Microsoft also provides libraries for different programing languages to consume Azure App Configuration service. More about it can be found here

Creating Azure App Configuration

To start with, create the App Configuration service in Azure. For trying out the service, I will use the free tier.

Once the service is created, In the left panel, under operations section, we can navigate to the Feature Manager screen and create a flag. The flag creation is as simple as giving a name to it. The screen also gives an option to create the flag as a FeatureFilter, which is used when the flag is not just a boolean value and you want to control the flag based on other criteria like a subset of users or switching a flag on/off for a time frame. We will keep the details on FeatureFilter for another post.

Once the flag is created, it can be toggled from the feature manager screen.

Note the connection string to the Azure AppConfiguration service, which we will use in our app to connect.

Consuming Azure App Configuration in a WebApp

I am implementing a simple web application using ASP.Net Core MVC default app to consume the app configuration service. Adding a view and a controller for the new feature called Feature1. The feature for now will only have a single index page which displays the feature name. Add the feature link to the navigation menu too. While the Microsoft FeatureManagement libraries in aspnetcore can work with flags stored in application's local config files or a database, here I am trying to have it work with the azure app configuration service.

To consume azure app configuration service we need add the below nuget package

Microsoft.Azure.AppConfiguration.AspNetCore

aspnetcore feature management requires the below nuget pacakge

Microsoft.FeatureManagement.AspNetCore

Add the Azure App Configuration connection string to the appsettings.json connection strings section with a key, I will use AppConfiguration .

To add the App Configuration from azure into the application, update the program.cs file CreateWebHostBuilder configuration. Within the configurewebhostdefaults method, add code to configure custom configuration source using ConfigureAppConfiguration method.

Within the method, retrieve the azure app configuration connection string from the appsettings.json and add the azure app configuration as a configuration source using AddAzureAppConfiguration method, also enable Feature flags.

Add the feature management to the dependency container using AddFeatureManagement in the configureservices method in startup.cs.

Once the setup is done there are few ways the feature flags can be used in the application code.

Action filter

An action filter FeatureGate("<feature name>") can be used to prevent the action from getting triggered if the feature name passed to the filter is not enabled in the Azure App Configuration.

Feature Manager Service

If the requirement is to stop execution of a logic based on the feature flag, then a service of type IFeatureManager can be injected in the controller and methods like IFeatureManager.IsEnabledAsync("<feature name>") can be used to check if the feature is enabled.

Navigation Links

By adding tag helpers from @addTagHelper *, Microsoft.FeatureManagement.AspNetCore gives the tag <feature name="<feature name>"> to be used around links or buttons or sections, so that the content of the feature tag is not rendered when the feature specified in the name attribute is not enabled.

Doing the above will let you switch on/off the feature in azure and the application will respond to it by removing the link from navigation as well as responding with a HTTP 404 if user tried to access the link directly. With the above implementation,the app needs to be restarted if the flag changes needs to get reflected, as the azure config is loaded only once when the app is launched. To have the config refreshed when it is changed in azure, we need to register a refresh for the azure configuration. Below is how we will do it.

First, the change to the code

Here the application monitors the RefreshKey for any change every 5 seconds (as specified in the cache expiry timespan), when a change in RefreshKey is noted all azure configurations are refreshed from the service for all keys (specified by refresh all flag).
The refresh key is created as a key-value in the app configuration explorer in azure app configuration.

For the refresh to work, we need to add the AzureAppconfiguration middleware by making the below changes in startup.cs

After this is implemented, you can update your feature flag and modify the feature key, which will cause the app to get the updated feature flags. Advantage of using a refresh key is that, one single key change can trigger refresh of all the feature flags configured. Alternatively, you can register refresh for individual keys which can be set to refresh only those keys that have been updated.

Radio Player using Blazor 5

gopkumr — Tue, 11 May 2021 06:35:28 +0000

I have been reading the Blazor 5 documentation and decided to create a simple project to give its features a try. As always, there were a ton of ideas in my mind but while scanning through dev.to i came across a post by Aleks Popovic, where he made a Radio player using react, so i decided to create one using Blazor 5. I used the same service as Aleks to get the radio stations, called the Radio-Browser.

First step was a to choose a suitable UI which is simple and easy to use as a radio. I borrowed the style of the player from a codepen.io sample for music player. With the UI design out of the way, it was time to create a component and wire up the code to fetch and play radio stations.

To keep it simple the project currently list a set of predefined genre and fetch stations for a selected genre and display it as a list. The user can choose the station and they listen to it.

State persistence

The list of genre is contained within its own component called LeftNavMenu. This component is included within the main layout page which renders the player component. The selected genre is maintained by an in-memory state container. The state container is used by both the LeftNavMenu component and the Player component to share the selected genre. When user selects a different genre from the LeftNavMenu the value in the state container is updated and action is triggered to notify the player component of the change. This approach can be used to share state between nested components or independent components.

The state container is configured as singleton instance in the service collection dependency container which is injected in all the Blazor components and used.

Cascade Values and parameters

The index component is the first component that is loaded and it contains the Radio player component. During initialization of the index component the radio server API is triggered to fetch all the radio stations for the selected genre. The fetched radio stations list is passed onto the Radio player component as a parameter, the first station of the list is passed into the radio player as a cascade value. The difference between the two is that cascading values can be passed onto to all the components within the CascadeValues section, where as for parameters the values would need to be passed to individual components.

CSS Isolation

One issue with CSS is bleeding of style, where style applied in one of the component affecting other components rendered in the same page. This was the issue with the genre LeftNavMenu component. As a was to get around this problem, blazor has introduced CSS isolation where you create a css file along with the component file and name the css file as .razor.css. The component styles are rewritten during compile time by appending a unique identifier to the css properties as well as to the HTML elements in the component UI.

HTML
<li b-3xxtam6d07>

CSS
li[b-3xxtam6d07]{
    color:red;
}

All the component styles are then bundled and included inside the www\index.html head tag as .styles.css.

These were the 3 of the new features that are used in this project and there are more, there are also other features like JS Interop, event handling used within the project which were part of the initial Blazor.

The source fot the project is available in github project, feel free to take a look and give suggestion.

Switch off auto formatting in Visual Studio 2019

gopkumr — Tue, 16 Feb 2021 21:51:19 +0000

If you have landed here searching how to switch off auto formatting of code files in Visual Studio, you are either a code purist who does not like the formatting the IDE is performing or you are like me editing a large auto-generated class file (due to unfortunate situations) and Visual studio hangs or crashes on you every time you do a small change. The good news is there is an option in the IDE to switch feature off.

Tools > Options > Basic > Advanced > Editor Help Section > Pretty listing (reformatting)of code

Steps for Deploying a Blazor as Static Site with Docker and Nginx

gopkumr — Thu, 11 Jun 2020 10:07:44 +0000

Step 1 Publish the Blazor WebAssembly project

Publish the project from Visual Studio,this ensures that the projects is linked which removes all the unwanted dependencies from the output, reducing the size of the assemblies created.

Step 2 Create a dockerfile

The docker file is very straightforward, pull the nginx image and copy the published Blazor WebAssembly file from the WWWRoot folder to the html folder in nginx

FROM nginx:alpine
EXPOSE 80
COPY bin/Release/netcoreapp3.1/publish/wwwroot /usr/share/nginx/html

Step 3 Build the docker image

use the below command

docker build --tag blazorstatic .

Step 4 Run the docker container

Run the docker container mapping the port exposed from the container to a port on the host

 docker run -p 8080:80 blazorstatic

Step 5 Access the Blazor WebApp from browser

Access the URL https://localhost:8080 which loads the WebApp

Source code for both ASPNet hosting and Static Website Hosting is available in Github: https://github.com/gopkumr/BlazorTourOfHeroes.git
Branch: Perf

Hosting Blazor WebAssembly on ASP.Net Core WebAPI

gopkumr — Tue, 09 Jun 2020 09:31:24 +0000

Background

My WebAssembly project has now been configured to be a PWA (refer the previous article in series). It time to introduce hosting. Since the WebAssembly project handles the client side, I want it to be unchanged but be hosted it in a project that can be used as backend for the UI, hence chose WebAPI.

The Changes

Create a new solution and add the already created Blazor WebAssembly project
Add a new ASPNet core web project and choose WebAPI template and call it the .Server project
Add reference of the WebAssembly Project to the .Server project.
Install package Microsoft.AspNetCore.Components.WebAssembly.Server to the .Server project. This package contains the runtime server for Blazor application.
In the startup class add configuration to the request pipeline to handle Blazor and its routing.

// This methods serves the WebAssembly framework files when a request is made to root path. 
//This method also take path parameter that can be used if the WebAssembly project is only served 
//from part of the project, giving options to combine web assembly project with a web application

app.UseBlazorFrameworkFiles();

//This configuration helps in serving the static files like 
//Javascript and CSS that is part of the Blazor WebAssembly

 app.UseStaticFiles();

//Add the below configuration to the end of the UseEndpoint configuration, 
//this will serve the index.html file from the WebAssembly when the WebAPI route 
//does not find a match in the routing table

 endpoints.MapFallbackToFile("index.html");

Your ASPNet Core hosted WebAssembly project is ready to be published and deployed. Pretty easy!

Next would to move some of the data source maintained in the WebAssembly to the WebAPI Server and use an HTTP call to retrieve it.

Source Code: https://github.com/gopkumr/BlazorTourOfHeroes.git
Branch: Perf

How can I turn my Blazor WebAssembly to PWA?

gopkumr — Thu, 04 Jun 2020 09:22:54 +0000

Lets get started with an existing Blazor WebAssembly project

I already have a Blazor WebAssembly project created implementing Angular Tour of heros application. You can find the project in my GitHub repository here
Repo: https://github.com/gopkumr/BlazorTourOfHeroes.git
Branch: Release

Next step is making this into PWA

As with any web application, adding PWA capabilities to Blazor follows the web standard process of adding a manifest json file and the service workers js file.

Manifest.json file specifies the PWA metadata like name, icon author etc
Service-Worker.js provides the offline capabilities. both these files were added to the wwwroot folder and included in the index.html page like below

<link href="manifest.json" rel="manifest" />
 <script>navigator.serviceWorker.register('service-worker.js');</script>

I have added the files to the project and it can be found in the same GitHub Repo but in a branch called PWA
Repo: https://github.com/gopkumr/BlazorTourOfHeroes.git
Branch: pwa

A little about the manifest.json file that i have include in the project

Now that we came to the topic of manifest.json below are the properties I chose to add to my manifest file.

short_name and name: short_name is used on the user's home screen, app launcher, or desktop. name is used when the app is installed.
icons: Set the icons for the browser to use on the home screen, app launcher, desktop etc.
start_url: The start_url tells the browser where your application should start when it is launched.
background_color: The background_color property is used on the splash screen when the application is first launched.
display: Used to customize what browser UI is shown when your app is launched. Below are the possible values
fullscreen: Opens the web application without any browser UI and takes up the entirety of the available display area.
standalone: Opens the web app to look and feel like a standalone native app. The app runs in its own window, separate from the browser, and hides standard browser UI elements like the URL bar.
minimal-ui: This mode is similar to standalone, but provides the user a minimal set of UI elements for controlling navigation (such as back and reload).
browser: A standard browser experience.
theme_color: The theme_color sets the color of the tool bar.

Offline capabilities

Adding the service-worker.js gives the app the offline capability that it requires to work like a native app.
When the app is launched the service worker will look for the page/component to be served from the cache, if it was not available in cache then it tries to reach the server for the request to be served. This is the strategy followed irrespective of connectivity being present or not.

Since this logic is baked into service worker js, if any URL in the app is to be always served from the server (like a server rendered page) then edits need to be done into service worker js onFetch method.

For any data that is served from the page will be directed to the server, so an offline capability has to be handled by the app developer either by using a localstorage or an indexDB for storing data at client side or presenting user with no connectivity message.

Reference links

All PWA concepts like manifest.json, service worker js, local storage, push notification are web standards independent of Blazor. Blazor has brought these webconcepts, webassembly and our beloved C# & Razor together.

Service Worker: https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API
Manifest.json: https://developer.mozilla.org/en-US/docs/Web/Manifest
Blazor: https://dotnet.microsoft.com/apps/aspnet/web-apps/blazor

An attempt to convert Blazor WebAssembly Project to Blazor Server App

gopkumr — Sat, 25 Apr 2020 02:02:19 +0000

Blazor Web-Assembly Project

This starts from my Blazor Web-Assembly project that I create as a replica of the Angular TourOfHeros tutorial. The source code of project is in GitHub

This is an attempt to convert the existing project to a Blazor server app with few changes to the wiring up and hosting configuration. Since this article is written with a pre-release version of Blazor Web-Assembly, there could be changes to the steps after the actual release expected in May 2020.

Framework updates

The WebAssembly project was create in Jan 2020 when the Blazor Web-Assembly project was in preview, hence i have to change the TargetFramework and few assembly references in the project file.

Updated Target Framework to netcoreapp3.1
Removed references to Blazor assemblies from .Net Core 3.1.0-Preview build
Removed RazorLanguageVersion specification

Hosting and Startup changes

We need to added references to couple of Framework assemblies, namely Microsoft.AspNetCore.App and Microsoft.NETCore.App which provides the BlazorServer components.

To wire up Blazor Server app we first need to configure the dependency injection container. This is done by adding server side Blazor service in startup class's ConfigureServices method
services.AddServerSideBlazor()
Also add support for Razor pages services.AddRazorPages(), because, our Blazor components are Razor pages.

Configuring the request pipeline

Unlike the Web-Assembly where we just bootstrap the first component and routing is performed at browser end, the Blazor server integrates with ASPNet Core routing and it uses BlazorHub to interact with Blazor components. For this we add the below configurations to the Configure method.

app.UseStaticFiles(); app.UseRouting(); app.UseEndpoints(endpoints => { endpoints.MapBlazorHub(); endpoints.MapFallbackToPage("/_Host"); });

All the requests are directed to a Blazor component based on the URL defined using the @page directive, any URL that does not have a match in the routing configured to directed to the fallback page.
The MapFallbackToPage is used to define the component to be loaded when the request does not match any URL. The host file is named _host by-convention also this route has a lower priority in the routing table, hence Blazor can be coexist with other ASPNet core pages/controllers without causing conflicts.

_Host file

Since the host file is loaded by default in our project (since we don't have any another routes configured), the code that we had in our index.html will need to be copied over to the host file along with couple lines of code modified.

The JavaScript file supporting web assembly needs to be changed to the one supporting Blazor server i.e. <script src="_framework/blazor.server.js"></script>
Rendering mode of the initial component to be changed to server-pre-rendered <app>Loading...</app> to <app> <component type="typeof(App)" render-mode="ServerPrerendered" /></app> We can pretty much bootstrap any component in the type attribute, we use the App component as it is our parent component which calls all the rest of the components.

And that's pretty much it. Your WebAssembly app should be able to running in a ServerRendered Blazor server mode now.

Both my WebAssembly and Blazor Server app code are available in GitHub

WebAssembly is in the master branch
BlazorServer is in the serverApp branch (which i branched out and modified)

Tired of updating namespaces? With VS2019 you won't.

gopkumr — Fri, 11 Oct 2019 09:26:47 +0000

Most of us programmers would have moved code files around to different folders at a different stages of the application development, this might be due to refactoring or redesigning or re-organizing. While moving around the code files, most .Net developers would have spent enough time changing the namespaces to match the folder structure (as better practice).

With Visual Studio 2019, this mundane task of changing the namespaces while moving folder is now automated, which means, visual studio updates the namespace to match the folder structure by itself.
Even if for some reason, you move the folder using the file explorer rather than the visual studio, in such case, you can go into the code file and you get an option to update the namespace to match the folder structure or change it any other existing namespace from your project.

Cool isn't it.

A brave move by Brave

gopkumr — Sun, 29 Sep 2019 09:48:58 +0000

Current online ads landscape
Advertisers and publishers are always in search of targeting the right user group and the actual presenting of ads to the user. Users are the most undervalued actor of the use case. The ads intrude into the viewing area, uses up bandwidth, make the overall experience poor. In most cases, the users enjoy the service for free by viewing the ads e.g. Youtube.

Brave browser has taken this use case and improvised to make it a win-win situation for all. Here is what Brave has done.

Brave Browser
Brave itself is an open-sourced browser specialized in ad and website tracker blocking and private browsing capabilities. And it does it efficiently.

Now to get to the technology behind brave.

Brave is Google's Chromium web browser like other browsers like chrome, partners with search engine DuckDuckGo. The browser has added Tor for private browsing. The browser has combined its capability with a blockchain-based platform to connect the advertisers with the consumers with no multilayered middlemen. The network that brave would connect to is the first of its kind blockchain-based digital advertising platform called TAP network. Braves network is based on Etherium blockchain and it uses a token Called Basic Attention Tokens (BAT) as the cryptocurrency for rewards for the users or viewers of the ads. The browser gives users an option to opt-in viewing ads and only those users will see ads as a notification separated from the content that they are viewing.

Brave Ads are shown to the user based on the data that is stored locally to the user's browser and hence it does not require a remote tracking system and users data to be sent out.
The browser also gives you the option to choose how frequently you want to view the ad.

This use-case of online advertisement implementation on top of a blockchain network is clearly a disruptive one that opens up a lot of possibilities. The token that users collect can be claimed back as any fiat currency or tip content writers, encouraging them to produce more quality content. At the time of writing 1 BAT (0.00093990 ETH) = USD 0.160672.