Мідлвар для мобільних додатків — основи, архітектура та застосування

Що таке мідлвар?

Мідлвар — програмний шар, розташований між двома компонентами системи, що перехоплює та обробляє дані до передачі в цільовий компонент. У мобільній розробці мідлвар застосовується в трьох основних контекстах: управління станом (Redux, Bloc), HTTP-комунікації (Ktor Client, Dio) та обробка подій (EventBus, NotificationCenter). Основна цінність — ізоляція наскрізних завдань (логування, автентифікація, аналітика) від предметної логіки додатка. Замість того щоб додавати виклики аналітики в кожен екран, мідлвар робить це централізовано.

Архітектура Pipe and Filter

Мідлвар реалізує патерн Pipe and Filter: кожен компонент мідлвару отримує дані, обробляє їх та передає наступній ланці ланцюжка. Порядок підключення мідлвару визначає послідовність обробки — перший мідлвар отримує вихідні дані, останній передає їх цільовому обробнику. За даними JetBrains (2026), така архітектура дозволяє додавати або відключати мідлвар без зміни існуючого коду, що спрощує тестування та A/B-тестування експериментальних модулів.

Відмінність від Interceptor

Мідлвар — загальний патерн, Interceptor — його окремий випадок для HTTP. Мідлвар працює з будь-якими потоками даних: actions у Redux, події в Bloc, HTTP-запити в Ktor. Interceptor завжди прив'язаний до мережевого шару та працює тільки з Request/Response. Розуміння цієї відмінності допомагає вибрати правильну абстракцію: для логування дій користувача — мідлвар, для додавання заголовків — Interceptor. У великих проєктах обидва патерни часто співіснують: мідлвар управляє станом, Interceptor — HTTP-комунікаціями.

Мідлвар в управлінні станом

Redux мідлвар перехоплює кожен dispatch action до того, як він потрапить у reducer. Це дозволяє логувати дії, виконувати асинхронні запити через Redux Thunk або Redux Saga, модифікувати action або скасовувати його за умовою. Кожен мідлвар отримує store (доступ до стану), next (посилання на наступний мідлвар або reducer) та action, вирішуючи, що робити: передати action далі, модифікувати його або заблокувати.

Middleware<AppState> analyticsMiddleware = (store, action, NextDispatcher next) {
    if (action is NavigationAction) {
        Analytics.logEvent(action.screenName);
    }
    return next(action);
};

final store = Store<AppState>>(
    reducer,
    initialState,
    middleware: [analyticsMiddleware]
);

Приклад analyticsMiddleware на Dart для Flutter Redux. Мідлвар перехоплює всі NavigationAction, логує назву екрану в аналітичну систему та викликає next(action) для продовження ланцюжка. Якби next не була викликана, action не дійшов би до reducer — так можна реалізувати умовну навігацію або блокування небажаних дій. Порядок мідлвару в масиві визначає черговість обробки.

Асинхронні мідлвари: Thunk та Saga

Redux Thunk — мідлвар, що дозволяє диспатчити не тільки action-об'єкти, але й функції. Функція отримує dispatch та getState, може виконувати async-операції (API-запити через HTTP-клієнт, читання з БД) та диспатчити звичайні actions після завершення. Це стандартний підхід для роботи з мережевими запитами в Redux-додатках. Redux Saga використовує генератори (yield) для більш складних сценаріїв: скасування запитів, race conditions, паралельні операції та дебаунс введення користувача. За даними Redux Saga (2026), корутини Saga легше тестувати та налагоджувати, ніж вкладені колбеки Thunk.

Мідлвар в HTTP-клієнтах

Ktor Client від JetBrains будує HTTP-обробку на основі pipeline мідлвару. Кожен етап запиту — встановлення з'єднання, відправка заголовків, читання відповіді — представлений окремою фазою в pipeline. Розробник встановлює плагіни (мідлвар) через client.install { }, отримуючи ланцюжок обробки. Порядок встановлення визначає, який мідлвар обробляє дані першим: Logging, Auth, ContentNegotiation, Caching.

val client = HttpClient {
    install(Logging) {
        level = LogLevel.BODY
    }
    install(Auth) {
        bearer {
            loadTokens { BearerTokens("access", "refresh") }
        }
    }
    install(ContentNegotiation) {
        json(Json { ignoreUnknownKeys = true })
    }
    install(HttpTimeout) {
        requestTimeoutMillis = 15000
    }
}

Конфігурація Ktor Client із встановленими мідлвар-плагінами. Logging — пише тіло запиту та відповіді. Auth — автоматично додає Bearer-токен із підтримкою refresh. ContentNegotiation — серіалізує/десеріалізує JSON. HttpTimeout — задає таймаути. Кожен плагін незалежний: у тестовому середовищі можна відключити Auth, замінивши конфігурацію клієнта, не змінюючи коду запитів.

Dio Interceptor у Flutter

Dio — популярний HTTP-клієнт для Flutter, що використовує Interceptor у ролі мідлвару. Interceptor перехоплює RequestOptions перед відправкою та Response після отримання, підтримуючи ланцюжок із декількох перехоплювачів. Dio Interceptor — аналог OkHttp Interceptor для Dart/Flutter. За даними Dio (2026), RetryInterceptor та LogInterceptor — найбільш часто використовувані мідлвари в Flutter-проєктах.

Мідлвар в архітектурі Bloc

Bloc не має вбудованого мідлвару як окремого компонента, але патерн реалізується через BlocObserver — глобальний спостерігач, що отримує події кожного блоку в додатку. BlocObserver.onEvent викликається перед обробкою кожної події, onTransition — при кожному переході стану, onError — при кожному виключенні. Це повноцінний мідлвар для аналітики, логування, краш-репортингу та моніторингу продуктивності.

class AppBlocObserver extends BlocObserver {
    @override
    void onEvent(Bloc bloc, Object? event) {
        Crashlytics.log("${bloc.runtimeType}: $event");
        super.onEvent(bloc, event);
    }

    @override
    void onTransition(Bloc bloc, Transition transition) {
        Analytics.log(transition.eventName());
        super.onTransition(bloc, transition);
    }

    @override
    void onError(Bloc bloc, Object error, StackTrace stackTrace) {
        Crashlytics.recordError(error, stackTrace);
        super.onError(bloc, error, stackTrace);
    }
}

BlocOverrides.runZoned(() {
    runApp(MyApp());
}, blocObserver: AppBlocObserver());

Приклад AppBlocObserver — мідлвар для Bloc на Dart. onEvent логує кожну подію в Crashlytics, onTransition відправляє події в аналітику, onError записує виключення в краш-репортинг. Підключення через BlocOverrides.runZoned робить спостерігача глобальним для всіх блоків без зміни їх коду. Для відключення в тестах достатньо передати порожнього спостерігача або не перевизначати BlocOverrides.

Коли та як застосовувати мідлвар

Мідлвар ефективний для завдань, що зачіпають багато компонентів: логування, автентифікація, аналітика, кешування, моніторинг продуктивності. Використовуйте мідлвар, коли одна й та сама логіка повторюється в різних частинах додатка — додавання токена в кожен запит, логування кожної дії користувача, аналітика кожного переходу між екранами. За даними Dio (2026), централізована обробка через мідлвар знижує кількість багів на 25% порівняно з дублюванням коду в кожному компоненті окремо.

• Не зловживайте — надмірна кількість мідлвару ускладнює налагодження та знижує продуктивність через додаткові виклики
• Порядок має значення — перший мідлвар отримує дані у вихідному вигляді, останній — після всіх модифікацій
• Async-операції — виносьте важкі виклики в асинхронні мідлвари, не блокуючи основний потік UI
• Тестованість — кожен мідлвар має бути ізольовано протестований через mock-середовища
• Документуйте ланцюжок — явно описуйте, які мідлвари та в якому порядку підключені в проєкті

Помилки при використанні мідлвару

Найчастіша помилка — порушення порядку мідлвару, коли перший перехоплювач очікує дані, які додає другий. Друга за частотою — блокуючі операції в мідлварі на головному потоці: запис у файл, синхронні HTTP-виклики, шифрування. Третя — відсутність обробки виключень: якщо мідлвар викине виключення, весь ланцюжок перерветься і action не дійде до reducer або запит не відправиться. Завжди обгортайте логіку мідлвару в try-catch та логуйте помилки в Crashlytics або Sentry, не перериваючи ланцюжок. Регулярно перевіряйте ланцюжок мідлвару на рев'ю коду — це запобігає деградації архітектури.