The documentation applies to: v0.8.0
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¶
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
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
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
- 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
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
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
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.