Middleware untuk Aplikasi Seluler — dasar, arsitektur, dan penerapan

Apa itu Middleware?

Middleware — lapisan perangkat lunak yang terletak di antara dua komponen sistem, mencegat dan memproses data sebelum dikirim ke komponen tujuan. Dalam pengembangan seluler, middleware diterapkan dalam tiga konteks utama: manajemen state (Redux, Bloc), komunikasi HTTP (Ktor Client, Dio), dan pemrosesan peristiwa (EventBus, NotificationCenter). Nilai utamanya — isolasi tugas lintas sektor (logging, autentikasi, analitik) dari logika bisnis aplikasi. Alih-alih menambahkan panggilan analitik di setiap layar, middleware melakukannya secara terpusat.

Arsitektur Pipe and Filter

Middleware mengimplementasikan pola Pipe and Filter: setiap komponen middleware menerima data, memprosesnya, dan meneruskannya ke mata rantai berikutnya. Urutan koneksi middleware menentukan urutan pemrosesan — middleware pertama menerima data asli, yang terakhir meneruskannya ke pemroses tujuan. Menurut data JetBrains (2026), arsitektur ini memungkinkan penambahan atau penonaktifan middleware tanpa mengubah kode yang ada, yang memudahkan pengujian dan pengujian A/B modul eksperimental.

Perbedaan dari Interceptor

Middleware — pola umum, Interceptor — kasus khusus untuk HTTP. Middleware bekerja dengan semua aliran data: action di Redux, peristiwa di Bloc, permintaan HTTP di Ktor. Interceptor selalu terikat pada lapisan jaringan dan hanya bekerja dengan Request/Response. Memahami perbedaan ini membantu memilih abstraksi yang tepat: untuk logging tindakan pengguna — middleware, untuk menambahkan header — Interceptor. Dalam proyek besar, kedua pola sering hidup berdampingan: middleware mengelola state, Interceptor — komunikasi HTTP.

Middleware dalam Manajemen State

Redux middleware mencegat setiap dispatch action sebelum mencapai reducer. Ini memungkinkan logging tindakan, menjalankan permintaan asinkron melalui Redux Thunk atau Redux Saga, memodifikasi action, atau membatalkannya secara kondisional. Setiap middleware menerima store (akses ke state), next (referensi ke middleware atau reducer berikutnya), dan action, memutuskan apa yang harus dilakukan: meneruskan action, memodifikasinya, atau memblokirnya.

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

Contoh analyticsMiddleware di Dart untuk Flutter Redux. Middleware mencegat semua NavigationAction, mencatat nama layar ke sistem analitik, dan memanggil next(action) untuk melanjutkan rantai. Jika next tidak dipanggil, action tidak akan mencapai reducer — dengan demikian navigasi bersyarat atau pemblokiran tindakan yang tidak diinginkan dapat diimplementasikan. Urutan middleware dalam array menentukan urutan pemrosesan.

Middleware Asinkron: Thunk dan Saga

Redux Thunk — middleware yang memungkinkan dispatch tidak hanya objek action, tetapi juga fungsi. Fungsi menerima dispatch dan getState, dapat menjalankan operasi async (permintaan API melalui klien http, membaca dari basis data) dan melakukan dispatch action biasa setelah selesai. Ini adalah pendekatan standar untuk bekerja dengan permintaan jaringan di aplikasi Redux. Redux Saga menggunakan generator (yield) untuk skenario yang lebih kompleks: pembatalan permintaan, race conditions, operasi paralel, dan debounce input pengguna. Menurut data Redux Saga (2026), korutin Saga lebih mudah diuji dan di-debug daripada callback bersarang Thunk.

Middleware dalam Klien HTTP

Ktor Client dari JetBrains membangun pemrosesan HTTP berdasarkan pipeline middleware. Setiap tahap permintaan — pembuatan koneksi, pengiriman header, pembacaan respons — diwakili oleh fase terpisah dalam pipeline. Pengembang menginstal plugin (middleware) melalui client.install { }, mendapatkan rantai pemrosesan. Urutan instalasi menentukan middleware mana yang memproses data terlebih dahulu: 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
    }
}

Konfigurasi Ktor Client dengan plugin middleware yang terinstal. Logging — menulis konten permintaan dan respons. Auth — secara otomatis menambahkan token Bearer dengan dukungan refresh. ContentNegotiation — menyerialisasi/deserialisasi JSON. HttpTimeout — menetapkan batas waktu. Setiap plugin independen: di lingkungan pengujian, Auth dapat dinonaktifkan dengan mengubah konfigurasi klien, tanpa mengubah kode permintaan.

Dio Interceptor di Flutter

Dio — klien HTTP populer untuk Flutter yang menggunakan Interceptor sebagai middleware. Interceptor mencegat RequestOptions sebelum dikirim dan Response setelah diterima, mendukung rantai beberapa pencegat. Dio Interceptor — padanan OkHttp Interceptor untuk Dart/Flutter. Menurut data Dio (2026), RetryInterceptor dan LogInterceptor adalah middleware yang paling sering digunakan dalam proyek Flutter.

Middleware dalam Arsitektur Bloc

Bloc tidak memiliki middleware bawaan sebagai komponen terpisah, tetapi pola ini diimplementasikan melalui BlocObserver — pengamat global yang menerima peristiwa setiap blok dalam aplikasi. BlocObserver.onEvent dipanggil sebelum pemrosesan setiap peristiwa, onTransition — pada setiap transisi state, onError — pada setiap pengecualian. Ini adalah middleware lengkap untuk analitik, logging, pelaporan kegagalan, dan pemantauan kinerja.

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

Contoh AppBlocObserver — middleware untuk Bloc di Dart. onEvent mencatat setiap peristiwa di Crashlytics, onTransition mengirim peristiwa ke analitik, onError menulis pengecualian ke pelaporan kegagalan. Koneksi melalui BlocOverrides.runZoned membuat pengamat global untuk semua blok tanpa mengubah kode mereka. Untuk menonaktifkan dalam pengujian, cukup berikan pengamat kosong atau jangan menimpa BlocOverrides.

Kapan dan Bagaimana Menerapkan Middleware

Middleware efektif untuk tugas yang mempengaruhi banyak komponen: logging, autentikasi, analitik, caching, pemantauan kinerja. Gunakan middleware ketika logika yang sama berulang di berbagai bagian aplikasi — menambahkan token ke setiap permintaan, mencatat setiap tindakan pengguna, analitik setiap transisi antar layar. Menurut data Dio (2026), pemrosesan terpusat melalui middleware mengurangi jumlah bug sebesar 25% dibandingkan dengan duplikasi kode di setiap komponen secara terpisah.

• Jangan berlebihan — jumlah middleware yang berlebihan mempersulit debugging dan menurunkan kinerja karena panggilan tambahan
• Urutan penting — middleware pertama menerima data dalam bentuk asli, yang terakhir — setelah semua modifikasi
• Operasi async — pindahkan panggilan berat ke middleware asinkron, jangan memblokir thread UI utama
• Kemampuan uji — setiap middleware harus diuji secara terisolasi melalui lingkungan mock
• Dokumentasikan rantai — jelaskan secara eksplisit middleware mana dan dalam urutan apa yang terhubung dalam proyek

Kesalahan dalam Menggunakan Middleware

Kesalahan paling umum — pelanggaran urutan middleware, ketika pencegat pertama mengharapkan data yang ditambahkan oleh pencegat kedua. Yang kedua paling sering — operasi pemblokiran di middleware pada thread utama: menulis ke file, panggilan HTTP sinkron, enkripsi. Yang ketiga — kurangnya penanganan pengecualian: jika middleware melempar pengecualian, seluruh rantai terputus dan action tidak mencapai reducer atau permintaan tidak terkirim. Selalu bungkus logika middleware dalam try-catch dan catat kesalahan di Crashlytics atau Sentry tanpa memutus rantai. Periksa rantai middleware secara teratur saat tinjauan kode — ini mencegah degradasi arsitektur.