 Let's start right away. Good evening guys and thank you for making it at 7 here after office hours and we'll jump into the topic right away. We'll discuss about hosting a blazer app using Azure Static Storage websites. So basically we have two new concepts and two new ways of developing SPS single-page applications and deploying them. How many web developers here? Okay, and the web developers starting from the ASPX days, web forms ASPX days. And what would be the one thing you know which we as web developers we always wanted to see in our Microsoft applications development. Let's make this interactive. I will be gathering on all along and you guys just staring at the screen doesn't make sense. Yeah, so you know that one thing which we always wanted to speed up our development or one wish you know as a web developer. What was that one thing which you always wished would come in the next release in the next release something like that. Any wishes? Any wishes for web devs? Okay, fine. So you know we I mean as a web dev I wish that I wouldn't have to write so much of JavaScript code. Then I wish that I wouldn't have to learn Razor syntax when they came up with MVC. After that I wish I didn't have to learn AngularJS which I had to and then going forward the next year they came with Angular 2 and suddenly you're like this is changed. So yeah, so now another thing was all of us we wish that we we should know only one language and that should be able to help us to get through client side and server side coding. So well wish granted they have come up with Blazor. So as you see that's similar to Razor. So the syntax which you see would be similar to the Razor syntax. But what Blazor essentially does is your DLLs your DLLs the server side code you can render in client side browser. Okay, so that's that's it runs on top of the assembly which is W3C standard. So it's not something you know they have introduced out of out of the blue. Okay, second thing is most of us when we want to develop websites content web content not all of that is dynamic. Most of the times we just want to develop sites with our blogs which is static content and then doing so on Azure. You know which are some shared hosting sites incurred substantial amount of cost. So yeah, so for Azure static storage the primary motivation is that organizations are individuals we need to deploy static websites frequently block content or just about us contact us kind of company websites. And then we are always on the path of improving the time to deploy improving the cost viability and traditional shared hosting providers cost somewhere around 8 to 10 USD per month. These are still a bit you know a conservative measures could be more taken from the website about two years ago. Okay, so just on the conservative side. Okay, and why why do shared hosting require these costs because we need to reserve some CPU and VM memory. Okay, but what if our content is not dynamic and just static you know you don't really require some server side IO and stuff all you require is storage and bandwidth. So that is where Azure static storage comes into play. They have very recently maybe around one and a half years back this announcement was made. And as we go along we'll see you know how not to confuse it with Azure block storage and what are the benefits we get with static storage. Okay, so yeah they announced static website hosting which was yet another option. So you have many other options already available. That is your traditional deployment using the app service. Then you have Kubernetes Docker VMs and all those things. Okay, so we'll see the power of hosting on Azure static storage. The metrics which will form the basis of our comparison of deciding why static storage for single page applications. And essentially it's only for you know static content which you know won't change frequently. It wouldn't require you to write APIs and server side connection all static content which you may just update frequently. But this is just STML rendered application. So the metrics for our comparison would be how much effort to manually deploy an application with the traditional method. Vis-a-vis our Azure static storage websites. Configuration which is needed. How much does it scale? How much does it perform? And how much does it cost? So while the first three you know it depends on what are you using? Are you using visual team, VSTS, visual team studio to deploy? Are you copying the scripts manually? Writing some scripts to upload your published folder to the cloud and all those things. The major point of contention would be the last two metrics. How does it perform? What does it cost? Straight away this is the data taken from the block site which was introduced when they introduced the static storage. So if you look at app service when we are deploying using app service. The state forward calculation is one instance with the minimum configuration it is still going to cost you around 60 euros per month. The second popular method of deploying would be using Azure Function app plus the storage. So these are some of the assumptions you see that our single page application consists of maybe it's not a very big application. So files may be home about contactors, careers and sort of those stuff. With about 100,000 requests per day for one month which makes about 15 million requests per month. The calculations based on that would be just for the traffic would be 0.7 euro per month and then the storage cost would be around 5.6 which comes to 5.81. That you trade off with the static storage. Static storage how it is priced is you are hosting it at no cost. The only cost for static storage comes in for your block storage and the operations which are performed. So which means you are paying only for the storage and operations which comes to 4.64 euro per month. Assuming we are not a very big website and we require I mean the number of requests is not exponentially big. So which means we have a clear winner there. Azure static storage is very cost effective and when you compare the storage performance, sorry when you compare the performance with 10000 requests across all three applications, there also you see that the storage is the clear winner. One baffling fact is why Azure function with app would take so much time. But yeah I mean when you try and run this is actually the responses which you get for about 1000, 10,000 and 100,000 requests. Any case our purpose is solved. Azure static storage performs the best even here. Okay now let's diverge a bit. So once I mean how to leverage on Azure static storage and how to empower that with the Blazor application. Before we move on to the final demo where we see how to publish Blazor app and upload it on the static storage website. First let us dive into the details of Blazor. So as I have been saying Blazor is a framework which enables us to compile our DLL server side code and render them into the browser. So it was basically it is still in the preview version. So if you download Visual Studio 2019 how many of you are already using Visual Studio 2019? Okay so in the Visual Studio 2019 I think the latest update is 16.3. I'm not sure. It doesn't ship with that. This is still in the preview version the Blazor. Okay and so basically with 2019 what you see is it hasn't been a better time to be a .NET developer. You can build a myriad of apps across myriad platforms with different technologies communicating with each other over diverse platforms. So it comes in .NET Core 3.0 is introduced and the preview six version will include the Blazor templates. Okay and of course as you have been seeing that with each release of Visual Studio ID they are extending the support more and more towards diverse applications. How many of you have been using Visual Studio 2017 to develop .NET Core apps? Yeah so in Visual Studio 2017 when you see that you are trying to have a console app, .NET console app or WPF doesn't come with the .NET Core support. Web app you have an option. I mean the template, the type of project you choose, you get that option ASP.NET Core whatever. Then you choose the versions 2.0, 1.1 whatever. But you don't see it for web, sorry for WPF, WinForms etc. With 2019 you have that capacity. So that is just a bit. Okay. Now what do we do with .NET Core 3.0? So of course it has the ASP.NET Core functionality intact with MBC Razor pages where the API signal are with some improvements to security and identity. Okay. The component which they have introduced Blazor, this would be writing the client side. Also it doesn't mean that you cannot write your JavaScript code anymore or you are not able to allow to leverage on your React and Angular code. Yeah, you can of course do that. On top of that you can build components only with C sharp code. And you have something called as GRPC services. Those are background worker services used for communication between processes or applications. Okay. So if time permits at the end we will see this demo where we see all the three parts we have discussed. The client, the Blazor front end, the GRPC services and the ASP.NET Core working in tandem and bringing us this application. Okay. So what does a full stack application entail? Okay. The client side would be, I mean the UI which you saw that. So the client side would be just a grid which is accepting certain orders for processing. This is not real time processing. In the order, the status you would see here would be pending. Then, so that would be, the client side would be built using Blazor. Then we would have a background worker process running based on, built on using GRPC. How many of you are aware of the GRPC protocol? Okay. Yeah. So I would mention a bit of that when we are actually seeing the demo, GRPC. And so GRPC protocol, the worker services is built on that and it runs in the background. As soon as an order is received, it will process the order and then it will communicate the status back to the UI. And that is done using, the communication is done by using SignalR. Okay. So Blazor basically is built client side web UI with .NET instead of JavaScript. Call into the JavaScript libraries and browser APIs as needed. If you have already existing JavaScript libraries, you can write web UI components, reusable components, and share the .NET code with both client and server. How many of us are working with Angular? Angular, JS, Angular 2, Angular 4. Okay. So in Angular, we see that we have reusable components, right? I mean, once you have a component, you can use it across pages. So same thing. I mean, same concept is there with Blazor also. So once you build a component, you can use it in various other pages as well. So each page, like for example to relate it to the ASPX days, ASPX, if you had to have master, I mean, if you had to have some common controls and used to have those master child pages or user controls in which the control is shared across pages. So it's extension of that concept, but in a more user friendly way. Okay. So Blazor for WebAssembly is now in the official preview. Again, when you get the version of Visual Studio 2019, you get the Blazor server side template. You don't get the Blazor client side template per se unless you are working with the preview version. Okay. So this is what I was talking about. So you have two templates, Blazor on client side or server side. Blazor on client side is running completely on the browser thanks to the WebAssembly and which is your C sharp, razor code both are rendered in the browser. Okay. And for the Blazor server side, they are rendered to the browser using SignalR. So basically everything is compiled on the server side for Blazor server side templates and that code is rendered to the client side using SignalR protocol. There are pros and cons of both approach. We'll see them shortly. So in the demo for Blazor, we will see the components of Blazor built using Blazor client side template and I'll walk you through the usable components and how the file looks and how the DLLs are compiled and available as a JS.js. So we'll jump into the demo. Okay. First of all, I would like to show you how the templates look for. Okay. So if I click on create a new project here. Okay. Let's go for a .NET core web application. Click next. Yeah. Any name. It's okay. Okay. And when I click on create, you would get an option for the, to choose the templates for using which you would want to go and build. So you see here worker service web app, Blazor server side and Blazor client side. So we have constructed our demo using Blazor client side. Okay. Let's just close it because we already have created it. Okay. Yeah. So once you create your Blazor application using the client side template. These are the three default projects you get Blazor sample client, Blazor sample server, Blazor sample shared. Shared is a project which is some shared classes between the client and server. Have a keen look at the client project. These are your pages. Okay. These are razor pages or essentially your ASPX or HTML pages, the UI. You have components here. Imposed dot razor, counter razor, fetch data razor, index razor. Also please pay attention to the fact that you don't have a folder called as scripts or content anywhere which is having your JavaScript libraries. It's purely if you go inside the code here, counter dot razor or fetch data razor, index razor, it's all all C sharp code. You don't see any JavaScript libraries being included or whatever. I mean forget the styling CSS and stuff bootstrap and all, but apart from that for any of the functionality, you don't see any. So this syntax if you see would remind you much of the razor syntax we used with MVC. It's very close to that, but it's all using C sharp code. You don't see any client side libraries anywhere. Okay. And these are the program and startup which if you have worked with dotted core, we are very familiar with how they are used to build the configuration and set up the ports and everything. Okay. Blazor sample server if you see it will have your normal controllers and everything from where they are calling the APIs to render the data. Let's quickly run and see. Okay. This blazor grid component, I will give you the link later on which all these demos are available on GitHub. So it's a component built and we have imported it. It is just to highlight the capabilities of using blazor, powerful blazor components rather than using the built-in THTD tags and rendering the grid as a table. Okay. So this blazor grid, there are many third party components already built and available in blazor and you can already start importing them for your application. Okay. So let's run this blazor sample and let us see how it looks in the Internet Explorer. Does it bother any of us that our DLLs are now being rendered on the browser? I mean, last time when I was talking in the Dev Insider about blazor, a lot of people came up and asked me this, you know, that your DLLs, I mean, that's a server-side code, right? I can hack into it and that is something which is now being made available to me on my browser. Does it compromise my security? Does it compromise my application in any way? No, because this is not something they have introduced out of the box. WebAssembly is a W3C standard. It's a standard, so the framework is tuned to that standard. So it doesn't in any way compromise our code or it doesn't. For example, something which the database calls, for example, won't be rendered in the client side. So whatever paradigms or whatever rules are applying to our normal applications, the same apply here. There's no compromise security or anything like that. Okay. So let us look at our, we do a quick F12 and let us again reload. Okay. Now you see this mono.js, right? You see our DLLs also in the browser. And thanks to this mono.js, that is responsible for converting our client side code, making it available and rendered in the client side in the browser. Okay. Then you can also see all your DLLs. I suppose anyone who has debugged our previous applications, Angular or whatever with Firebug or Postman or stuff like that, I'm pretty sure we are not able to see this DLLs like this rendered in the client side. It's very much available here. You can see that. And the extra file which we see here is the mono.js and mono.wsm. WSM, this WSM file is the WebAssembly file. The WebAssembly file, which is the protocol that WebAssembly W3C standard, which allows the server side libraries also to be rendered in the browser. Coming back to, so this is a very simple default template you get once you create a Blazor client side application about reusability. So this was a separate page altogether. There are three pages, home, counter, fetch data. So counter was a separate page, razor page altogether if you see in our application here. If you see in our application here, in the pages, you had index fetch data counter. So counter was a separate razor page. I can always use it here in this page. It will give intelligence also if you want to use it. So you can use it as a tag. Same thing what we do with Angular. You build components, you import them in other pages. So much the same way you can also do this. So essentially, since this code was already there, what I've done is this counter page, I've imported a component in the home page. I click, it increments the counter. So basically the functionality doesn't change. It's just to show you that we are building reusable components. The razor pages can be used across the application pages. Now let's move on. So that was a blazer on client. I will quickly, in five minutes, I'll show you blazer on server side. That is a much complex thing with all the GRPC and server side coding and all. Let me see how much we can cover. We started off quite late. So this is our blazer application built with the server side. And you see that this has three things. Application shared is the shared libraries between client server and the worker process. The worker process, it works on a GRPC protocol. So GRPC protocol is a protocol which was introduced by Google few years ago. And if I were to believe industry insiders, it is now going to very quickly replace our normal REST API calls. Because what happens with GRPC is that you have a definitive contract on the functions which are written. And plus, what do you think, what do you think GRPC, you have used GRPC, right? What do you think you know? Because I was asked this question and I have faced this myself, this difficulty that when you work with REST API. So when I was explaining GRPC services, people came to me saying that you already have REST. It's a very popular paradigm. Microservices are built already, huge frameworks are there. So why GRPC? And why it is such a big deal now? So what do you think in your experience that GRPC brings in what REST does not? For me, it's the enforcement of the protobufs like being able to find all your types. Correct. And the contracts as you mentioned, that's like the strongest point. Another point for me was dual streaming. REST doesn't allow that at all. Like you know, even if you were to enforce that, there's no streaming in REST. And that is something which is very beautifully handled by GRPC. So GRPC, it enforces a protocol on you, protocol on the server and client. So it's like a contract they agree on. And that is how I'm going to write my function. This is how I'm going to consume my function, something like that. And it's RPC, it's a remote procedure call. But based on certain contracts. So this is the protobuf file, which is the building block of GRPC. So this file, this is the contract which I'm talking about. So this is like a pre-agreed syntax. So once this syntax is shared between client and server, they know that there will be a service called as orders manager. There is going to be a message sent from the server for order request. And the client is going to get back a reply in the form of order reply, something like that. It's pre-agreed upon. And if you look here also, the proto file is shared. See, proto's. The proto file is shared between the client and the server. So quickly when if we run this application now, it takes a bit of time to run because on my laptop as you see, I have right from visuals to the 2008. So right from the ASPX days to the blazer days. So let's say donuts, for example, maybe quantity 20, save order. So this is not immediately processed. An order is entered. It is there in the pipeline in the queue and it's pending. Now let us run the worker's worker process, which we have where the protocol is defined using the proto file. Let's run that. The worker is built using the GRPC as a client. See, order with ID4 has been processed. And now if I just refresh my page here, it will immediately notify that this order has been processed. Now it's no longer waiting in queue. So this communication from the client, server, back and forth worker services running in background, long running services that has been addressed. And another advantage of using worker services with Blazer framework is, let's say today this is hosted, the worker was hosted using a Windows service. Tomorrow you may want to use the event viewer to log everything. That also can be done by adding just few lines of code and some packages and you get packages. But it knows that when it's rendered as a Windows service, I should log the output in console when it is as an event viewer than where I should log and all those are inbuilt into the framework and it's very intuitive coding. You don't have to put in a lot of effort or stuff to do that. Moving on, so that was about Blazer. So we saw two concepts. One is Blazer, one is why Azure Static Storage. Now let's quickly combine those two and see the power of deploying Blazer on Azure Static Storage. So how many of you have a free Azure subscription? You know, you can just log into the portal and check out all the features offerings of Azure. If you ask a question, you might get one today. So for deployment, we will first log into our Azure portal and there you will see something like this. So I have logged into my Azure portal. In there, you go to storage accounts and then you click on add storage account, add here. Basically give the field whatever your subscription is. Resource group is the name what you want to give to your resource or account has to be a unique name. If it is repeated, it won't allow you to create. It would give you a validation error when you are trying to review and recreate here. Storage account name, location and rest all the things you can leave it as general. It is already a storage V2 general purpose account. It's different from the Azure Blob Storage. When you create review and create, it will create your storage account with the defaults. So I have already created one which is called as Blazer Static Storage. Now if you go to this Blazer Static Storage, there most of the things are already configured for us. We need to go to the static website prompt and there initially you will see that it is in a disabled state. You just make it enabled and it will give you two endpoints, primary and secondary. It generates on its own. Just keep high on the format of that. It gives HTTPS and the name of the account you have given and then these are generated by Azure. So when we are publishing or uploading our files to this static storage website, just be mindful of the account name you have given. You will have to give that in the syntax. If you see that it creates a dollar web folder here. If you go to this web folder, if you initially when you create that, it would be in a private access. You change it to either blob or container, both of which will allow you to browse the website once it is hosted. So I have made it a blob access. If you look at the contents of this, this is what we have published from our Blazer app. We will discuss that how we have done that. So let's go to our Blazer app here. The first one which we saw with the Blazer sample. This one. I basically just published the application. When you publish the application, it will... When you publish the application, it will just, if I open it in the file explorer, once you publish the application, it will create... These are the published files it has created, which we have to upload to our dollar web folder on the Azure static storage. So for that you have multiple ways to upload the files. You can use Visual Studio Code interface and you have an upload button there to upload. Or you can use the interface provided on the portal itself where you can upload files. So if I go here, you have... Sorry. Yeah, here. Upload. You can upload files from here also. But that is a bit tedious. You have to do it file by file. Or you have Azure CLI command prompt from where you can run commands and upload the entire folder or files inside that folder to the dollar web folder. So this is what I have done. So this is our Azure CLI. I downloaded it. And then these are the commands. az storage blob update. You have to give this account name. And then the account name of your account which you have specified, which in our case is Blazer Static Storage. Whatever the account name you have given when you are creating your static websites. So you do that account name. And the files you want to upload, the folders you want to upload. Once that is done, this is how it looks like. So this is your dollar web folder. Yeah. And these are the files you have uploaded. One thing to notice here is when you are creating your static website, it will ask you for two things. Your default page and your not found 404 page. So those you have to specify. For the 404 which is not found page, you can give the same index.html so that it falls back. If you don't have an error page configured, you can give the same fallback page so that you don't get that ugly azure cannot find XML error. So go back to your website. Go back to the static website. There are other options you can see. Blobs, custom domain. Custom domain is if what if you don't want to use this default link which is given here, but you may want to have some custom domain configured. You can do that here. Access keys, replication, cross-domain policy and stuff. So now all our basic stuff is done. If you look here, I have configured the default name, the landing page and the error page. And if you just browse this. Is it already there? With the primary or the secondary endpoint, both of them could be there. So we are just browsing it. And your application is rendered. It takes a bit of time. But this again, you know the static storage as I kept on highlighting is only for static data. To reiterate, when you will try to go to the fetch data page, fetch data page is actually fetching some data from API of server side that won't work here. So now this same application is working hosted on a static Azure website. You look at the counter field, the counter page, the home page. Both of them work as expected. The counter also. So because this is static data, as soon as I'm navigating to the fetch data page, it will throw an error. You can look at the network here. See console, console error, because it is trying to look for a server call here. Whether forecast API sample data, which is a server request to fetch some remote data. So how to do that, how to configure and how to have Azure function set up to communicate with your server side will be covered in the future sessions. So that's all for now. So we see how easy it is to deploy SPAs built with Blazor to Azure static storage. And I would be happy to take any questions.