More notes on my Webassembly web development with Blazor
This is another post in the Inselkampf series. Having spent much of my career creating “desktop” application, web always feels a bit different. If it’s a website then HTML/CSS/PHP + MySql is a reasonable way of working. But when its a web application like a browser game that uses a SQL database, then there’s a bit of architecting involved.
I’m trying to be clever by using the WebAssembly version but having the C# talk to a restful interface. Restful just means it has a bunch of http calls to do things like update, fetch data, login etc. On the server runs a ASP.NET program implementing this. It’s headless, as in its not outputting any webpages to the browser but just returns data in JSON (or maybe MessagePack).
This avoids having a SignalR connection for every user logged into the site which is one way to bring a server to its knees. When you create a Blazor Server application, it has a few disadvantages. As Microsoft says: when you use Blazor server.
- Higher latency usually exists. Every user interaction involves a network hop.
- There’s no offline support. If the client connection fails, the app stops working.
- Scalability is challenging for apps with many users. The server must manage multiple client connections and handle client state.
- An ASP.NET Core server is required to serve the app. Serverless deployment scenarios aren’t possible, such as serving the app from a Content Delivery Network (CDN).
I’m also not using the Microsoft authentication but rolling my own. Yes it’s possibly not perfect but I’ve done it before. This way I get to generate recovery numbers. (Both GitHub and Gmail offer these). A bunch of one off codes that are used to authenticate you, if you’ve lost your password or messed up your email then you login with your account number and an authentication code. This is the only way you get to change email and/or password. You just have to keep the codes safe.
Rolling my own Interface
So things like logging in, getting current status, updating game play are all done by making a call to an HTTPS routine. This is all behind the scenes so players see nothing. Values are sent as POST parameters and also include a nonce. This word (that unfortunately means sex offender in UK English!) , refers to a special code that has to be supplied with each call to the server to authenticate it. Successful logging in returns a nonce that has to be added as a parameter with every call to the server.
The program on the server that serves the restful calls is a simple ASP.NET Razor pages application (Well maybe Razor, I’m not sure if I need them). Behind the scenes I’m using MySQL which was installed as part of VirtualMin (the excellent software I use to setup the VPS).