Mobil tətbiqlər üçün Middleware — əsaslar, arxitektura və tətbiq

Middleware nədir?

Middleware — sistemin iki komponenti arasında yerləşən, məlumatları hədəf komponentə ötürməzdən əvvəl yaxalayan və emal edən proqram təbəqəsidir. Mobil inkişafda middleware üç əsas kontekstdə tətbiq olunur: vəziyyətin idarə edilməsi (Redux, Bloc), HTTP rabitəsi (Ktor Client, Dio) və hadisələrin emalı (EventBus, NotificationCenter). Əsas dəyər — bütün komponentlərə aid tapşırıqların təcrid edilməsi (login, autentifikasiya, analitika) tətbiqin biznes məntiqindən. Hər ekrana analitika çağırışı əlavə etmək əvəzinə, middleware bunu mərkəzləşdirilmiş şəkildə edir.

Pipe and Filter arxitekturası

Middleware Pipe and Filter nümunəsini həyata keçirir: hər bir middleware komponenti məlumatları alır, emal edir və zəncirin növbəti halqasına ötürür. Middleware-in qoşulma sırası emal ardıcıllığını müəyyən edir — birinci middleware orijinal məlumatları alır, sonuncu onları hədəf emalçıya ötürür. JetBrains (2026) məlumatlarına görə, belə arxitektura mövcud kodu dəyişmədən middleware əlavə etməyə və ya söndürməyə imkan verir ki, bu da test etməni və eksperimental modulların A/B testini asanlaşdırır.

Interceptor-dan fərqi

Middleware — ümumi nümunə, Interceptor — onun HTTP üçün xüsusi halıdır. Middleware istənilən məlumat axını ilə işləyir: Redux-da actionlar, Bloc-da hadisələr, Ktor-da HTTP sorğuları. Interceptor həmişə şəbəkə təbəqəsinə bağlıdır və yalnız Request/Response ilə işləyir. Bu fərqi anlamaq düzgün abstraksiyanı seçməyə kömək edir: istifadəçi hərəkətlərini login etmək üçün — middleware, başlıqlar əlavə etmək üçün — Interceptor. Böyük layihələrdə hər iki nümunə tez-tez birlikdə mövcud olur: middleware vəziyyəti idarə edir, Interceptor — HTTP rabitəsini.

Vəziyyətin idarə edilməsində Middleware

Redux middleware hər bir dispatch actionu reducerə çatmamış yaxalayır. Bu, hərəkətləri login etməyə, Redux Thunk və ya Redux Saga vasitəsilə asinxron sorğular yerinə yetirməyə, actionu dəyişdirməyə və ya şərti olaraq ləğv etməyə imkan verir. Hər bir middleware store (vəziyyətə giriş), next (növbəti middleware və ya reducerə istinad) və action alır, nə edəcəyinə qərar verir: actionu ötürmək, dəyişdirmək və ya bloklamaq.

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]
);

Flutter Redux üçün Dart dilində analyticsMiddleware nümunəsi. Middleware bütün NavigationAction-ları yaxalayır, ekranın adını analitik sistemə login edir və zənciri davam etdirmək üçün next(action) çağırır. Əgər next çağırılmasaydı, action reducerə çatmazdı — bu yolla şərti naviqasiya və ya arzuolunmaz hərəkətlərin bloklanması həyata keçirilə bilər. Middleware-lərin massivdə sırası emal ardıcıllığını müəyyən edir.

Asinxron middleware: Thunk və Saga

Redux Thunk — yalnız action obyektlərini deyil, həm də funksiyaları dispatch etməyə imkan verən middleware. Funksiya dispatch və getState alır, async əməliyyatları (http müştərisi vasitəsilə API sorğuları, verilənlər bazasından oxuma) yerinə yetirə və başa çatdıqdan sonra adi actionları dispatch edə bilər. Bu, Redux tətbiqlərində şəbəkə sorğuları ilə işləmək üçün standart yanaşmadır. Redux Saga daha mürəkkəb ssenarilər üçün generatorlardan (yield) istifadə edir: sorğuların ləğvi, race conditions, paralel əməliyyatlar və istifadəçi girişinin debounce-u. Redux Saga (2026) məlumatlarına görə, Saga korutinlərini test etmək və sazlamaq Thunk-ın iç-içə callbacklərindən daha asandır.

HTTP müştərilərində Middleware

Ktor Client JetBrains tərəfindən HTTP emalını pipeline middleware əsasında qurur. Sorğunun hər bir mərhələsi — əlaqənin qurulması, başlıqların göndərilməsi, cavabın oxunması — pipeline-da ayrıca faza ilə təmsil olunur. Tərtibatçı client.install { } vasitəsilə plaginlər (middleware) quraşdırır, emal zənciri əldə edir. Quraşdırma sırası hansı middleware-in məlumatları birinci emal etdiyini müəyyən edir: 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
    }
}

Quraşdırılmış middleware plaginləri ilə Ktor Client konfiqurasiyası. Logging — sorğu və cavabın məzmununu yazır. Auth — yeniləmə dəstəyi ilə avtomatik Bearer token əlavə edir. ContentNegotiation — JSON-u serializasiya/deserializasiya edir. HttpTimeout — vaxt məhdudiyyətlərini təyin edir. Hər bir plagin müstəqildir: test mühitində sorğu kodunu dəyişmədən müştəri konfiqurasiyasını dəyişərək Auth söndürülə bilər.

Flutter-da Dio Interceptor

Dio — Flutter üçün məşhur HTTP müştərisi, middleware rolunda Interceptor-dan istifadə edir. Interceptor göndərməzdən əvvəl RequestOptions-u və cavab aldıqdan sonra Response-u yaxalayır, bir neçə yaxalayıcıdan ibarət zənciri dəstəkləyir. Dio Interceptor — Dart/Flutter üçün OkHttp Interceptor-un analoqudur. Dio (2026) məlumatlarına görə, RetryInterceptor və LogInterceptor Flutter layihələrində ən çox istifadə olunan middleware-lərdir.

Bloc arxitekturasında Middleware

Bloc-un ayrıca komponent kimi daxili middleware-i yoxdur, lakin nümunə BlocObserver vasitəsilə həyata keçirilir — tətbiqdə hər bir blokun hadisələrini alan qlobal müşahidəçi. BlocObserver.onEvent hər bir hadisənin emalından əvvəl çağırılır, onTransition — hər vəziyyət dəyişikliyində, onError — hər istisnada. Bu, analitika, login, qəza hesabatı və performans monitorinqi üçün tam hüquqlu middleware-dir.

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());

Dart dilində Bloc üçün AppBlocObserver — middleware nümunəsi. onEvent hər hadisəni Crashlytics-ə login edir, onTransition hadisələri analitikaya göndərir, onError istisnaları qəza hesabatına yazır. BlocOverrides.runZoned vasitəsilə qoşulma müşahidəçini kodlarını dəyişmədən bütün bloklar üçün qlobal edir. Testlərdə söndürmək üçün boş müşahidəçi ötürmək və ya BlocOverrides-i dəyişməmək kifayətdir.

Middleware nə vaxt və necə tətbiq edilməlidir

Middleware effektivdir bir çox komponentə aid olan tapşırıqlar üçün: login, autentifikasiya, analitika, keşləmə, performans monitorinqi. Eyni məntiq tətbiqin müxtəlif hissələrində təkrarlandıqda middleware-dən istifadə edin — hər sorğuya token əlavə etmək, hər istifadəçi hərəkətini login etmək, ekranlar arası hər keçidin analitikası. Dio (2026) məlumatlarına görə, middleware vasitəsilə mərkəzləşdirilmiş emal hər komponentdə kodun təkrarlanması ilə müqayisədə səhvlərin sayını 25% azaldır.

• Həddən artıq istifadə etməyin — həddindən artıq middleware sayı sazlamağı çətinləşdirir və əlavə çağırışlar səbəbindən performansı azaldır
• Sıra vacibdir — birinci middleware məlumatları orijinal formada alır, sonuncu — bütün dəyişikliklərdən sonra
• Async əməliyyatları — ağır çağırışları asinxron middleware-ə köçürün, əsas UI ipliklərini bloklamayın
• Test edilə bilənlik — hər bir middleware mock mühitləri vasitəsilə təcrid olunmuş şəkildə test edilməlidir
• Zənciri sənədləşdirin — layihədə hansı middleware-lərin və hansı ardıcıllıqla qoşulduğunu açıq şəkildə təsvir edin

Middleware istifadəsində səhvlər

Ən geniş yayılmış səhv — middleware sırasının pozulması, birinci yaxalayıcı ikincinin əlavə etdiyi məlumatları gözlədikdə. Tezliyə görə ikinci — əsas iplikdə middleware-də bloklayan əməliyyatlar: fayla yazma, sinxron HTTP çağırışları, şifrələmə. Üçüncü — istisnaların işlənməsinin olmaması: middleware istisna atarsa, bütün zəncir qırılacaq və action reducerə çatmayacaq və ya sorğu göndərilməyəcək. Həmişə middleware məntiqini try-catch-ə sarın və zənciri qırmadan səhvləri Crashlytics və ya Sentry-də login edin. Müntəzəm olaraq middleware zəncirini kod icmalında yoxlayın — bu, arxitekturanın deqradasiyasının qarşısını alır.