Co to jest middleware? Definicja, rodzaje i przykłady z kodem

Middleware, czyli oprogramowanie pośredniczące, to warstwa kodu umieszczona pomiędzy aplikacjami, systemem operacyjnym a danymi, która przejmuje komunikację i wspólne zadania, takie jak przesyłanie wiadomości, uwierzytelnianie czy dostęp do bazy. Dzięki niemu aplikacje nie muszą znać szczegółów działania siebie nawzajem — rozmawiają z middleware, a ono dba o resztę.

Termin ma w praktyce dwa znaczenia. W architekturze systemów middleware to osobne oprogramowanie, np. broker wiadomości RabbitMQ albo serwer aplikacji. W programowaniu webowym to funkcja w łańcuchu obsługi żądania HTTP, np. w Express.js czy Laravelu. Poniżej oba znaczenia z przykładami.

Middleware w prostych słowach: analogia i definicja

Wyobraź sobie firmę, w której dział sprzedaży pracuje w CRM, magazyn w systemie WMS, a księgowość w ERP. Każdy z tych systemów mówi „innym językiem”: inny format danych, inny protokół, inna baza. Bez pośrednika każdy musiałby mieć osobne połączenie z każdym — przy kilku systemach to kilkanaście integracji do utrzymania.

Middleware jest tym pośrednikiem. Przyjmuje dane od jednego systemu, ewentualnie je przekształca i przekazuje do drugiego. Może też zapewnić, że wiadomość nie zginie, gdy odbiorca chwilowo nie działa, albo że do systemu nie dostanie się nikt nieuprawniony.

Formalnie: middleware to oprogramowanie, które udostępnia aplikacjom usługi wykraczające poza to, co daje system operacyjny — komunikację, zarządzanie transakcjami, bezpieczeństwo, dostęp do danych — i ukrywa przed nimi szczegóły sieci oraz heterogenicznych platform.

Rodzaje middleware w architekturze systemów

Middleware komunikatów — przykład z życia

Sklep internetowy przyjmuje zamówienie. Zamiast synchronicznie wywoływać po kolei system płatności, magazyn, wysyłkę maili i fakturowanie (i czekać na każdy z nich), aplikacja publikuje jedno zdarzenie „zamówienie złożone” do brokera. Każdy z systemów subskrybuje to zdarzenie i obsługuje je we własnym tempie.

Korzyści są konkretne: awaria modułu maili nie blokuje składania zamówień, a wiadomość poczeka w kolejce do jego powrotu. Nowy system (np. analityka) podłączasz, dodając subskrybenta, bez zmian w sklepie. Kosztem jest dodatkowy element infrastruktury do utrzymania i myślenie w kategoriach spójności ostatecznej (eventual consistency).

Middleware bazodanowe

Gdy aplikacja w Javie łączy się z bazą przez JDBC, a raport w Excelu przez ODBC, oba sterowniki są właśnie middleware — tłumaczą standardowe wywołania na protokół konkretnej bazy. Wyżej w stosie działają poolery połączeń, np. PgBouncer przed PostgreSQL, które pozwalają setkom procesów aplikacji współdzielić kilkadziesiąt połączeń z bazą. Jeśli wybierasz silnik bazy, przyda się przegląd najpopularniejszych systemów baz danych.

API gateway

W architekturze mikrousług klient nie powinien znać adresów kilkudziesięciu serwisów. API gateway przyjmuje wszystkie żądania, sprawdza token, nakłada limity zapytań, loguje ruch i przekazuje żądanie do właściwej usługi. Jeśli dopiero zaczynasz z API, zajrzyj do wprowadzenia do REST API.

Middleware w frameworkach webowych: łańcuch obsługi żądania

W kontekście frameworków webowych middleware to funkcja (lub klasa), przez którą przechodzi każde żądanie HTTP, zanim trafi do właściwego kontrolera, i każda odpowiedź w drodze powrotnej. Kilka takich funkcji tworzy łańcuch, nazywany też potokiem (pipeline).

Typowe zadania middleware w aplikacji webowej:

• logowanie żądań i mierzenie czasu odpowiedzi,
• uwierzytelnianie i autoryzacja (czy użytkownik jest zalogowany, czy ma rolę admina),
• nagłówki CORS i nagłówki bezpieczeństwa,
• parsowanie treści żądania (JSON, formularze),
• ograniczanie liczby zapytań (rate limiting),
• kompresja odpowiedzi, obsługa sesji, ochrona CSRF,
• globalna obsługa błędów.

Każdy element może przepuścić żądanie dalej, zmodyfikować je albo zakończyć łańcuch własną odpowiedzią (np. 401 Unauthorized). To w gruncie rzeczy wzorzec łańcucha zobowiązań (chain of responsibility).

Przykład: Express.js (Node.js)

const express = require('express');
const app = express();

// middleware logujący każde żądanie i czas odpowiedzi
function logger(req, res, next) {
  const start = Date.now();
  res.on('finish', () => {
    console.log(`${req.method} ${req.originalUrl} ${res.statusCode} ${Date.now() - start} ms`);
  });
  next(); // przekaż żądanie dalej
}

// middleware sprawdzający klucz API
function requireApiKey(req, res, next) {
  if (req.get('X-API-Key') !== process.env.API_KEY) {
    return res.status(401).json({ error: 'Brak autoryzacji' }); // przerwanie łańcucha
  }
  next();
}

app.use(express.json()); // wbudowany middleware parsujący JSON
app.use(logger);         // działa dla wszystkich tras

app.get('/api/zamowienia', requireApiKey, (req, res) => {
  res.json([{ id: 1, status: 'nowe' }]);
});

app.listen(3000);

Kluczowe jest wywołanie next(). Jeśli middleware go nie wywoła ani nie wyśle odpowiedzi, żądanie „zawiśnie” do timeoutu.

Przykład: Django (Python)

# mojaaplikacja/middleware.py
import time

class TimingMiddleware:
    def __init__(self, get_response):
        self.get_response = get_response

    def __call__(self, request):
        start = time.monotonic()
        response = self.get_response(request)  # dalsza część łańcucha i widok
        response["X-Response-Time"] = f"{(time.monotonic() - start) * 1000:.0f}ms"
        return response

Middleware rejestrujesz w settings.py, dopisując "mojaaplikacja.middleware.TimingMiddleware" do listy MIDDLEWARE. Kolejność na liście to kolejność wykonywania dla żądania; dla odpowiedzi jest odwrotna.

Przykład: Laravel (PHP)

php artisan make:middleware EnsureUserIsAdmin

// app/Http/Middleware/EnsureUserIsAdmin.php
public function handle(Request $request, Closure $next): Response
{
    if (! $request->user()?->is_admin) {
        abort(403);
    }

    return $next($request);
}

W Laravelu 11 i nowszych alias rejestrujesz w bootstrap/app.php w sekcji ->withMiddleware(...), np. $middleware->alias(['admin' => EnsureUserIsAdmin::class]);, a potem używasz go w trasach: Route::middleware('admin')->group(...). Jeśli PHP jest dla Ciebie nowe, zacznij od krótkiego wprowadzenia do PHP.

Przykład: ASP.NET Core (C#)

var app = WebApplication.Create(args);

app.Use(async (context, next) =>
{
    // kod przed dalszą częścią potoku
    context.Response.Headers["X-Content-Type-Options"] = "nosniff";
    await next.Invoke();
    // kod po powrocie z potoku (nie modyfikuj już treści odpowiedzi)
});

app.MapGet("/", () => "Witaj");
app.Run();

Microsoft w dokumentacji podkreśla, że kolejność wywołań app.Use... definiuje kolejność potoku — np. obsługa wyjątków musi być na początku, a autoryzacja po routingu i uwierzytelnianiu.

Na co uważać przy pisaniu i wdrażaniu middleware

1. Kolejność ma znaczenie. Middleware autoryzacji umieszczony po kontrolerze nic nie chroni. Globalna obsługa błędów powinna być na początku, żeby złapać wyjątki z całej reszty łańcucha.
2. Nie traktuj middleware jako jedynej warstwy bezpieczeństwa. W marcu 2025 r. ujawniono lukę CVE-2025-29927 w Next.js, w której specjalny nagłówek żądania pozwalał całkowicie pominąć middleware — także ten sprawdzający logowanie. Sprawdzaj uprawnienia również bliżej danych.
3. Uważaj na wydajność. Middleware globalny działa przy każdym żądaniu, także dla plików statycznych. Ciężkie zapytanie do bazy w takim miejscu potrafi zwielokrotnić obciążenie.
4. Zawsze przekaż sterowanie lub zakończ żądanie. Brak next() czy $next($request) to klasyczny błąd skutkujący wiszącymi połączeniami.
5. W infrastrukturze — monitoruj pośrednika. Broker wiadomości czy API gateway to pojedynczy punkt awarii, jeśli nie jest redundantny. Kolejki, które rosną, bo konsument przestał działać, trzeba wykrywać alertami.

Wskazówka: Next.js w wersji 16 zmienił nazwę pliku middleware.ts na proxy.ts, żeby podkreślić, że ten kod działa przed routingiem jako warstwa sieciowa. Jeśli trafisz na starsze tutoriale, nazwa pliku może się różnić od tej w Twoim projekcie.

Middleware a API, ESB i mikrousługi – jak się to łączy

Te pojęcia często są mieszane, więc krótko:

• API to interfejs — umowa, jak komunikować się z systemem. Middleware zwykle udostępnia API albo z nich korzysta, ale samo API middleware’em nie jest.
• ESB to jeden z rodzajów middleware: centralna szyna z logiką routingu i transformacji. Popularny w dużych firmach w latach 2005–2015, dziś często zastępowany lżejszym podejściem — brokerem zdarzeń i „inteligentnymi” usługami na końcach.
• Mikrousługi zwiększyły zapotrzebowanie na middleware: brokery zdarzeń, API gateway i service mesh to dziś standard w środowiskach opartych na kontenerach. Jeśli porządkujesz pojęcia w tym obszarze, przyda się tekst Kubernetes vs Docker – różnice.

Kiedy w ogóle potrzebujesz middleware

W aplikacji webowej middleware pojawi się prawie zawsze — każdy nowoczesny framework ma go wbudowanego, a Ty dopisujesz własne elementy, gdy jakaś logika dotyczy wielu tras naraz. Zasada praktyczna: jeśli ten sam kod (sprawdzenie tokena, nagłówek, log) kopiujesz do trzeciego kontrolera, to kandydat na middleware.

Na poziomie architektury osobne oprogramowanie pośredniczące ma sens, gdy integrujesz kilka systemów, potrzebujesz niezawodnej komunikacji asynchronicznej albo chcesz odciąć klientów od wewnętrznej struktury usług. W małym projekcie z jedną aplikacją i jedną bazą broker wiadomości czy ESB to zwykle niepotrzebna złożoność — wystarczy dobrze zaprojektowane API.