Middleware para sa Mobile Apps — mga batayan, arkitektura, at aplikasyon

Ano ang Middleware?

Middleware — isang software layer na nakalagay sa pagitan ng dalawang component ng system, humaharang at nagpoproseso ng data bago ipadala sa target na component. Sa mobile development, inilalapat ang middleware sa tatlong pangunahing konteksto: pamamahala ng state (Redux, Bloc), HTTP communication (Ktor Client, Dio), at pagproseso ng event (EventBus, NotificationCenter). Ang pangunahing halaga — paghihiwalay ng mga cross-cutting na gawain (logging, authentication, analytics) mula sa business logic ng app. Sa halip na magdagdag ng analytics call sa bawat screen, ginagawa ito ng middleware nang sentralisado.

Pipe and Filter Architecture

Ipinapatupad ng middleware ang Pipe and Filter pattern: bawat middleware component ay tumatanggap ng data, pinoproseso ito, at ipinapasa sa susunod na chain. Tinutukoy ng pagkakasunud-sunod ng pagkonekta ng middleware ang sequence ng pagproseso — ang unang middleware ay tumatanggap ng orihinal na data, ang huli ay ipinapasa ito sa target na processor. Ayon sa datos ng JetBrains (2026), pinapayagan ng arkitekturang ito ang pagdaragdag o pag-disable ng middleware nang hindi binabago ang umiiral na code, na nagpapadali sa pag-test at A/B testing ng mga eksperimental na module.

Pagkakaiba sa Interceptor

Middleware — pangkalahatang pattern, Interceptor — partikular na kaso nito para sa HTTP. Gumagana ang middleware sa anumang data stream: actions sa Redux, events sa Bloc, HTTP requests sa Ktor. Ang Interceptor ay laging nakatali sa network layer at gumagana lamang sa Request/Response. Ang pag-unawa sa pagkakaibang ito ay tumutulong sa pagpili ng tamang abstraction: para sa pag-log ng mga aksyon ng user — middleware, para sa pagdagdag ng headers — Interceptor. Sa malalaking proyekto, madalas na magkasamang umiiral ang dalawang pattern: middleware ang namamahala ng state, Interceptor — ng HTTP communication.

Middleware sa Pamamahala ng State

Redux middleware humaharang sa bawat dispatch action bago ito umabot sa reducer. Pinapayagan nito ang pag-log ng mga aksyon, pagsasagawa ng mga asynchronous na request sa pamamagitan ng Redux Thunk o Redux Saga, pagbabago ng action, o pagkansela nito nang kondisyonal. Bawat middleware ay tumatanggap ng store (access sa state), next (reference sa susunod na middleware o reducer), at action, nagpapasya kung ano ang gagawin: ipasa ang action, baguhin ito, o harangin.

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

Halimbawa ng analyticsMiddleware sa Dart para sa Flutter Redux. Hinaharang ng middleware ang lahat ng NavigationAction, ni-log ang pangalan ng screen sa analytics system, at tinatawag ang next(action) para ipagpatuloy ang chain. Kung hindi tinawag ang next, hindi aabot ang action sa reducer — sa ganitong paraan maaaring ipatupad ang conditional navigation o pagharang ng mga hindi gustong aksyon. Tinutukoy ng pagkakasunud-sunod ng middleware sa array ang pagkakasunud-sunod ng pagproseso.

Asynchronous Middleware: Thunk at Saga

Redux Thunk — middleware na nagpapahintulot sa dispatch hindi lamang ng action objects, kundi pati na rin ng mga function. Ang function ay tumatanggap ng dispatch at getState, maaaring magsagawa ng async operations (API requests sa pamamagitan ng http client, pagbabasa mula sa database) at mag-dispatch ng mga regular na action pagkatapos matapos. Ito ang karaniwang approach para sa pagtatrabaho sa network requests sa Redux apps. Redux Saga ay gumagamit ng generators (yield) para sa mas kumplikadong scenarios: pagkansela ng requests, race conditions, parallel operations, at debounce ng user input. Ayon sa datos ng Redux Saga (2026), ang Saga coroutine ay mas madaling i-test at i-debug kaysa sa nested callbacks ng Thunk.

Middleware sa HTTP Clients

Ktor Client mula sa JetBrains ay bumubuo ng HTTP processing batay sa pipeline middleware. Bawat yugto ng request — pagtatatag ng koneksyon, pagpapadala ng headers, pagbabasa ng response — ay kinakatawan ng hiwalay na phase sa pipeline. Nag-install ang developer ng mga plugin (middleware) sa pamamagitan ng client.install { }, na nakakakuha ng processing chain. Tinutukoy ng pagkakasunud-sunod ng pag-install kung aling middleware ang unang magpoproseso ng data: 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
    }
}

Configuration ng Ktor Client na may naka-install na middleware plugins. Logging — isinusulat ang nilalaman ng request at response. Auth — awtomatikong nagdadagdag ng Bearer token na may suporta sa refresh. ContentNegotiation — serializes/deserializes JSON. HttpTimeout — nagtatakda ng mga timeout. Bawat plugin ay independyente: sa testing environment, maaaring i-disable ang Auth sa pamamagitan ng pagbabago ng configuration ng client, nang hindi binabago ang code ng mga request.

Dio Interceptor sa Flutter

Dio — sikat na HTTP client para sa Flutter na gumagamit ng Interceptor bilang middleware. Hinaharang ng Interceptor ang RequestOptions bago ipadala at Response pagkatapos matanggap, sumusuporta sa chain ng maraming interceptor. Ang Dio Interceptor — katumbas ng OkHttp Interceptor para sa Dart/Flutter. Ayon sa datos ng Dio (2026), ang RetryInterceptor at LogInterceptor ay ang pinakamadalas gamitin na middleware sa Flutter projects.

Middleware sa Bloc Architecture

Bloc ay walang built-in na middleware bilang hiwalay na component, ngunit ang pattern ay ipinapatupad sa pamamagitan ng BlocObserver — isang global observer na tumatanggap ng events ng bawat bloc sa app. Ang BlocObserver.onEvent ay tinatawag bago ang pagproseso ng bawat event, onTransition — sa bawat state transition, onError — sa bawat exception. Ito ay isang ganap na middleware para sa analytics, logging, crash reporting, at performance monitoring.

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

Halimbawa ng AppBlocObserver — middleware para sa Bloc sa Dart. onEvent ay nagla-log ng bawat event sa Crashlytics, onTransition ay nagpapadala ng events sa analytics, onError ay nagsusulat ng mga exception sa crash reporting. Ang pagkonekta sa pamamagitan ng BlocOverrides.runZoned ay gumagawa ng observer na global para sa lahat ng bloc nang hindi binabago ang kanilang code. Para i-disable sa tests, sapat na magbigay ng empty observer o hindi mag-override ng BlocOverrides.

Kailan at Paano Ilapat ang Middleware

Epektibo ang middleware para sa mga gawain na nakakaapekto sa maraming component: logging, authentication, analytics, caching, performance monitoring. Gumamit ng middleware kapag ang parehong lohika ay paulit-ulit sa iba't ibang bahagi ng app — pagdagdag ng token sa bawat request, pag-log ng bawat aksyon ng user, analytics ng bawat transition sa pagitan ng screens. Ayon sa datos ng Dio (2026), ang sentralisadong pagproseso sa pamamagitan ng middleware ay nagbabawas ng bilang ng mga bug ng 25% kumpara sa pagdoble ng code sa bawat component nang hiwalay.

• Huwag lumampas — ang sobrang dami ng middleware ay nagpapahirap sa debugging at nagpapababa ng performance dahil sa mga karagdagang tawag
• Mahalaga ang pagkakasunod-sunod — ang unang middleware ay tumatanggap ng data sa orihinal na anyo, ang huli — pagkatapos ng lahat ng pagbabago
• Async operations — ilipat ang mabibigat na tawag sa asynchronous middleware, huwag harangin ang main UI thread
• Testability — bawat middleware ay dapat na isolated na ma-test sa pamamagitan ng mock environments
• Idokumento ang chain — ilarawan nang malinaw kung aling middleware at sa anong pagkakasunod-sunod ang konektado sa proyekto

Mga Pagkakamali sa Paggamit ng Middleware

Ang pinakakaraniwang pagkakamali — paglabag sa pagkakasunod-sunod ng middleware, kapag ang unang interceptor ay umaasa ng data na idinadagdag ng pangalawa. Ang pangalawa sa dalas — mga blocking operation sa middleware sa main thread: pagsulat sa file, synchronous HTTP calls, encryption. Ang pangatlo — kawalan ng exception handling: kung ang middleware ay mag-throw ng exception, ang buong chain ay mapuputol at ang action ay hindi aabot sa reducer o ang request ay hindi maipapadala. Palaging balutin ang middleware logic sa try-catch at i-log ang mga error sa Crashlytics o Sentry nang hindi pinuputol ang chain. Regular na suriin ang middleware chain sa code review — ito ay pumipigil sa degradation ng architecture.