Client-Server WASM-Application In C#, TypeScript And Transact-SQL


This is not a traditional complete article, but only an introductory description with references to another resource with a more detailed representation of proposed ideas. In my research, I do not from a practical perspective, but from a desire to materialize some views. Here I’m talking about programming in C# language, which is targeted for the Web-browser. The subject is related to Blazor-WASM (SPA), but not only (if we look at it in general). All this (the work and the article) is very far from useful and practical approaches applied to Web-programming, but somebody may find my work interesting.

Idea of Client-Server.WEB

The idea is to create reusable skeleton for Web-application simultaneously on both client and server sides, including also some support at database level. This idea also may be named simply as a Web-application engine. Such an engine is build in several languages which are normally the same that are used in user application code. (Let us shortly reference to this idea as CSWEB.)

The Work

I would like to represent my experimental Work which is related to Blazor-WASM (and not only). The name of the Work is Client-Server.WEB (idea). Under this name it is located on my own Web-domain in correspondent partition, (CSWEB URL). As a result of the Work — it is accompanied by the BookRegistry sample application supplied in the following download file: “BookRegistry app. YYYY-MM-DDx.7z” (general name form) which is located on domain.
The Work and subject of the Article are confined by the BookRegistry application project (set of compilable projects), which already includes all necessary minimal dependencies as attached auxiliary modules (prerequisites). Separate project/product Handicraft-SDK formally is not part of this Work, but it may be interesting in connection with CSWEB. On Handicraft-CODE public pages (domain on supporting resource: two big projects are represented by following two different and separated partitions,
  • Handicraft-SDK
  • Client-Server.WEB (idea).

BookRegistry application

I would like to represent to you a little but able-to-work sample program which is based on previously mentioned app.skeleton — BookRegistry application in Blazor-WASM, with presence of library-level code and user code in three languages: C#, TypeScript and Transact-SQL. (User interface markup is in HTML/CSS.)
The program demonstrates some operations of simple tools (Web-application), which is intended to support the following two things: (I) book selection from the database by different parameters, and also (II) editing of the book registry. An authorized user may: (1) correct book-record, (2) add new book into book-registry (database), and (3) to delete unnecessary book-record. It’s simple itself (not much user code), but it strongly cooperates with the engine (skeleton). This construction (engine+app.) provides certain unification into UI and into user app behavior. A simplified preso-synchronous approach for UI-interaction is used in this SPA like somewhere in classic desktop UI (but this is not very restrictive). The program is provided with the so-called Magistral layout for SPA performed in a special manner, so as if it is embedded at the browser level. This layout is intended to supplement a lack of some important user accessors to UI (that are: vertical side-bar inside application page — with top/bottom scrolling, content selection button, operation escape-unblock, intentional reloading of virtual-page etc.) and also supports so-called Foreground UI-operation (with a corresponding visual indication of performing the action). The magistral layout is an interesting thing that is potentially useful in terms of its general application. It is implemented in TypeScript and it has corresponding simple API for C# (WASM DLL).

Handicraft programming style

Handicraft approach to program development (so-called “handicraft programming”) implies, that somebody maintains or controls a part of system-like code and this significant part of auxiliary and/or low-level code in the application may be kept in hands of one or more individual developers. Non-trivial organization on base of modules (DLLs and not only) is an inherent feature of such handicraft programming, as well as a tendency to the strong fractional division of program text into numerous source files grouped into subfolders (instead of working with kilometer-long files of code). Handicraft-coding style is suitable for building somebody’s own AFX (Application Framework Extension) — your own small auxiliary framework and/or collection of simple general helpers for different purposes. In other words, all this may be denoted as User Runtime Extensions (let us name it as URX).

Handicraft-SDK (not part of the Work)

In a Client-Server WASM-app, the skeleton is built with help of DotNetHelpers libraries — set of modules: “CommonHelpers.*.dll” (general purpose libs). DotNetHelpers library set is part of Handicraft-SDK. Compiled modules “CommonHelpers.*.dll” are included into to BookRegistry app. project (CSWEB) as attached binary dependencies, but the sources are part of separate product Handicraft-SDK (not part of the Work).
Web-pages listed at the end of this page (links) contain information about Handicraft-SDK. There is no special documentation for helper APIs (except special SQL-header doc.files), but source code is quite simple for everyone who is C#-programmer. Some code samples are applied in the form of compiled sources (as part of DotNetHelpers). Also, there is a lot there dedicated to programming inside the database in T-SQL.
(Handicraft-SDK is free of charge, it has open source and it has weak restrictions issued from its copyright. See the corresponding Web-page on supporting resource:, in the article's author domain.)

Client-Server Web-engine and the application

BookRegistry application together with all its libraries and auxiliaries, all this is standing directly on three imperative languages and without intensive usage of something high-level — as in Web-client so as to at the server-side. For instance, the Bootstrap framework is used superficially (mainly for decorations of different kinds). The server which is in C# (in ASP.NET-Core) operates with the database with help of extremely lightweight ORM to SP and queries which is implemented in DotNetHelpers. (This construction sits on ADO.NET-Core.)
Both parts of the program Client & Server are in C#, and this is determinative here. For the sake of unified Client-Server interoperation special C#-classes are introduced (as base exchanging structures for data-models). Normally, the user code does not use JSON-features (C# attributes) intensively. Instead, all declarations of data exchange are specified mainly in pure C# language, which has priority over JSON (in this approach). Conditional compilation is used extensively however for declaration of C# exchangeable objects and in some implementations (code-files). Such a non-trivial declaration is used in order to represent the exchange data-model in one single place so that this description takes effect for both sides (client/server), but with some differences in behavior at sides of the server and the client.
Also, there is a lot interesting concerning error handling, especially at the client-side. For example, an error page is implemented in WASM-Blazor. A special technique is used when dealing with possible exceptions. See the source code of BookRegistry.Client subproject (in corresponding BookRegistry app. download from supporting site).

Experimental way

My approach is not simple of the cause, but looking to user written code as onto separate part from one side and onto CSWEB-engine so as it is framework extension or base skeleton (which does already exist) from the other side, the program then doesn’t seem so complex (at least in its user part). Also, some reorganization may improve the situation concerning clarity and accessibility. (This is experimental application.)

Supporting resource (Web-pages)

There are Web-pages dedicated to so-called “handicraft programming” on my own Web-domain(s). They include also (besides other materials) the idea of a Client-Server WASM-application. See the following addresses (Handicraft-SDK & CSWEB), 
  • CSWEB (Client-Server) partition, the Work
  • - separate product Handicraft-SDK (partition);
  • - Handicraft-CODE (public pages), subdomain HANDICRAFT;
  • - site root (parent domain). 
This article was previously published in Handicraft-CODE author's blog.
Client-Server WASM-Application In C#, TypeScript And Transact-SQL (BLOG-HC subdomain).