Express kontra Fastify w 2026 roku: Praktyczne porównanie frameworków Node.js

Załóżmy, że zespół rozpoczyna pracę nad nowym backendem w Node.js.

Zaczynają badać dostępne frameworki, a niemal od razu w rozmowach dominują dwa nazwy:

Express.js i Fastify.

Następnie pojawiają się wykresy porównawcze.

W wielu syntetycznych testach Fastify osiąga znacznie wyższe wartości przepustowości.

Powstaje naturalna reakcja:

"Jeśli Fastify wygrywa pod względem szybkości, to dlaczego ktoś miałby nadal używać Express?"

Z pozoru to słuszne pytanie.

Jednak wybór frameworka do backendu rzadko sprowadza się do jednego takiego wskaźnika.

Liczba surowych żądań na sekundę to tylko jeden element układanki. Należy również wziąć pod uwagę otaczający ekosystem, sposób działania middleware’u, wbudowaną weryfikację, wsparcie dla TypeScript, koszty migracji, codzienną pracę programistów, istniejącą bazę kodu, którą utrzymujesz, oraz to, czego faktycznie wymaga twoja aplikacja.

Należy również zwrócić uwagę na drugi aspekt tego porównania.

Express 5 został już oficjalnie wydany.

Po długim okresie używania Express 4, ta nowa główna wersja wprowadza kilka zmian, o których muszą wiedzieć wszyscy, którzy utrzymują starszą bazę kodu Express.

Mając to na uwadze, przyjrzyjmy się temu, co naprawdę odróżnia Express od Fastify – a co ważniejsze, sytuacjom, w których każdy z nich ma sens.

Najpierw: Co dokładnie to Express i Fastify?

Oba te frameworki istnieją po to, aby pomóc ci w budowaniu serwerów internetowych na bazie Node.js.

W swojej istocie oszczędzają ci konieczności pisania kodu bezpośrednio do modułu HTTP na niższym poziomie w Node, oferując czystsze API do definiowania tras i obsługi żądań.

Oto jak wygląda minimalny serwer Express:

const express = require("express");

const app = express();
app.get("/users", (req, res) => {
  res.json([
    { id: 1, name: "Neha" },
    { id: 2, name: "Rahul" }
  ]);
});
app.listen(3000);

Punkt wyjścia Fastify wygląda dość podobnie:

const fastify = require("fastify")({
  logger: true
});

fastify.get("/users", async (request, reply) => {
  return [
    { id: 1, name: "Neha" },
    { id: 2, name: "Rahul" }
  ];
});
fastify.listen({ port: 3000 });

Czy zauważyłeś coś?

Ani jeden z przykładów nie jest szczególnie przerażający.

Prawdziwa różnica między nimi staje się widoczna dopiero wtedy, gdy twoja aplikacja przekroczy ten etap prostego przykładu.

Express vs Fastify: Ogólny obraz

Zobaczmy, dlaczego różnice między tymi dwoma frameworkami są istotne w praktyce.

1. Wydajność: Fastify ma przewagę

To prawdopodobnie najważniejszy powód, dla którego Fastify ciągle pojawia się w takich rozmowach.

Jakość działania i minimalne obciążenie były od samego początku kluczowymi celami projektowania Fastify.

Jego wewnętrzne mechanizmy w dużej mierze opierają się na schematach do walidacji przychodzących danych oraz serializacji wychodzących odpowiedzi, co może znacząco zwiększyć przepustowość w przypadku obciążeń opartych na API. Własna dokumentacja Fastify zaleca używanie JSON Schema specjalnie do walidacji tras oraz serializacji odpowiedzi.

Mimo to istnieje tu ważna uwaga.

Nie należy na podstawie jednego wyniku testu wydawać pochopnych wniosków, że:

Fastify automatycznie oznacza aplikację 3 razy szybszą.

Większość testów wydajności frameworków mierzy obciążenie samego frameworku, w ściśle kontrolowanych warunkach.

Sami utrzymywacze Fastify przyznają, że opublikowany przez nich test wydajności to syntetyczny test w stylu „hello world”, i wyraźnie zalecają przeprowadzenie własnych testów wydajności dla rzeczywistej aplikacji, jeśli szybkość jest dla Ciebie kluczowa.

Rozważmy przepływ żądania, który wygląda następująco:

Request
   ↓
Authentication
   ↓
Database query
   ↓
Redis
   ↓
External API
   ↓
Business logic
   ↓
Response

Jeśli sama wywołanie bazy danych zajmuje 80 milisekund, zmniejszenie niewielkiego obciążenia frameworkiem nie przyniesie znaczącej poprawy szybkości tego punktu końcowego.

Zatem prawdziwe pytanie, które powinieneś sobie zadać, brzmi:

Czy moja aplikacja rzeczywiście jest ograniczana przez obciążenie CPU lub frameworkiem?

Innymi słowy: czy to sam framework spowalnia przetwarzanie żądań? Jeśli odpowiedź brzmi tak, przejście na Fastify ma znacznie silniejsze uzasadnienie.

Jeśli odpowiedź brzmi nie, to ogólne testy wydajności frameworków prawdopodobnie nie powinny być decydującym czynnikiem.

2. Walidacja: Tu Fastify staje się interesujący

Załóżmy, że nasza API jest zaprojektowana tak, aby przyjmować dane w takim kształcie:

{
  "name": "Neha",
  "age": 25
}

Oczywiście chcielibyśmy odrzucić nieprawidłową wersję tych samych danych, na przykład:

{
  "name": 123,
  "age": "hello"
}

W świecie Express zespoły zazwyczaj korzystają z dodatkowych bibliotek do obsługi takiej walidacji żądań. Fastify stosuje inny podejście: walidacja oparta na schematach jest wbudowana bezpośrednio w sam framework.

Oto jak to wygląda w praktyce:

const schema = {
  body: {
    type: "object",
    required: ["name", "age"],
    properties: {
      name: { type: "string" },
      age: { type: "integer" }
    }
  }
};

fastify.post("/users", { schema }, async (request, reply) => {
  return { message: "User created" };
});

Fastify umożliwia definiowanie definicji JSON Schema dla różnych elementów cyklu żądania i odpowiedzi, w tym:

• ciała żądania
• parametrów zapytania
• parametrów trasy
• headerów
• serializacji odpowiedzi

W głębi Fastify polega na Ajv do obsługi tej warstwy walidacji, a te same definicje schematów mogą być również wykorzystane do przyspieszenia serializacji odpowiedzi.

Ajv, skrót od „Another JSON Schema Validator”, to szybka biblioteka zgodna ze standardami do walidacji obiektów danych JavaScript według definicji JSON Schema, która działa zarówno w Node.js, jak i w przeglądarce.

To podejście oparte na schematach staje się szczególnie cenne, gdy interfejs API rozszerza się o dużą ilość ustrukturyzowanych danych wejściowych i wyjściowych.

3. Express ma coś, czego Fastify nie może łatwo zastąpić: swój ekosystem

Express istnieje od 2010 roku, co oznacza, że wokół niego powstała ogromna ilość wiedzy, narzędzi oraz doświadczeń społeczności.

• Potrzebna autoryzacja? Istnieje na to pakiet.
• Potrzebne logowanie? Istnieje na to pakiet.

Potrzebna obsługa CORS? Istnieje do tego pakiet.

Potrzebna walidacja? Istnieje do tego pakiet.

Załapany na jakimś niezrozumiałym błędzie? Prawdopodobnie ktoś inny już na niego natrafił i udokumentował rozwiązanie.

Taka głębia ekosystemu ma większe znaczenie, niż mogłoby się wydawać na pierwszy rzut oka.

Wyobraź sobie, że dołączasz do firmy, której backend działa w produkcji od sześciu lat. Nie możesz sam wybrać frameworka od zera – musisz przyjąć to, co już tam jest, co może wyglądać mniej więcej tak:

Express
 ├── 200+ routes
 ├── authentication middleware
 ├── custom middleware
 ├── logging
 ├── validation
 ├── monitoring
 └── lots of business logic

Czy naprawdę ma sens przepisywanie całego tego kodu tylko dlatego, że Fastify działa szybciej według testów? Prawdopodobnie nie.

Migracja istniejącej bazy kodu zawsze wiąże się z kosztami, a każda rzeczywista decyzja inżynieryjna wymaga porównania tych kosztów z oczekiwanymi korzyściami.

4. Middleware vs Pluginy

Istnieje również głębsza różnica architektoniczna pomiędzy tymi dwoma frameworkami.

Express jest zbudowany wokół koncepcji middleware. Typowa konfiguracja może wyglądać następująco:

app.use(authMiddleware);
app.use(loggingMiddleware);
app.use(express.json());

Każde przychodzące żądanie przechodzi kolejno przez te funkcje middleware.

Z drugiej strony Fastify wykorzystuje architekturę opartą na pluginach, zbudowaną wokół hooków i mechanizmów inkapsulacji. Koncepcyjnie przepływ wygląda mniej więcej w ten sposób:

Request
   ↓
Fastify
   ↓
Hooks
   ↓
Plugins
   ↓
Route
   ↓
Response

Dla aplikacji zaprojektowanych od początku w oparciu o model Fastify, taka struktura ułatwia organizację i zrozumienie większych baz kodu.

Mimo to istnieje kompromis – jeśli przez lata budowaliście modele mentalne wokół middleware w stylu Express, adaptacja do systemu pluginów i hooków Fastify może na początku wydawać się nieznana.

5. Obsługa błędów

W Express 4 obsługa błędów pochodzących z asynchronicznych obsług tras wymagała zazwyczaj ręcznego przekierowania ich dalej. Typowy wzorzec wyglądał w ten sposób:

app.get("/user/:id", async (req, res, next) => {
  try {
    const user = await getUserById(req.params.id);
    res.json(user);
  } catch (error) {
    next(error);
  }
});

Express 5 znacznie to upraszcza. Teraz odrzucenia obietnic (promise rejections) wywołane przez obsługę tras lub middleware są automatycznie przekazywane do mechanizmu obsługi błędów, dzięki czemu można napisać znacznie prostszy kod:

app.get("/user/:id", async (req, res) => {
  const user = await getUserById(req.params.id);
  res.json(user);
});

Jeśli getUserById() wywoła błąd lub zostanie odrzucone, Express 5 automatycznie to przechwyci i skieruje do obsługi błędów, bez konieczności używania wyraźnego try/catch lub wywołania next(err). Samo w sobie może to wydawać się drobną ułatwieniem składniowym. Jednak w kodzie zawierającym setki tras taka drobna poprawka przyczynia się do znacznie uporządkowanego i mniej podatnego na błędy kodu.

Express 5: Co tak naprawdę się zmieniło?

Express 5 trafił na rynek w październiku 2024 roku, więc wchodząc w rok 2026 nie jest już nową wersją. Mimo to duża liczba aplikacji produkcyjnych działa na Express 4, co oznacza, że zrozumienie zmian pomiędzy wersjami ma ogromne znaczenie dla każdego, kto planuje aktualizację.

I tak, istnieją zmiany mogące powodować problemy, których należy być świadomym.

1. Zmienione opcjonalne parametry ścieżek

W Express 4 można było napisać ścieżkę w ten sposób:

app.get("/:file.:ext?", handler);

Express 5 zastępuje ten wzorzec tym:

app.get("/:file{.:ext}", handler);

Stara notacja ? służąca do oznaczenia parametru jako opcjonalnego już nie działa.

Dlaczego ta zmiana?

Nowa składnia pozwala od razu zobaczyć, która część ścieżki jest opcjonalna.

Na papierze to subtelna zmiana, ale może potajemnie uszkodzić dziesiątki ścieżek w dużej, już istniejącej aplikacji.

2. Zmienione ścieżki z gwiazdkami

Wcześniej ścieżka ogólna mogła wyglądać w ten sposób:

app.get("/*", handler);

Express 5 wymaga, aby znaki zastępcze miały nazwy:

app.get("/*splat", handler);

Jeśli potrzebujesz, aby ten znak zastępczy pasował również do ścieżki korzeniowej /, otocz go w ten sposób:

app.get("/{*splat}", handler);

To kolejna niewielka zmiana składni, która może potajemnie uszkodzić istniejącą logikę routingu podczas aktualizacji.

3. Zmienione wzory ścieżek oparte na wyrażeniach regularnych

Express 5 przestaje obsługiwać kilka starych wzorów opartych na ciągach znaków, które wykorzystywały elementy w stylu regex.

Np. zamiast bezpośrednio umieszczać alternatywne segmenty w jednym ciągu ścieżki, teraz zwykle przekazuje się tablicę ścieżek:

app.get(
  ["/discussion/:slug", "/page/:slug"],
  handler
);

Celem tej zmiany jest zapewnienie, że dopasowywanie ścieżek będzie jawne i przewidywalne, zamiast polegać na skrótach w stylu regex.

4. req.body może teraz mieć wartość undefined

To subtelna kwestia, którą łatwo przeoczyć.

W Express 4 powszechnie przyjmowano, że:

req.body

automatycznie przyjmie wartość pustego obiektu jeszcze przed jakąkolwiek obróbką.

W Express 5, jeśli żaden element nie zostanie przetworzony w ciele żądania, req.body może po prostu być undefined.

To oznacza, że taka obrona typu „defensywna” staje się istotna w zależności od trasy:

if (!req.body) {
  return res.status(400).send("Request body required");
}

Chodzi o niewielką zmianę w zachowaniu, ale dokładnie o takie drobne szczegóły, które po aktualizacji mogą spowodować trudne do wykrycia błędy.

5. Zmiana w funkcji express.urlencoded()

Domyślna wartość opcji extended to teraz false.

Zamiast polegać na domyślnym ustawieniu:

app.use(express.urlencoded());

lepiej ustawić ją wyraźnie, jeśli twoja aplikacja polega na starszym zachowaniu:

app.use(
  express.urlencoded({
    extended: true
  })
);

Kolejny detal, który warto dokładnie przeanalizować podczas migracji istniejącej bazy kodu.

6. Zmiany w parserze ciała wiadomości

Express 5 również uporządkował sposób działania parsera ciała wiadomości wewnątrz aplikacji.

Teraz można napisać:

app.use(express.json());
app.use(
  express.urlencoded({
    extended: false
  })
);

Zamiast łączyć oddzielne pakiety middleware body-parser, jak to było wcześniej.

Ponadto Express 5 dodaje obsługę ciał żądań skompresowanych metodą Brotli oraz umożliwia konfigurację maksymalnej głębokości kodowania URL dla treści żądań.

7. Usunięto niektóre stare API odpowiedzi

Załóżmy starszą aplikację Express zawierającą coś w rodzaju:

res.send({
  message: "Success"
}, 200);

W Express 5 oczekiwany format jest następujący:

res
  .status(200)
  .send({
    message: "Success"
  });

Podobnie stary skrót:

res.redirect("back");

Został całkowicie usunięty.

Oficjalny przewodnik migracyjny zaleca ręczne sprawdzanie nagłówka referrer oraz użycie domyślnej ścieżki, gdy jest on brakujący.

Żadna z tych pojedynczych zmian nie jest szczególnie trudna do wprowadzenia.

Ale wyobraź sobie bazę kodu z przeszłości zawierającą tysiące wywołań napisanych w starym stylu.

W takim skali aktualizacja przestaje być prostym podniesieniem wersji zależności i staje się samodzielnym, poważnym zadaniem inżynieryjnym.

Zatem, Express czy Fastify: który wygrywa?

W tym momencie masz już wystarczająco dużo informacji, aby podjąć prawdziwą decyzję.

Nie opierałbym jej wyłącznie na:

">Który działa szybciej w testach wydajnościowych?"

Zamiast tego zacznij od przyjrzenia się samej aplikacji.

Powody, by pozostać przy Express:

• Tylko zaczynasz pracę nad rozwojem backendu w Node.js.
• Twoja zespół jest już biegle obeznany z Express.

Zarządzasz istniejącą bazą kodu Express lub ją rozszerzasz.

Twój projekt w dużej mierze opiera się na middleware w stylu Express.

Chcesz mieć dostęp do jak najszerszego ekosystemu pakietów.

Czysta wydajność nie jest głównym ograniczeniem, z którym się borykasz.

wolisz coś prostego i elastycznego zamiast rozwiązania narzucającego określone standardy.

Powody, by rozważyć Fastify:

• Rozpoczynasz od zera nową usługę skupioną na API.
• Przepustowość i minimalizacja obciążenia frameworkiem są rzeczywiście istotne.
• Chcesz, aby walidacja była realizowana bezpośrednio za pomocą schematów.
• Chcesz również, aby serializacja była obsługiwana poprzez schematy.
• Budujesz mikrosługi.
• Lubisz pracować z architekturą opartą na pluginach.
• Jest ci obojętne przyjęcie nieco młodszego ekosystemu.

Nie ma nic złego w wyborze Express nawet dla systemu na dużą skalę.

To, że jest to „duże aplikacja”, nie oznacza automatycznie, że Fastify będzie lepszym wyborem.

To, co otacza framework – twoja ogólna architektura – zazwyczaj ma znacznie większe znaczenie niż sam wybór frameworka.

Podstawowy sposób rozważenia tej kwestii

Oto przybliżony tok myślenia przy podejmowaniu decyzji:

Start
                   │
                   ▼
          Is this an existing app?
              /           \
            Yes            No
             │              │
             ▼              ▼
       Already using     Need very high
        Express?         throughput?
         /    \           /       \
       Yes     No       Yes        No
        │       │        │          │
        ▼       ▼        ▼          ▼
     Keep    Evaluate  Fastify    Evaluate
    Express  migration           both

Zanim podjęiesz ostateczną decyzję, warto zadać jeszcze jedno pytanie:

Jaki problem tak naprawdę próbuję rozwiązać?

Jeśli twoja obecna aplikacja z Express działa wolno, powstrzymaj się od natychmiastowego obwiniania frameworka.

Najpierw sprawdź jej wydajność.

Prawdziwym winowajcą może być:

Slow API
   ↓
Database query
   ↓
Missing index

lub:

Slow API
   ↓
External API
   ↓
3-second response time

lub:

Slow API
   ↓
Expensive business logic
   ↓
CPU bottleneck

Zmiana frameworka sama w sobie nie rozwiąże żadnych z tych podstawowych problemów.

Mój stosunek do tego tematu

Gdybyś dziś rozpoczynał nowy, mały projekt w Node.js, odrzucenie Expressa tylko dlatego, że Fastify osiąga lepsze wyniki w testach wydajnościowych, nie miałoby większego sensu. Express oferuje ogromny ekosystem, prosty model myślowy oraz lata zgromadzonej wokół niego wiedzy.

Mimo to Fastify również nie powinien być ignorowany. W przypadku nowej usługi, gdzie rzeczywiście mają znaczenie przepustowość, walidacja schematów, serializacja oraz minimalne obciążenie frameworkiem, Fastify zasługuje na poważną uwagę.

A jeśli odziedziczyłeś istniejące aplikacje oparte na Express 4? Przepisywanie ich wyłącznie dlatego, że Fastify jest szybszy, byłoby błędnym posunięciem.

Lepszym podejściem jest najpierw zrozumienie aplikacji, określenie miejsc, gdzie znajdują się rzeczywiste wąskie gardła, sprawdzenie kompatybilności z Express 5, przeprowadzenie testów migracyjnych, a dopiero potem podjęcie decyzji, czy zmiana frameworka przynosi wystarczającą wartość, by usprawiedliwić włożony wysiłek.

To jest chyba główna nauka z tego tekstu.

Framework o najlepszych wynikach w testach nie jest automatycznie odpowiednim rozwiązaniem dla twojej sytuacji.

Odpowiedni framework to ten, który rozwiązuje twój rzeczywisty problem, dodając przy tym jak najmniej niepotrzebnej złożoności.

Literatura pokrewna

• Node.js, Deno i Bun w porównaniu: testy wydajności, kompromisy i strategia migracji — Wyjaśnia rzeczywiste różnice architektoniczne między Node.js, Deno i Bun, co ujawniają testy z 2025 roku oraz jak zdecydować, czy i kiedy przeprowadzić migrację.
• Dzielenie jednego schematu Zod między frontendem React a backendem Node — Dowiedz się, jak jeden schemat Zod może weryfikować formularze React, odpowiedzi API, treści żądań Express oraz zmienne środowiskowe, jednocześnie generując odpowiadające im typy TypeScript.