.NET 5 + Blazor = Blazor WebAssembly✅
Tags: csharp, dotnet, programming, beginners
Published: 2021-07-05 11:57:00

Since the last release of *.NET 5* at *.NET Conf 2020*, all of your users have seen first-hand how to take advantage of the latest web technology using *.NET.* Most interesting of all was the announcement of the new release of **Blazor WebAssembly.** What Blazor allows is to create an interactive web user interface, but using *C#* instead of the classic *JavaScript.*

What Blazor WebAssembly allows users is to create an isolated C# application that can be run in almost all different types of web environments, even environments that only allow static sites such as HTML, Javascript, and CSS.

Thanks to *Blazor WebAssembly* compiling all your *C#* code, into native code that **doesn’t run on the server** from somewhere, but rather **runs in the browser.**

This is very important in scenarios where the application needs to run **without being attached to a server** or needs to run **offline.** Only if the application needs a server to request data from outside, which is most common in applications that are based on *Javascript.*

Considering that the application runs in the browser, the loading and **rendering times** of the user interface **are non-existent,** thus allowing a very pleasant experience for the end user. In order to see the benefits, it was decided to migrate a well-known application to *.NET 5* and Blazor *WebAssembly.*


![blazor](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/gr3jqgdqloiawz4z29zf.png)

---

I’m going to tell you a bit 👇

At Ignite 2019, **RPSLS** *(Rock, Paper, Scissors, Lizard, Spock)* was introduced, simply a web game based on the classic Rock, Paper, Scissors, but with an added difficulty increase. Their goal was to show that services created in any language could run on *Azure* on a large scale.

When it launched, thousands of people tested the game in the first week. You can find the game code on *GitHub* **(RPSLS)**.

> What is really the game?

- It is simply a microservices architecture solution that has been built on Azure Kubernetes Service.

> How does it work?

- There are two ways to play, one is against a friend using a URL that is generated on the spot. And another is you simply play against a bot.
In the case of playing against a friend, nothing happens, but when playing against a bot, what you are really doing is playing against the microservice in the language you choose at the beginning.

For example 👇

If you choose .NET as your opponent, basically a service is running in .NET that tries to guess your next move. Guessing, the service tries to choose a move to beat you. The predictions run in .NET, as does the bot microservice and the web UI.


![blazor](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/r47nrw4rbebthnpaa1p5.png)

---

### 🔼 Update the application to use the latest bits

With the recent release of *.NET 5* unified with *Blazor*, it made a lot of sense to update the game. This was not challenging, but what was interesting was not only upgrading to *.NET 5*, but also migrating the game to *Blazor WebAssembly.*

### 🔄 The process
A new project was created with a template that had *Blazor WebAssembly*.

What this does, is create 3 projects👇

- Frontend
- Backend
- Shared services

Simply moved the content of the *Blazor Server* page to the static folder index and replaced the *BlazorServer* framework with *BlazorClient.*

All *.razor* files from the old project were migrated to the new one.

Afterwards, the client’s project was configured to be able to initialize *Google Analytics* with the **API** key obtained in the Backend. Implement an authentication provider such as *AuthenticationState* to verify user logins before calling the server.


![blazor](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/aidyqz60zu578clhjofl.png)

---

### 🟢 Conclusion:

In general, it seemed a bit more complicated, but it turned out to be very simple. Developing the application layers in the same language made it not appear that a *client-side* application was being built, but compiling into native *WebAssembly*, it is.

Building a *client-side* application and still getting support for dependency injection, *HTTP/GRPC* clients, and the options pattern, in the same way as the backend, **makes migration easier**.

One of the advantages of the application is that it does not need persistence, so it can be migrated to *Blazor WebAssembly* without major changes. From ByteHide we want to thank the .NET 
team for their great improvements. By making .NET 5 and Blazor more accessible to all applications to be migrated. 🤗