Адаптери

інформація

Обробка http запитів та ws здійснюється силами адаптерів ядра відображення. Створення запитів здійснюється в рамках життєвого циклу запиту чи події. Життєві цикли включають в собі валідації маршруту, залучення типів приватизації маршрутів, логування, формування контексту і т.д.

Архітектура

При ініціалізації ядра відображень відбувається послідовний запуск сервісів, У цьому порядку також включений сервіс комбінацій CombinationService, призначений для послідовного запуску адаптерів та фабрик.

Оскільки існує можливість конфігурування адаптерів, то запуск адаптера відбувається з урахуванням цієї конфігурації

інформація

Запуск сервісу комбінацій, а відповідно і запуск адаптерів, можливий лише після обробки конфігураційних файлів, активації можливостей логування, завантаження структури бізнес-схеми в пам'ять ядра відображення. Ця послідовність зумовлена залежністю створення запитів від вище описаних сервісів.

примітка

Запуск адаптера включає в себе активацію веб-клієнта за конкретним протоколом, на певному хості та порту, із можливістю використання ssl сертифікатів та закритих ключів.

Застосування

Використання адаптерів відрізняється відповідно до протоколу: http адаптер взаємодіє з заголовками, методами http та статусними кодами, тоді як адаптер ws працює згідно з довільним контрактом, який спеціально формується самостійно застосунком X-Fiber за власним контрактом.

http адаптер

Адаптер координує http взаємодію ядра відображень із попередньо завантаженою бізнес-схемою та веб-сервером.

HTTP адаптер оперує власним життєвим циклом створення запитів, що включає в себе налаштування CORS (Cross-Origin Resource Sharing), загальну валідацію вхідних даних, визначення деталей кінцевого маршруту, а також їх обробку. Він здійснює валідацію даних запиту відповідно до опису деталей кінцевого маршруту, додає токени доступу при необхідних типах приватизації та надсилає запит до веб-сервера. Після створення запиту, адаптер оброблює відповідь та повертає результат в хід роботи відповідного документа бізнес-схеми для послідуючої оброки цієї відповіді.

ws адаптер

Адаптер координує ws взаємодію ядра відображень із попередньо завантаженою бізнес-схемою та веб-сервером.

Адаптер взаємодіє в межах власного життєвого циклу створення запитів, що включає в себе загальну валідацію даних, пошук та визначення деталей кінцевої події, а також її формування. Він проводить валідацію даних запиту відповідно до опису деталей події, додає токени доступу при необхідних типах приватизації та надсилає подію до веб-сервера разом з іншою необхідною інформацією. Після створення запиту, адаптер оброблює відповідь та повертає результат в хід роботи відповідного документа бізнес-схеми для послідуючої оброки цієї відповіді.

інформація

Оскільки протокол ws не визначає конкретну структуру побудови подій, X-Fiber впроваджує власний формат взаємодії. Цей формат включає в себе тип події, що аналогічний http методу, оскільки комунікаційні варіанти обмежені (події від сесії до сесії, від сесії до кімнати, від сесії до сервісу тощо), статус події - спрощений варіант коду статусу, версія події, динамічні параметри та тіло події, тип приватизації та відповідне поле токену. Цей перелік вважається достатнім для структуризації. Також включається назва події, що є аналогом кінцевого маршруту.

Побудова подій та створення запитів детально описана в розділі "Бізнес-схема".

Застосування

Для обробки запитів http адаптер має уніфікований маршрут, димамамічними параметрами в який описується кінцевий маршрут. Адаптер аналізуючи динамічні параметри знаходить опис деталей маршруту та сам створювач запиту, проводячи життєвий цикл цього запиту.

// ** common.d.ts */
export type HttpMethod =
    | 'GET'
    | 'POST'
    | 'PUT'
    | 'PATCH'
    | 'DELETE'
    | 'OPTIONS'
    | 'TRACE'
    | 'HEAD';

// ** http.adapter.d.ts */
export namespace NHttpAdapter {
    export type RequestOptions = {
        // ... options structure
    }

    export type Response<R> = {
        // ... response structure
    };
}


// ** http.adapter.ts */  
import { inversify, inject } from '~packages'
import { CoreSymbols } from '~symbols'

import type {
    IHttpAdapter, 
    NHttpAdapter, 
    ISchemeService, 
    HttpMethod
} from '~types'

const { injectable } = inversify

@injectable()
export class HttpAdapter implements IHttpAdapter {
    // ... other class structure

    constructor(
        @inject(CoreSymbols.SchemaService)
        private readonly _schemeService: ISchemeService,
        // ... other inject structure
    ) {}

    public async request<
        SERVICES extends string = string,
        DOMAIN extends string = string,
        ROUTE extends string = string,
        DATA = any,
        RESULT = void,
    >(
        service: SERVICES,
        domain: DOMAIN,
        route: ROUTE,
        method: HttpMethod,
        config?: NHttpAdapter.RequestOptions<DATA>
    ): Promise<NHttpAdapter.Response<RESULT>> {
        const sStorage = this._schemeService.services.get(service);
        if (!sStorage) {
            // ... throw error
        }

        const dStorage = sStorage.get(domain);
        if (!dStorage) {
            // ... throw error
        }

        const sRoute = dStorage.routes.get(route + '{{' + method.toUpperCase() + '}}');
        if (!sRoute) {
            // ... throw error
        }


        //  1. root dinamyc params and resolve required params
        //  2. root query params and resolve requered params
        //  3. root headers and resolve required headers
        //  4. root supported language

        const {protocol, host, port} = this._config;
        try {
            const response = await this._requester.request(
                // ... request options structure
            );
            return {
                body: response.data,
                status: response.status,
                headers: response.headers,
                request: response.request,
            };
        } catch (e) {
           // ... processing catch error
        }
    }
}