Aiursoft micro-services platform. Powered by ASP.NET Core.

Nexus is not a framework, not a tool, nor a library. It was just a project, runs in the application level, using micro-services design and powers all Aiursoft applications.

Nexus provides many useful services and simplifies web application development.

Nexus provides a central platform for an entire enterprise. So the enterprise can focus on business app development.

• Integrated user authentication https://gateway.aiursoft.com (OAuth, Social authenticate, password reset)
• Integrated app authentication https://archon.aiursoft.com (Token assign, token validation, app authorization)
• Account management center https://account.aiursoft.com (Profile editting, Two-FA, social account, switch email)
• Developer center https://developer.aiursoft.com (App creation and permission management, basic debugging tools)
• File storage system https://probe.aiursoft.com (Compress, Clear EXIF, customize domain-name)
• Message queue https://stargate.aiursoft.com (Auto message clear, WebSocket push, channel authentication)
• Home web page https://www.aiursoft.com (Terms, privacy)
• Wiki center https://wiki.aiursoft.com (Read document)
• Cross-platform deployment (Supports Windows, Linux, and docker)

Nexus code structure has 4 layers:

• Abstract layer - Contains basic interfaces and code style abstracts.
  • Scanner.Abstract - Abstract layer for Aiursoft.Scanner.
• Basic tools layer - Contains basic tools for C#.
  • Handler - An error handle framework for ASP.NET Core
  • DocGenerator - A basic API document generator for ASP.NET Core applications.
  • Scanner - An Automatic dependencies management system for ASP.NET Core.
  • XelNaga - Some other C# tools.
• SDK layer
  • SDK - Contains Aiursoft interface defination and abstract.
  • Pylon - ASP.NET Core toolset. Contains tools for building web apps for Aiursoft.
• Web apps layer

Nexus architect has three layers for web applications:

• Basic Services
• Infrastructures
• Applications

The basic services are used to support the operation of the entire platform. It is the basis for the expansion of the subsequent infrastructure and user services throughout the platform. The basic services mainly include the user's authentication, authorization, application authentication, authorization, and allow the user's self-registration and self-registration of the application. At the same time, the underlying service is also responsible for the user's underlying data and the underlying data of the application, as well as the user's set of credentials and the set of credentials for the application.

Infrastructure refers to some common software tools that the platform can provide on an infrastructure-based basis. Such software tools are similar to static file storage, object storage, CDN, message queues, caching, and the like. Such services need to be registered in the underlying service and use the application authentication service and the application authorization service to check if the visitor has permission to invoke the infrastructure.

Before discussing the user service layer, all of the underlying services and infrastructure we discussed were oriented toward other subservices rather than user-oriented, but only provided data interfaces for other service calls. Obviously, as a mature platform, developers and users should not implement the registration of services and the management of permissions by calling interfaces. Therefore, we need to develop additional programs that provide such a user-oriented terminal that allows users to operate through a concise interface and logic.

In addition to the user interface that OAuth itself needs to provide login, this layer should also provide a more basic service in the microservice platform. According to the results of the needs analysis, there are account management services and developer center services in this layer. Both services rely on the infrastructure of the previous layer and provide user-oriented functionality.

Any high-level service is built on the micro-service platform. But the requirements they solve are actually based on the decisions of the companies that use the microservices platform. In other words, regardless of the company's decision-making to build search engines, forums, company homepages, feedback centers, recruitment centers, etc., the platform should be able to support. But the entire process of this part should follow the process followed by a separate software system.

Running the entire micro-service platform is very very complicated and requires a lot of computing resources. Before you try to run the platform, we strongly suggest running only one specific service. Running one service is very easy and simple.

For running the platform, The document is here.

The document is here.

If you wanna try the platform, all independent services are deployed under the following link. Click any of it allows you to try viewing a service.

• Account
• API
• Archon
• Colossus
• Developer
• EE
• Stargate
• Wiki
• WWW