Middleware για κινητές εφαρμογές — βασικές αρχές, αρχιτεκτονική και εφαρμογή

Τι είναι το Middleware;

Middleware — ένα επίπεδο λογισμικού που βρίσκεται μεταξύ δύο στοιχείων του συστήματος, παρεμποδίζοντας και επεξεργάζοντας δεδομένα πριν από τη μετάδοση στο στοιχείο προορισμού. Στην κινητή ανάπτυξη, το middleware εφαρμόζεται σε τρία κύρια πλαίσια: διαχείριση κατάστασης (Redux, Bloc), επικοινωνία HTTP (Ktor Client, Dio) και επεξεργασία συμβάντων (EventBus, NotificationCenter). Η κύρια αξία — απομόνωση διατομεακών εργασιών (καταγραφή, αυθεντικοποίηση, αναλυτική) από την επιχειρηματική λογική της εφαρμογής. Αντί να προσθέτετε κλήση αναλυτικής σε κάθε οθόνη, το middleware το κάνει κεντρικά.

Αρχιτεκτονική Pipe and Filter

Το middleware υλοποιεί το μοτίβο Pipe and Filter: κάθε στοιχείο middleware λαμβάνει δεδομένα, τα επεξεργάζεται και τα μεταδίδει στον επόμενο κρίκο της αλυσίδας. Η σειρά σύνδεσης του middleware καθορίζει την ακολουθία επεξεργασίας — το πρώτο middleware λαμβάνει τα αρχικά δεδομένα, το τελευταίο τα μεταδίδει στον επεξεργαστή προορισμού. Σύμφωνα με δεδομένα του JetBrains (2026), αυτή η αρχιτεκτονική επιτρέπει την προσθήκη ή απενεργοποίηση middleware χωρίς τροποποίηση του υπάρχοντος κώδικα, διευκολύνοντας τη δοκιμή και τη δοκιμή A/B πειραματικών λειτουργικών μονάδων.

Διαφορά από Interceptor

Middleware — γενικό μοτίβο, Interceptor — η ειδική περίπτωσή του για HTTP. Το middleware λειτουργεί με οποιαδήποτε ροή δεδομένων: actions στο Redux, συμβάντα στο Bloc, HTTP αιτήματα στο Ktor. Το Interceptor είναι πάντα συνδεδεμένο με το επίπεδο δικτύου και λειτουργεί μόνο με Request/Response. Η κατανόηση αυτής της διαφοράς βοηθά στην επιλογή της σωστής αφαίρεσης: για καταγραφή ενεργειών χρήστη — middleware, για προσθήκη κεφαλίδων — Interceptor. Σε μεγάλα έργα, και τα δύο μοτίβα συνυπάρχουν συχνά: το middleware διαχειρίζεται την κατάσταση, το Interceptor — την επικοινωνία HTTP.

Middleware στη διαχείριση κατάστασης

Redux middleware παρεμποδίζει κάθε dispatch action πριν φτάσει στον reducer. Αυτό επιτρέπει την καταγραφή ενεργειών, την εκτέλεση ασύγχρονων αιτημάτων μέσω Redux Thunk ή Redux Saga, την τροποποίηση του action ή την ακύρωσή του υπό όρους. Κάθε middleware λαμβάνει store (πρόσβαση στην κατάσταση), next (αναφορά στο επόμενο middleware ή 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. Το middleware παρεμποδίζει όλα τα NavigationAction, καταγράφει το όνομα της οθόνης στο αναλυτικό σύστημα και καλεί το next(action) για συνέχιση της αλυσίδας. Εάν το next δεν είχε κληθεί, το action δεν θα έφτανε στον reducer — έτσι μπορεί να υλοποιηθεί υπό όρους πλοήγηση ή μπλοκάρισμα ανεπιθύμητων ενεργειών. Η σειρά των middleware στον πίνακα καθορίζει τη σειρά επεξεργασίας.

Ασύγχρονα middleware: Thunk και Saga

Redux Thunk — middleware που επιτρέπει dispatch όχι μόνο αντικειμένων action, αλλά και συναρτήσεων. Η συνάρτηση λαμβάνει dispatch και getState, μπορεί να εκτελεί async λειτουργίες (αιτήματα API μέσω http πελάτη, ανάγνωση από βάση δεδομένων) και να κάνει dispatch συνηθισμένα actions μετά την ολοκλήρωση. Αυτή είναι η τυπική προσέγγιση για εργασία με αιτήματα δικτύου σε εφαρμογές Redux. Redux Saga χρησιμοποιεί γεννήτριες (yield) για πιο σύνθετα σενάρια: ακύρωση αιτημάτων, race conditions, παράλληλες λειτουργίες και debounce εισόδου χρήστη. Σύμφωνα με δεδομένα του Redux Saga (2026), οι κορουτίνες Saga είναι ευκολότερο να δοκιμαστούν και να εντοπιστούν σφάλματα από τα ένθετα callbacks του Thunk.

Middleware σε HTTP πελάτες

Ktor Client από τη JetBrains χτίζει την επεξεργασία HTTP βάσει pipeline middleware. Κάθε στάδιο ενός αιτήματος — δημιουργία σύνδεσης, αποστολή κεφαλίδων, ανάγνωση απάντησης — αντιπροσωπεύεται από ξεχωριστή φάση στο pipeline. Ο προγραμματιστής εγκαθιστά πρόσθετα (middleware) μέσω client.install { }, αποκτώντας μια αλυσίδα επεξεργασίας. Η σειρά εγκατάστασης καθορίζει ποιο middleware επεξεργάζεται πρώτο τα δεδομένα: 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 με εγκατεστημένα πρόσθετα middleware. Logging — γράφει το περιεχόμενο του αιτήματος και της απάντησης. Auth — προσθέτει αυτόματα το διακριτικό Bearer με υποστήριξη ανανέωσης. ContentNegotiation — σειριοποιεί/αποσειριοποιεί JSON. HttpTimeout — ορίζει χρονικά όρια. Κάθε πρόσθετο είναι ανεξάρτητο: σε περιβάλλον δοκιμής, το Auth μπορεί να απενεργοποιηθεί αλλάζοντας τη διαμόρφωση του πελάτη, χωρίς να τροποποιηθεί ο κώδικας των αιτημάτων.

Dio Interceptor στο Flutter

Dio — δημοφιλής HTTP πελάτης για Flutter που χρησιμοποιεί το Interceptor ως middleware. Το Interceptor παρεμποδίζει το RequestOptions πριν από την αποστολή και το Response μετά τη λήψη, υποστηρίζοντας μια αλυσίδα πολλών παρεμποδιστών. Το Dio Interceptor — το αντίστοιχο του OkHttp Interceptor για Dart/Flutter. Σύμφωνα με δεδομένα του Dio (2026), τα RetryInterceptor και LogInterceptor είναι τα πιο συχνά χρησιμοποιούμενα middleware σε έργα Flutter.

Middleware στην αρχιτεκτονική Bloc

Bloc δεν έχει ενσωματωμένο middleware ως ξεχωριστό στοιχείο, αλλά το μοτίβο υλοποιείται μέσω BlocObserver — ενός καθολικού παρατηρητή που λαμβάνει συμβάντα κάθε μπλοκ στην εφαρμογή. Το BlocObserver.onEvent καλείται πριν από την επεξεργασία κάθε συμβάντος, onTransition — σε κάθε μετάβαση κατάστασης, onError — σε κάθε εξαίρεση. Αυτό είναι ένα πλήρες middleware για αναλυτική, καταγραφή, αναφορά σφαλμάτων και παρακολούθηση απόδοσης.

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 — middleware για Bloc σε Dart. Το onEvent καταγράφει κάθε συμβάν στο Crashlytics, το onTransition στέλνει συμβάντα στην αναλυτική, το onError γράφει εξαιρέσεις στην αναφορά σφαλμάτων. Η σύνδεση μέσω BlocOverrides.runZoned καθιστά τον παρατηρητή καθολικό για όλα τα μπλοκ χωρίς τροποποίηση του κώδικά τους. Για απενεργοποίηση σε δοκιμές, αρκεί να μεταβιβάσετε έναν κενό παρατηρητή ή να μην παρακάμψετε το BlocOverrides.

Πότε και πώς να εφαρμόζετε το Middleware

Το middleware είναι αποτελεσματικό για εργασίες που επηρεάζουν πολλαπλά στοιχεία: καταγραφή, αυθεντικοποίηση, αναλυτική, προσωρινή αποθήκευση, παρακολούθηση απόδοσης. Χρησιμοποιήστε middleware όταν η ίδια λογική επαναλαμβάνεται σε διαφορετικά μέρη της εφαρμογής — προσθήκη διακριτικού σε κάθε αίτημα, καταγραφή κάθε ενέργειας χρήστη, αναλυτική κάθε μετάβασης μεταξύ οθονών. Σύμφωνα με δεδομένα του Dio (2026), η κεντρική επεξεργασία μέσω middleware μειώνει τον αριθμό σφαλμάτων κατά 25% σε σύγκριση με την επανάληψη κώδικα σε κάθε στοιχείο ξεχωριστά.

• Μην το παρακάνετε — ο υπερβολικός αριθμός middleware δυσκολεύει τον εντοπισμό σφαλμάτων και μειώνει την απόδοση λόγω πρόσθετων κλήσεων
• Η σειρά έχει σημασία — το πρώτο middleware λαμβάνει δεδομένα στην αρχική μορφή, το τελευταίο — μετά από όλες τις τροποποιήσεις
• Ασύγχρονες λειτουργίες — μεταφέρετε βαριές κλήσεις σε ασύγχρονα middleware, χωρίς να μπλοκάρετε το κύριο νήμα UI
• Δυνατότητα δοκιμής — κάθε middleware πρέπει να δοκιμάζεται απομονωμένα μέσω περιβαλλόντων προσομοίωσης
• Τεκμηριώστε την αλυσίδα — περιγράψτε ρητά ποια middleware και με ποια σειρά είναι συνδεδεμένα στο έργο

Σφάλματα στη χρήση middleware

Το πιο συνηθισμένο σφάλμα — παραβίαση της σειράς middleware, όταν ο πρώτος παρεμποδιστής αναμένει δεδομένα που προσθέτει ο δεύτερος. Το δεύτερο πιο συχνό — λειτουργίες αποκλεισμού σε middleware στο κύριο νήμα: εγγραφή σε αρχείο, σύγχρονες κλήσεις HTTP, κρυπτογράφηση. Το τρίτο — έλλειψη διαχείρισης εξαιρέσεων: εάν το middleware ρίξει εξαίρεση, ολόκληρη η αλυσίδα διακόπτεται και το action δεν φτάνει στον reducer ή το αίτημα δεν αποστέλλεται. Πάντα τυλίγετε τη λογική middleware σε try-catch και καταγράφετε σφάλματα στο Crashlytics ή Sentry χωρίς να διακόπτετε την αλυσίδα. Ελέγχετε τακτικά την αλυσίδα middleware κατά την αναθεώρηση κώδικα — αυτό αποτρέπει την υποβάθμιση της αρχιτεκτονικής.