Skip to content

Big Picture

The documentation applies to:✅ v0.8.0

Design Goal

LET Portal (LP) has been designed for one important question:

How can a small team develop and deliver quickly a change to colleagues?

To be honest, we take a couple of months to answer this question. We would like to have a system can help me to generate an application form, a data list, and a dashboard in a few minutes without taking care seriously in some software aspects such as High Performance, High Availability, etc. to adapt a basic requirement. We just care about our colleagues's expectation, how they can use it, and how it reduces more time.

LET Portal Architecture

LET Portal Architecture

According to an architecture above, LET Portal has six components and one 3rd-party component. There are:

  • SPA Web: Angular 8
  • Gateway: Ocelot - .NET Core 3.1
  • Identity API: .NET Core 3.1, use .NET Identity library to provide JWT
  • Portal API: .NET Core 3.1
  • Service Management: .NET Core 3.1, a built-in service management for all LET Portal APIs
  • Chat API: .NET Core 3.1 and SignalR for Web Socket
  • Proxy Server: Nginx

Advantages and Disadvantages

In our opinion, there are no perfect architecture and no architecture suits for most of softwares, includes technologies trend such as Micro-services, Saga, etc. So we list out some common advantages and disadvantages based on High Level Design abvobe. Hope they can guide you to go right direction when you have a plan to deploy LET Portal.


  • Separation of concerns: we can replace ⅘ components, they are:
    • Proxy server: you can choose HAProxy instead of Nginx
    • Gateway Ocelot: you can choose Kong, Zookeepr instead of Ocelot
    • Identity API: you can choose Identity Server 4 instead of built-in Microsoft Identity
    • Service Management: you can choose Consul, Eureka instead of built-in service
  • Support scalability with less changing code -> Reduce deployment preparation
  • Easy to understand by most of developer -> Reduce training time
  • Deployable on one VM or multiple VMs -> Cost is efficient
  • Be ready to apply micro-services when needed -> Adaptive with trend


  • Many components are built-in, so features can't be comparable with others
  • Security is acceptable, not suitable for High security requirement
  • Availability is acceptable, but we need more time to deploy High Availability


SPA Website

Front-end site of LET Portal, it is an Single Page Application which connects to two web services (Identity API, Portal API) and Gateway (Ocelot).

Source code location: src/web-portal
Technology: Angular 8.2.1

Gateway Ocelot

Following a micro-services trend, we use a Gateway Ocelot (it is a open-source project) to do four functions by default in LET Portal:

  • URL-based routing
  • Add TraceId to request header
  • Authentication
  • Offload SSL (in case HTTPS)

Current version, Gateway Ocelot is only covering Portal API and one full-path API of Service Management. We will discuss more detail later.

Source code location: src/web-apis/LetPortal.Gateway
Technologies: .NET Core 3.1, Ocelot 14.0.5

Identity API

This service is providing authentication/authorization mechanism between SPA Web and Gateway Ocelot. Main functions are: - Login with JWT - Register/ Forgot Password - Get roles and claims - Track user's activities

Source code location: src/web-apis/LetPortal.IdentityApis
Technologies: .NET Core 3.1, .NET Identity

Portal API

This service provides all data for LET Portal SPA Web, without this, it can't work. This service has many functions to execute, so we will discuss more detail later.

Source code location: src/web-apis/LetPortal.PortalApis
Technologies: .NET Core 3.1

Chat API

This service provides a message exchange and bridge for Video call. That helps to construct a chat room and cache message for improving performance.

Source code location: src/web-apis/LetPortal.ChatApis
Technologies: .NET Core 3.1, SignalR

Service Management API

This service is built-in for micro-services architecture. This provides some basic functions as SM in theory:

  • Service Configuration
  • Service Monitor
  • Service Logging

These APIs are using HTTP protocol, for gRPC we will do it later

Source code location: src/web-apis/LetPortal.ServiceManagementApis
Technologies: .NET Core 3.1

Proxy Server - 3rd party

This proxy server is mainly acting as network routing and WAF. We choose Nginx for taking this role, however, you can choose another proxy such as HAProxy.

A main reason why we should use Proxy server , is Kestrel server doesn't have enough web server's functionalities. If you have a plan to use on Windows OS, so you can replace Nginx by IIS.