Hono - szybka i lekka alternatywa dla Express.js

Hono to framework do budowy API i aplikacji serwerowych w JavaScripcie i TypeScripcie, który w wielu nowych projektach zastępuje Express.js. Jest szybką i lekką alternatywą dla Express.js: nie ma żadnych zewnętrznych zależności, a ten sam kod uruchamia się na serwerze Node.js, w funkcjach serverless i w sieciach brzegowych, takich jak Cloudflare Workers.

Framework Express.js działa od 2010 r. i przez ten czas stał się domyślną odpowiedzią na pytanie, w czym napisać backend w JavaScripcie. Nadal jest dobrym wyborem w wielu sytuacjach. Tyle że powstał w innych warunkach: dla jednego środowiska, jednego serwera i czasów, w których TypeScript jeszcze nie istniał.

Express.js po ponad piętnastu latach: co działa, a co uwiera

Siła Expressa to ekosystem. Do niemal każdego problemu - logowania użytkowników, obsługi plików, limitów zapytań - istnieje gotowa biblioteka, a programistę znającego Expressa łatwo znaleźć. Dokumentacja, poradniki i odpowiedzi na forach liczone są w setkach tysięcy. Problemy wynikają z wieku. Express jest ściśle związany ze środowiskiem Node.js, czyli programem, który uruchamia JavaScript na serwerze. Korzysta z jego wewnętrznych obiektów zapytania i odpowiedzi, więc bez dodatkowych warstw nie zadziała w nowszych środowiskach, które opierają się na standardach przeglądarkowych. Typy dla TypeScript są dostarczane osobno, przez społeczność, a nie przez twórców frameworka.

Rozwój przez lata szedł powoli. Wersja 5 ukazała się we wrześniu 2024 r., dziesięć lat po wersji 4. Według harmonogramu wsparcia Expressa gałąź 4.x jest od kwietnia 2025 r. w fazie utrzymania, a jej wsparcie może się zakończyć nie wcześniej niż 1 października 2026 r. Dla projektów na Expressie 4 to i tak moment decyzji: aktualizacja do piątki albo przejście na coś innego. Sama architektura Expressa jest prosta i dobrze znana. Zapytanie przechodzi przez łańcuch funkcji pośredniczących, które kolejno sprawdzają uprawnienia, parsują dane czy zapisują logi. Te same warstwy pośrednie, czyli middleware, są sercem Hono. Programista Expressa odnajdzie się w nim szybko, bo zmienia się głównie składnia.

Czym jest Hono i co odróżnia je od Expressa

Hono (po japońsku „płomień”) stworzył Yusuke Wada, a projekt jest rozwijany na licencji MIT. Sam lekki framework webowy Hono składa się z routera, obsługi middleware i zestawu pomocników, a resztę dokłada się w miarę potrzeb. Ciekawsze od listy funkcji jest to, czym różni się od Expressa.

Najważniejsza różnica jest niewidoczna dla użytkownika aplikacji. Hono zbudowano na standardach webowych, czyli tych samych obiektach zapytania i odpowiedzi, których używa przeglądarka. Każde środowisko, które je obsługuje, uruchomi Hono bez przeróbek. Według dokumentacji Hono lista obejmuje Cloudflare Workers, Fastly Compute, Deno, Bun, Vercel, Netlify, AWS Lambda i Node.js (przez oficjalny adapter).

Druga różnica to rozmiar. Najmniejszy wariant Hono waży poniżej 14 kB, Express z zależnościami - 572 kB. Hono nie pobiera żadnych zewnętrznych pakietów, a w zestawie ma to, co w Expressie trzeba doinstalować:

• uwierzytelnianie tokenami JWT i hasłem,
• obsługę CORS, czyli zasad dostępu z innych domen,
• kompresję, cache i nagłówki bezpieczeństwa,
• walidację danych wejściowych i strumieniowanie odpowiedzi.

Mniej pakietów to mniej aktualizacji bezpieczeństwa do śledzenia. Przy projektach pisanych w TypeScript liczy się też to, że Hono od początku powstawało w tym języku, więc typy są częścią frameworka, a nie dodatkiem.

Gdzie Hono jest szybsze, a gdzie różnica znika

Twórcy publikują benchmarki, w których Hono wyraźnie wygrywa. W środowisku Cloudflare Workers router Hono obsługuje ponad 400 tys. operacji na sekundę, prawie dwa razy więcej niż konkurencyjny itty-router. Na Deno Hono przetwarza ponad 136 tys. zapytań na sekundę, a popularny tam framework oak około 43 tys. (dane z zestawienia benchmarków Hono). Te liczby trzeba czytać z dystansem. Mierzą przede wszystkim szybkość routera, czyli mechanizmu, który dopasowuje adres zapytania do właściwej funkcji. W typowej aplikacji biznesowej odpowiedź trwa kilkadziesiąt milisekund, bo tyle zajmuje zapytanie do bazy danych albo do zewnętrznego systemu. Router odpowiada za ułamek tego czasu.

Na Node.js różnica względem Expressa jest mniejsza. Hono nie powstało z myślą o tym środowisku i działa w nim przez adapter, który tłumaczy obiekty Node.js na standardowe. Aplikacja nadal zyska na lżejszym kodzie, ale nie będzie kilkukrotnie szybsza tylko dlatego, że zmienił się framework.

Wyraźny zysk pojawia się w nowszych środowiskach. Bun jako środowisko uruchomieniowe obsługuje standardy webowe natywnie, a Hono korzysta z tego bez żadnych warstw pośrednich. Podobnie jest z Deno od twórcy Node.js. Jeszcze większe znaczenie niż sama szybkość ma jednak rozmiar aplikacji tam, gdzie płaci się za każde uruchomienie.

Hono jako alternatywa dla Express.js w serverless i na edge

Serverless to model, w którym kod nie działa na stale włączonym serwerze, tylko uruchamia się na żądanie, a firma płaci za faktyczne wywołania. Tak działa usługa AWS Lambda. Każde pierwsze uruchomienie po przerwie, tzw. zimny start, wymaga wczytania całej aplikacji. Im jest mniejsza, tym krócej użytkownik czeka. Edge computing idzie krok dalej. Kod działa na serwerach rozsianych po całym świecie, najbliżej użytkownika, jak w platformie Cloudflare. Takie środowiska mają ścisłe limity rozmiaru i pamięci, a Express bez dodatkowych warstw zgodności w nich nie wystartuje. Hono powstało właśnie z myślą o Cloudflare Workers i tam czuje się najlepiej. W praktyce Hono na edge sprawdza się przy zadaniach krótkich i częstych: przekierowaniach, sprawdzaniu tokenów, personalizacji odpowiedzi, pośredniczeniu między aplikacją a zewnętrznymi API. Mechanizm dobrze opisuje przykład funkcji brzegowych (Edge Functions), które skracają czas odpowiedzi bez przebudowy całego backendu.

Z Hono w produkcji korzystają m.in. cdnjs, baza danych Cloudflare D1 i dostawca usług logowania Clerk. To projekty obsługujące ogromny ruch, co dobrze świadczy o dojrzałości frameworka. W aplikacjach SaaS, gdzie API obsługuje klientów z wielu krajów, przeniesienie części logiki na edge potrafi wyraźnie skrócić czas odpowiedzi dla użytkowników z drugiego końca świata.

Jeden typ danych od serwera po przeglądarkę

Częsty błąd w projektach z osobnym frontendem i backendem jest banalny. Backend zmienia nazwę pola w odpowiedzi, frontend o tym nie wie, a użytkownik widzi pusty ekran. W Expressie przed takimi sytuacjami chronią dodatkowe narzędzia albo ręcznie utrzymywana dokumentacja. Hono ma do tego funkcję RPC. Serwer eksportuje opis swoich tras jako typy TypeScript, a klient `hc` wykorzystuje je w aplikacji frontendowej. Jeśli backend zmieni kształt danych, edytor programisty frontendu pokaże błąd od razu, zanim kod trafi na produkcję. Dane wejściowe sprawdza walidator, najczęściej oparty na bibliotece Zod, a osobny moduł generuje z tego samego kodu specyfikację OpenAPI.

Dla zespołów pracujących w podejściu API-first to wygodne połączenie: kontrakt API powstaje w kodzie i nie rozjeżdża się z dokumentacją.

Jest jedno zastrzeżenie. Dokumentacja RPC w Hono przyznaje, że przy bardzo dużej liczbie tras edytor zaczyna zwalniać, więc duże API trzeba dzielić na moduły od samego początku.

Hono w aplikacji Next.js

Boring Owl buduje strony i aplikacje w frameworku Next.js, więc to połączenie interesuje nas szczególnie. Next.js ma własne trasy API, ale przy kilkudziesięciu punktach końcowych szybko robi się w nich tłoczno: każda trasa to osobny plik, a wspólna logika (autoryzacja, walidacja, obsługa błędów) jest powielana. Hono można osadzić w Next.js jako jedną trasę, która przejmuje wszystkie adresy zaczynające się od `/api`. Całe API żyje wtedy w jednym, uporządkowanym miejscu, z middleware i walidacją zdefiniowanymi raz. Frontend w tym samym repozytorium korzysta z typów RPC bez dodatkowej konfiguracji.

Ta sama aplikacja Hono może później zostać wyjęta z Next.js i uruchomiona jako osobna usługa, na przykład na Cloudflare Workers, gdy ruch na API zacznie rosnąć niezależnie od ruchu na stronie. Kod się nie zmienia. Zmienia się tylko miejsce, w którym działa. Przy tworzeniu aplikacji webowych daje to swobodę, której Express w takim układzie nie zapewnia.

Kiedy zostajemy przy Expressie albo wybieramy coś większego

Hono nie jest odpowiedzią na wszystko. Duża, działająca aplikacja na Expressie, z dziesiątkami bibliotek middleware do logowania przez zewnętrznych dostawców, sesji i uploadu plików, raczej nie powinna zmieniać frameworka tylko dla szybkości. Middleware napisane dla Expressa nie zadziała w Hono bez przepisania, a zysk wydajności na Node.js będzie umiarkowany. Aktualizacja do Expressa 5, wspieranego co najmniej do kwietnia 2027 r., jest wtedy tańszą i bezpieczniejszą drogą.

Przy rozbudowanych systemach biznesowych z wieloma modułami, zespołami i regułami domenowymi częściej sięgamy po framework NestJS. Narzuca strukturę projektu, co przy kilkunastu programistach jest zaletą, a nie ograniczeniem. Hono daje swobodę, ale odpowiedzialność za architekturę spada w całości na zespół.

Jeśli projekt ma zostać na klasycznym serwerze Node.js, a liczy się wydajność, warto też rozważyć framework Fastify. Jest dojrzały, szybki na Node.js i ma własny ekosystem wtyczek. Hono wygrywa z nim tam, gdzie aplikacja ma działać w kilku środowiskach albo na edge.