Architecture Overview

The AIClient-2-API project provides a unified API service compatible with various mainstream Large Language Models (LLMs), including Google Gemini, OpenAI, Anthropic Claude, Grok, and more. Its core architecture is designed with modularity, focusing on protocol conversion, provider pool scheduling, and plugin extensibility.

Core Module Components

The architecture of AIClient-2-API consists of the following key layers:

1. API Service Layer (src/services/)

• api-server.js: The entry point for the entire service, responsible for starting the HTTP server and basic routing.
• api-manager.js: Manages API route mapping and endpoint allocation.
• ui-manager.js: Handles Web Management UI rendering and interaction.

2. Core Scheduling & Management (src/core/ & src/services/)

• config-manager.js: Centralized configuration loading, validation, and dynamic merging.
• service-manager.js: Service instantiation factory, supporting model-level fallback logic.
• plugin-manager.js: The heart of the plugin system, allowing custom logic injection at key points (e.g., response chunking).
• provider-pool-manager.js: (located in src/providers/) Manages provider pools for load balancing, failover, and automatic credential switching.

3. Protocol Conversion Layer (src/converters/ & src/convert/)

• ConverterFactory.js: A factory using the singleton pattern to manage conversion instances for different protocols.
• BaseConverter.js: An abstract base class defining unified conversion interfaces for requests, responses, stream chunks, and model lists.
• strategies/: Contains specific protocol implementations (e.g., OpenAIConverter, ClaudeConverter).

4. Service Abstraction Layer (src/providers/)

• adapter.js: Implements the ApiServiceAdapter abstraction layer, encapsulating common logic for underlying API calls.
• Provider Cores: openai-core.js, claude-core.js, gemini-core.js, etc., responsible for actual HTTP interaction and authentication.

5. Utility Layer (src/utils/)

• common.js: Core utility library containing request body parsing, unified error handling, retry logic, and authorization checks.
• provider-strategies.js: Provider strategy factory handling model extraction, system prompt management, and more.
• logger.js: A unified logging system.

Request Processing Flow

graph TD
    A[HTTP Client] --> B[api-server.js]
    B --> C[request-handler.js]
    C --> D{Protocol Resolution}
    D -->|Request Conversion| E[converters/ConverterFactory]
    E --> F[service-manager.js]
    F --> G{Pool Scheduling}
    G --> H[providers/adapter.js]
    H --> I[Provider Core]
    I --> J[External LLM API]
    J --> K{Response Conversion}
    K --> L[converters/ConverterFactory]
    L --> M[HTTP Response]
    
    subgraph Plugin Hooks
    M -.-> N[PluginManager: onContentGenerated]
    end

Core Design Philosophy

1. Protocol Neutrality: Internal logic is decoupled from specific protocols, achieving "any input, consistent output" through the conversion layer.
2. High Availability: The provider pool manager automatically detects and masks invalid credentials, ensuring service continuity.
3. Dynamic Nature: Configuration supports real-time refreshing, and the strategy pattern allows dynamic selection of the best adapter based on the requested model name.
4. Extensibility: Developers can quickly enhance functionality by adding new Converter strategies or writing plugins.