Blazor WebAssembly & Firebase Authentication

I will talk about:-

Architecture to choose for bigger audience.

Too many machines - remove dependency from user machine (the unknowns) and shift it towards known machines (servers). Make the client as lean as possible. Get server to do the  heavy lifting - that's what they are made for.

The problem is that unless you have an army of application support people, you would never be able to sort out each and every problem. Machines tend to be different. Code misbehaves on certain machines and let's face it, you can never full-proof your code for every kind of machine.

On the face of it, it is quite lucrative to push as much functionality to our "thick" or "smart" client as possible. This will de-centralise processes to user's machine. Result - less load on server. But in case of a production issue, is hard of get hold of user's machine. Moreover, efforts done to fix the problem might not be useful to majority of users. This result in maintenance nightmare. If this was some server misbehaving, we know it is a controlled environment and we can debug the problem. Patches will make sense to all.

Lets take an example of a document management application with following broad functionality:-

1. Users can create searches which will fetch documents from Sharepoint.

2. User's can drag and drop document from Outlook as well as local folders.

3. User's can associate metadata from some other enterprise system to documents which gets stored in sharepoint list.

4. User's can store a set of metadata as a bookmark. He can choose the bookmark for search execution. Also he can drop a document from outlook to this bookmark to associate its metadata.

5. User requires offline capability.

You may notice outright that this system talks with too many eternal systems - Outlook or Mail Server, Sharepoint, Enterprise system from where metadata is sourced, the database, then local drive or may be some sqlite files for offline storage.

I believe the number of external systems increase risk of failure exponentially. On the top it if we let each user's machine handle it in its own way - the entire system for sure has gone for a toss. We have no control over the user's network, cpu, memory, firewall, antivirus and other resources. Basically we have to deal with jus too many parameters.

But the matter of fact is that we can't do much about that. If we have to - we have to. But we can be smart and move all interaction logic to some place which is more controlled.

How?

Lets create a controlled server environment (or a cluster). User drags and drops an email from outlook. We tell the server to get that email from exchange, fetch the relevant metadata, apply it and upload the document to Sharepoint. All in one instruction to the server may through a message pushed through some message bus. Client subscribes  back to the result of the entire operation. all of a sudden, the client is now dependent on just one broker. On the top of it our server cluster is totally controlled.

The the client deal with the magic of presentation...

Logging and Auditing

Most of the user's are not technical, but they need to have faith in system. If there is an issue, you got to trust the user. But you cannot use all of his time to debug your production issue.

But strange things do happen and you will need to figure out what actually happened. User's may forget things, hence you cannot solely rely on their capability to recall what they were doing when the problem occurred.

If the system is not trustworthy, they may blame it for some or their own mistakes. Auditing and logging comes handy and is actually a huge defence mechanism for developers. It is something you can live without - but hey, you can even ride a 1000cc motorbike without a helmet. The question is whether it is wise to do it?

Ideally every user action should be centrally logged so that they don't have to be disturbed while tracking down problems.

Importance of testing.

Roll out strategy.