NML

Architectural Guidance

Posted on 20 Mar 2019
Charl Marais

A one-size-fits-all architecture is never optimal as there are many ways to skin the proverbial cat.

This guide describes types of systems based on their particular "special requirements", and then types of architectures and technologies to consider using when designing the solution for those systems.

NML Preferred Technology Stack

Development Languages

  • C# 7+
  • Typescript 3+
  • TSQL
  • HTML5 / JSX
  • CSS 2+

UX

Web Server

Transactional Applications

  • ASP.Net Core 3.1+ / ASP.Net Framework 4.6.1+
  • MVC with Razor Views

Caching

  • Azure Redis Cache

Static Sites

CMS

Back-ends

Data

Messaging

  • Azure ServiceBus / Azure Storage Queues

Processing

  • Azure Logic Apps
  • Azure Functions
  • Azure API Manager
  • Azure Traffic Manager
  • Windows Services on VMs

General Preferred Dependencies

NPM

NUGET

General
Unit testing

Technologies to avoid and replace

  • .Net Core 2.1 & 2.2
  • Unity dependency injection
  • JQuery
  • React alternatives (Vue.js, Preact.js, Angular)
  • Javascript (over Typescript)

Architectural guidance

Complex business rules

Requirement: Application with complicated business rules, especially business rules that may change often.

Event stream processing

Requirement: the system needs to take action based on a large number of inter-related events. For example, thousands of "person location update" events need to be processed in order to determine if two "friends" are close to one another.

Workflow with user-interaction

Requirement: the system has complicated workflows that include user interaction, for example: "Loan" message arrives at service, service calls another service to do a credit check, then a person has to review the request and "approve" or "deny" it.

  • Consider Azure Logic Apps and Functions, Power Automate
  • Unsure. Is there any good workflow technology out there?
  • Nasty option nr 1: BizTalk orchestrations
  • Nasty option nr 2: K2
  • Workflow Foundation with custom code to handle user interaction.
  • Custom implementation from scratch.

High load website

Requirement: public-facing website must be able to handle thousands of requests per minute. Data does not change frequently (i.e. a news site).

Remember, accessing data from the database or from a web service is slow. Often implementing these strategies make a big difference:

Reliable messaging

Requirement: the system must accept messages and return messages in a reliable way, ensuring no messages get lost, and ensuring that the system can endure temporary internet outages.

  • Consider using Azure Service Bus Queues (more feature-rich) or Azure Storage Queues (faster and simpler, but less features).
  • Use NServiceBus to get auto-retries, error queue monitoring and much more useful reliability, maintenance and monitoring features.
  • On VMs, consider using message queues instead of calling web services directly (the simplest kind is MSMQ built into Windows).

High availability

Requirement: Application must always be online.

  • Consider hosting in Azure (i.e. Azure Web Apps), but keep in mind that even Azure only has a 99.9% uptime guarantee, meaning as much as 40 minutes downtime per month.
  • Leverage Azure Traffic Manager configured for fail-over across multiple Azure Web Apps.
  • Use a load-balanced architecture with multiple servers, when one goes down, the other servers can pick up the slack. This requires a load balancer or use of the Azure Traffic Manager.
  • Have a hot-standby server ready to switch over to in-case the main server is unavailable. This can be triggered by an automated DNS switch-over.
  • Geo-replication: replicate the system to more than one physical location, and use DNS fail-over to switch to another location if the primary location becomes unavailable.

Strict security requirements

Requirement: Application is used in a Banking environment, and as such must be very secure.

  • Use HTTPS for all communications, do not allow HTTP.
  • Protect against cross-site forgery (XSRF) by using a XSRF-token on all HTML Forms.
  • Get a security audit from a company like Sensepost. They test software for vulnerabilities.
  • Do not allow common passwords (i.e. anything that contains the word "Password"). Check against a list like the following: 500 most common passwords.
  • Ensure authentication and authorization is done on all REST endpoints. This can be easy to overlook.

Very simple requirements

Requirement: Application is very simple, minimal business logic, mostly saving/loading of simple entities.

In this case, simpler architectures can be used to save time, but beware that these architectures generally don't "scale" well when the system gets more complex, so make extra sure that the system probably won't get more complicated in future.

  • Consider using a micro ORM, like Dapper or PetaPoco.
  • Consider using Active Record instead of a full-featured ORM.
  • For smaller projects, consider the NML repository pattern.
  • Consider if the MVVM pattern is overkill, perhaps a simpler plain HTML or plain Javascript implementation will be sufficient?

Cross-platform app

Requirement: Application must be available on many platforms including, i.e. Mac, PC, Android, iPhone and Windows Phone devices.

  • First choice is Progressive Web Apps.
  • Consider a technology like Ionic (cross platform ReactJS + Typescript)
  • Refer the client to an NML partner for native mobile application development.