DEV Community: Alexey Zimarev

Hacking the ASP.NET Core React SPA template for Vue.js

Alexey Zimarev — Sat, 26 Jan 2019 22:04:56 +0000

ASP.NET Core SPA templates and Vue.js

Since version 2.1, ASP.NET Core has moved all SPA templates, previously available via the Microsoft.AspNetCore.SpaTemplates package, to the core repository. When that was done, all .NET developers that love VueJs were negatively surprises, since the Vue template was simply removed from the new set of templates. So, when you create a new ASP.NET Core Web Application, you have a choice between Angular, React
and React with Redux. The issue is described in details by Owen Caulfield in his post on Medium. Owen refers to the GitHub issue.

How to deal with that

Ideally, the .NET community needs to look at the issue and create a new template to address the issue. Below, I will go through the requirements for such a template and explain how to work around the problem before we get the template working.

The React template

Let's have a quick look at how the React+Redux SPA template works.

An application created with that template contains a folder in the web project that is called ClientApp. This folder is a home for the React application, which uses WebPack.

To build the SPA, there are some additional items in the csproj file. You can look at it youself since I will not include these items in the post for the sake of brevity. In short, there is one ItemGroup there to include the ClientApp folder as content to the output of the build, and two Target tags to execute npm at the build and publish stages.

There are also some lines of code in the Startup.cs file that are important to make the whole thing work.

First, in the ConfigureServices method we can find this line:

services.AddSpaStaticFiles(configuration => 
    { configuration.RootPath = "ClientApp/build"; });

and in the Configure method we have a few more lines too:

app.UseStaticFiles();
app.UseSpaStaticFiles();

// MVC configuration is skipped but still needed

app.UseSpa(spa =>
{
    spa.Options.SourcePath = "ClientApp";

    if (env.IsDevelopment())
    {
        spa.UseReactDevelopmentServer(npmScript: "start");
    }
});

Making it work with Vue

So, as we can see, there are no massive changes to the whole application setup to make the SPA work, and hence the UseReactDevelopmentServer accepts the npm command, it might be easily replaced to run another command instead.

Replace the client app

So, let's start by replacing the React app with the Vue app. To do that, I created a Vue app in another directory, using the vue create myapp command. I added some options like using TypeScript and PWA, but it doesn't really matter. The Vue CLI 3 only uses the WebPack configuration, so the whole build configuration of the ASP.NET Core application should work as before. To check if this is the case, I removed the content of the ClientApp folder in my .NET project and replaced it with the content of my new Vue application directory:

You can see that my ClientApp folder contains the Vue app instead of the React app. I can try building the whole solution now, and it builds as expected.

Middleware

However, if I run the app, I get an exception in the ReactDevelopmentServerMiddleware, because it tries to execute npm run start, but the Vue development server is started by npm run serve. It appears to be an easy fix, so I only needed to change the line in my Startup.cs:

app.UseSpa(spa =>
{
    spa.Options.SourcePath = "ClientApp";

    if (env.IsDevelopment())
    {
        spa.UseReactDevelopmentServer(npmScript: "serve");
    }
});

But now, when I start the application, it opens the browser window that continuously hangs trying to load the home page. At the console output, however, I can clearly see that the Vue development server has started successfully and there are no exceptions.

The reason for the hang is this code in the ReactDevelopmentServerMiddleware class:

Match match = await npmScriptRunner.StdOut.WaitForMatch(new Regex("Starting the development server", RegexOptions.None, ReactDevelopmentServerMiddleware.RegexMatchTimeout));

As you can see, it starts the npm with a given command, which we can replace, but it waits for Node to produce a certain console output, which is hardcoded to Starting the development server. If you look close to the output of the npm run serve for Vue, you can see that it says Starting development server. So, the code above waits for the output until it times out and throws.

Change the output message

So, here comes a hack, since everything we did before was rather legit. Now, we need to replace the output message. It can be done by changing the serve.js file in the ClientApp/node_modules/@vue/cli-service/lib/commands directory. Here is my change:

  }, async function serve (args) {
    info('Starting the development server...')

Now, if I run the application again, it starts the browser, but I get an exception that the middleware cannot proxy the request to the development server:

HttpRequestException: Failed to proxy the request to http://localhost:54252/, because the request to the proxy target failed. Check that the proxy target server is running and accepting requests to http://localhost:54252/

(the port number can vary)

At the same time, I can see that at the time the development server of Vue was still building and linting the app. When that is done, I refreshed the page, and everything worked as expected.

Note on Browser Sync

It is possible to use the Browser Sync by installing the Vue CLI plugin by executing the vue add browser-sync in the ClientApp directory and using the serve:bs as an argument for the middleware instead of serve. But then the whole thing stops working again. That's because the plugin uses its own code to handle the serve:bs command. But it can also be fixed by changing the text to Starting the development server in the ClientApp/node_modules/vue-cli-plugin-browser-sync/index.js file.

Publishing

If you run the dotnet publish command for the React app, you will see that the distribution version for the SPA is built to the build directory in the ClientApp. That also corresponds with this line in the Startup.cs file:

services.AddSpaStaticFiles(configuration => 
    { configuration.RootPath = "ClientApp/build"; });

and this line in the csproj file:

<DistFiles Include="$(SpaRoot)build\**; $(SpaRoot)build-ssr\**"/>

As you can see, it is very easy to fix by changing build to dist in both places. The build-ssr part can be safely removed if you don't use the Server-Side Rendering. So, the code would be:

services.AddSpaStaticFiles(configuration => 
    { configuration.RootPath = "ClientApp/dist"; });

in the Startup.cs and

<DistFiles Include="$(SpaRoot)build\**"/>

in the csproj file.

When those changes are done, you can start developing and publishing your Vue SPA app hosted in the .NET Core web application service.

Shortcut

It is not nice to hack the code that run npm commands for the Vue CLI, so you might want to use the complete code for the Vue development server middleware that I've composed from the React development server middleware. Unfortunately, many helper classes for the middleware are internal, so I had to include those classes as well. All that code has the Apache 2.0 licence so it is not a problem to use the modified version of it as soon as the origin of the code is stated clearly. Here is my gist. If you copy this file to your project, you can just use it:

app.UseSpa(spa =>
{
    spa.Options.SourcePath = "ClientApp";

    if (env.IsDevelopment())
    {
        spa.UseVueDevelopmentServer(npmScript: "serve"); // use serve:bs for Browser Sync
    }
});

Deploy GitLab CE on a new Azure Kubernetes cluster

Alexey Zimarev — Sat, 02 Jun 2018 17:11:15 +0000

I would like to share my experience to create a small Kubernetes cluster on
Azure Container Service (AKS Preview) and deploy GitLab CE on it using the Helm chart.

Originally published on Medium.

Creating a cluster in AKS should be an easy task but sometimes things don’t go at they suppose to. There are at least two main issues that I found:

When using the Azure Portal, there is a big chance something will go wrong and the cluster will be always in “creating” state and you can only remove it by using the Azure CLI.
There is no way from Azure CLI to understand, which VM sizes are available in which region. Definitely, not all VM sizes can be used in AKS and in different regions the set of available VM sizes is different. It is OK when someone else pays for your Azure subscription, but using your own freemium subscription or paying out of own pocket might end up not so well.
You need a cluster with at least three nodes, since smaller VMs have limitations on how many data volumes can be attached to them and GitLab uses quite a few persistent volumes.

So, I managed to install the cluster with three nodes of the recent VMs, which are still quite cheap — the relatively new B-series machine size. These machines, according to Microsoft, are suited best for irregular CPU load, like web sites, development or test environments. This suits my purpose ideally.

I used B2s machine size with 2 vCPUs, 8 Gb RAM and 8 Gb local SSD.

You need Azure CLI if you want to repeat what I have done. If you don’t have it, the installation is described on this page. You also need kubectl, the management command like tool for Kubernetes.

After logging in to the Azure account, I had to register a new resource group,
because AKS requires a separate resource group. So do this, I executed this command:

az group create --name ubiquitous --location eastus

Although I am not from the US, I chose this region because it has most VM sizes available. As you can imagine, ubiquitous is my own resource group name and you should be using something else.

Next, the cluster creation. Doing it using Azure CLI is rather simple.

az aks create --resource-group ubiquitous --name ubiquitous --node-count 3 --generate-ssh-keys --node-vm-size Standard_B2s

The cluster name can be anything and I chose to use my company name, which matches with the resource group name. As you can see I specified three nodes for my cluster and B2s VM size.

The process is quite lengthy so leave it to run for at least 20 minutes or more. At the end, it will produce a JSON output, which you might record but I have not used it.

In order to be able to use kubectl with your new cluster, you need to add the cluster context to your .kube/config file. It can be easily done using Azure CLI.

az aks get-credentials -g ubiquitous -n ubiquitous

Here, -g is the shortcut for --group and -n — for --name , where you
specify the name of your cluster.

The next thing is to install GitLab CE. The best way of installing it on Kubernetes is to use the Omnibus Helm chart. If you don’t know about Helm, learn more here.

Note: it will be replaced by a new “cloud ready” chart, which is in alpha stage
now.

First things first, and if you don’t have Helm, you need to install it first. Installation is different per platform, so the best way to do it is to refer to the installation instructions.

After Helm is installed, we need to install Tiller, the Helm agent in Kubernetes. It is very easy to do by running this command:

helm init

Since you are already have your current Kubernetes context switched to the new cluster, it will just go there and install Tiller in the default namespace.

Then, we need to add GitLab Helm repository:

helm repo add gitlab

Before installing, remember that GitLab will use kube-lego to create SSL for your Ingress using Let’s Encrypt. But you need to have a domain, which you will use for your GitLab instance. You also need to control DNS for this domain. This is because it is necessary to add a wildcard DNS entry and point it to Ingress, which will be configured by GitLab.

Here, you can either get an external IP address for your cluster in advance, create a DNS entry and specify this address in the Helm deployment command. Or, as I did, rely on Azure to assign the IP address but in this case you will have just a few minutes to create the DNS entry, since you need to do it as soon as Ingress gets the address but before GitLab deployment is finished. This is the way I used.

So, the installation is executed by this command (remember to use your own domain name):

helm install --name gitlab --set provider=acs gitlab/gitlab-omnibus

As you can see, I chose to use the app.ubiquitous.no subdomain, so I needed to add a DNS entry for it.

In order to see whether the IP address is already available, I used this command:

kubectl get svc -w --namespace nginx-ingress nginx

At first, it produces output, where the EXTERNAL_IP will be shown as <pending> but let it run for a few minutes until a new line will appear and show the newly assigned external IP address.

Now, quickly add an A DNS entry for your (sub)domain and use this new address. In my case, the DNS entry was:

A   *.app.ubiquitous.no   23.96.2.189

I intentionally expose the real details here since it is a test cluster with non-production data. In addition, it is quite secure.

At this moment, the GitLab instance is still being deployed. Azure is not very fast on completing persistent volume claims and before this is done, GitLab pods will not be operational. It took about 20 minutes in my case for everything to be set up.

Now, after all is done, I got a GitLab CE instance running on Kubernetes cluster in Azure. Helm deployment told Ingress to use a few host names: gitlab , mattermost and registry . These host names are for the subdomain specified for the installation. So in my case, I am accessing GitLab by going to https://gitlab.app.ubiquitous.no. When I went there the first time, I was able to specify the new password for the root user, so my advice is to log in the first time as fast as you can.

What is included by default? Well, quite a lot:

GitLab CE itself, which hosts your Git repositories and handles issues and wikis.
GitLab Runner for Kubernetes, which is used to build and deploy your applications using the CI/CD pipeline.
GitLab Docker Registry, allowing you to host Docker images in individual Docker repositories for each project.
Mattermost chat system.
Prometheus time-series database, which will collect metrics for GitLab itself and for pods that the CI pipeline will deploy.

Hence that Kubernetes integration is enabled and configured out of the box, so you can use their default Auto Deploy CI/CD configuration and start building and deploying your apps to Kubernetes if you have a Dockerfile in your repository or your app can be built using one of default Heroku buildpacks. Read more about Auto Deploy
here.

Prometheus is not exposed to the outside world, so if you want to reach it, you can use this command:

kubectl port-forward svc/gitlab-gitlab 9090:9090

to set up port forwarding to the GitLab service, then open http://localhost:9090 to reach the Prometheus UI.

Later, I will describe how to use Auto Deploy in GitLab to build and deploy ASP.NET Core applications.

Finally, if some configuration for GitLan is required, you need to change the Ruby file that GitLab sues for configuration. Since configuration is stored on a persistent volume, it can safely be changed and the changes will remain after the pod or the whole cluster restarts.

But since there are neither root login nor SSH certificate for the pod, the easiest way to configure GitLab is to use kubectl exec. In order to use it, you have to know the name of the pod where GitLab runs. To do this, you can list all pods:

$ kubectl get pods
NAME                                        READY     STATUS    RESTARTS   AGE
gitlab-gitlab-764bd7665-w94t6               1/1       Running   1          22h
gitlab-gitlab-postgresql-5fff4f67bb-lp74p   1/1       Running   0          22h
gitlab-gitlab-redis-6c88945d56-gm5qc        1/1       Running   0          22h
gitlab-gitlab-runner-f7c85548-bl8c5         1/1       Running   7          22h

You can see some pods to run Postgresql, Redis, the GitLab Runner, but the first pos is the one we need. So, if we run this command:

kubectl exec -it gitlab-gitlab-764bd7665-w94t6 -- /bin/bash

we will get the pod bash prompt in sudo mode. From there everything is easy. To change the configuration, just edit the Ruby file:

vim /etc/gitlab/gitlab.rb

You can of course use something like nano if you aren’t familiar with vim.

When all changes are done, save the file, quit the editor and run these commands:

gitlab-ctl reconfigure
gitlab-ctl restart

Happy GitLabbing!

Hands-on Domain-Driven Design with C# Book

Alexey Zimarev — Mon, 16 Apr 2018 11:17:28 +0000

Ok, it is official that my book Hands-on Domain-Driven Design with C#
will be published by Packt in January 2019.

Here is the link to the book.

What You Will Learn

Discover domain complexity together with business stakeholders
Avoid common pitfalls when creating the domain model
Understand the concept of bounded context and aggregate
Design and build temporal models based on behavior and not only data
Explore benefits and drawbacks of event-sourcing
Figure out CQRS and to-the-point read models with projections
Practice building one-way flow UI with Vue.js
Learn how task-based UI matches with DDD principles
Understand how to develop complex systems in ever changing world

DDD All-The-Things

Alexey Zimarev — Thu, 03 Aug 2017 16:29:05 +0000

This article was originally published on Medium.

For quite a few years, with growing popularity of Domain-Driven Design (DDD), I keep hearing that:

DDD is hard
DDD is only for core domain

This mantra has became very popular and often is (mis)used to advocate some crazy things people do to avoid crunching the domain knowledge.

In this post, I would like to return back to the roots. In nearly every talk or lecture that somehow concerns DDD, Greg Young mentions that, in his opinion, the chapter order of the Blue Book is incorrect. The issue is that most of the strategic design is placed to the latest chapters of the book. Since the book itself is not the easiest of reads, most of the people rarely get over 50% of it, which means they manage to get through the basics of the Ubiquitous Language, learn a little bit about contexts, then spend most of their time reading about implementation patterns.

But, if you look at Twitter of Eric Evans, you will see this:

“Domain Linguist” @ domainlanguage.com

Something begins to clear up, doesn’t it? Eric is not an “king of aggregates” or “master of repositories”. He is a domain linguist.

One of the major take aways from the (highly recommended) Implementing Domain-Driven Design workshop by Vaughn Vernon for me was this:

Domain-Driven Design is developing Ubiquitous Language within Bounded Context.

How crazy is that? Not “finding the right aggregate boundaries” or “splitting layers”. Thisâ€Š–â€Šlanguage and context.

What does it mean in real life and how does it correspond with the post title, you might ask? Well, here is my answer:
Use domain-driven design everywhere. Start with knowledge crunching, get as much knowledge about the domain as you can. Talk to domain experts, use techniques like Event Storming, mind-mapping and observations to get knowledge. At the end of the day, we all agree that 90% of the developer’s job is finding out what to do and only 10% is coding. DDD will allow you to understand what to do, from the problem space perspective, from your user perspective.

By writing this I do not suggest using implementation patterns like aggregates, repositories and so on, everywhere. This is just plain wrong. But two things â€Š– â€Šlanguage and context â€Š– â€Šare your main tools to create a strategic map of the future solution, will create this missing link between your users’ problems and your proposed solution.

Each context might use any implementation technique suitable for that context That could be CRUD, Active Record, Event Sourcing or anything else find applicable and what is inline with the complexity of the context itself. However, the realisation of facts that you have different contexts, that your system almost never consists of one context only, that you need to understand your user’s language, will help you building a better system.

I gave a talk at DDD Norway meetup in March 2017 about this and you can find slides on SlideShare.

The same talk was squeezed to a ten minutes lightning talk at DDD Exchange 2017 in London, which you can watch on the SkillsMatter web site.

Do you agree or disagree? Have you got your own thoughts about this? I am happy to discuss.

Hi, I'm Alexey Zimarev

Alexey Zimarev — Thu, 19 Jan 2017 10:16:14 +0000

I have been coding for 20 years.

You can find me on GitHub as alexeyzimarev

I live in Larvik, Norway.

I work for ABAX.

I mostly program in these languages: C#, TypeScript, F#, Scala.

I am currently learning more about functional programming.

Nice to meet you.