Nidus – framework Rust, który stawia na eksplicytność

Przyznajmy to sobie: frameworki backendowe w Rust albo zmuszają cię do pisania wszystkiego od zera, albo robią tyle "magii" pod maską, że tracisz kontrolę nad tym, co się dzieje. Nidus idzie inną drogą. I szczerze mówiąc, ta droga może przypaść do gustu doświadczonym programistom Rust.

Czytelność kodu to podstawa

Filozofia Nidus jest prosta i przy tym uczciwa: struktura twojej aplikacji powinna być widoczna gołym okiem w kodzie źródłowym. Nie chowa się jej w wygenerowanych plikach konfiguracyjnych ani w runtime'owych dekoratorach. Framework nazywa to module graph – i nazwa idealnie oddaje to, czym to jest. Masz czytelną, inspectowalną strukturę pokazującą importy, providery, controllery i eksporty.

Co z tego wynika? Gdy coś się psuje, znajdujesz to błyskawicznie. Gdy chcesz prześledzić, jak zależność przepływa przez twój serwis, czytasz kod – nie próbujesz odcyfrowywać logów runtime'owych, żeby zrozumieć, co framework sobie nawymyślał przy starcie.

Wstrzykiwanie zależności, które ma sens

Jeśli korzystałeś z kontenerów DI w innych językach, wiesz pewnie, jak wygląda standardowe podejście: klucze oparte na stringach, refleksja albo "konwencja ponad konfigurację". Nidus robi to inaczej – wykorzystuje system typów Rusta.

Rejestrujesz zależności po typie, używając wzorców, które czują się naturalnie w Rust: singletony dla współdzielonego stanu, request-scoped dla danych per-request, lazy dla odroczonej inicjalizacji, optional dla eleganckiego radzenia sobie z brakami, factory dla złożonych konstrukcji. Najlepsze? Wszystko jest typowane. Czyli kompilator łapie błędy zanim zobaczą je użytkownicy.

Warstwa HTTP, która się ładnie składa

Nidus bazuje na Axum i Tower – solidnych wyborach w ekosystemie Rust – ale opakowuje je w warstwę, gdzie kompozycja jest eksplicytna. Twoje route'y, middleware, guards i pipy walidacyjne definiujesz w kodzie, gdzie widzisz cały obraz.

Za walidację odpowiada Garde, co daje stabilne odpowiedzi błędów, na których możesz polegać. Generowanie OpenAPI odbywa się na podstawie definicji route'ów – nie na podstawie osobnej dokumentacji, która zazwyczaj i tak rozjeżdża się z rzeczywistością.

Testy wydajności – bez czarowania

No i tutaj robi się ciekawie. Zespół Nidus przeprowadził benchmarki porównujące swój framework z FastAPI, Spring Boot i Express. Testy szły na homelabowym Kubernetesie, z identycznymi endpointami backed by PostgreSQL. Wyniki są warte uwagi:

Nidus osiągnął najniższy ping latency – 423.72 mikrosekundy, zero failed requests i najlepszy write-heavy throughput na poziomie 423.94 requests per second.

Ale doceniam to, co robią dalej – formułują ostrożne claimy. Dokładnie opisują, jak testowali, gdzie testowali i co mierzyli. Żadnych napompowanych liczb marketingowych, tylko fakty z ich homelabowych uruchomień.

Wąski facade, czyli brak zbędnych zależności

Jedno, co wyróżnia Nidus filozoficznie, to tak zwany narrow facade. Framework domyślnie nie ciągnie za sobą vendor dependencies. Potrzebujesz wsparcia dla SQLx? Jest osobny adapter crate. Chcesz cachowanie? Kolejny adapter crate. Rdzeń frameworka zostaje lean, a ty dobierasz tylko to, czego potrzebujesz.

To ma znaczenie z kilku powodów. Po pierwsze, drzewo zależności zostaje czyste. Po drugie, masz bezpośredni dostęp do klientów niższego poziomu – żadne warstwy abstrakcji nie zjadają ci wydajności. Po trzecie, upgrade czy podmiana jakiejś zależności nie wymaga walki z zmianami na poziomie frameworka.

Start zajmuje dosłownie chwilę

Framework chwali się, że senior Rust engineer może przejść od zera do działającego service'a w niecałą minutę. Katalog examples to potwierdza – znajdziesz tam przykłady od hello-world po production-shaped API z adapterami i zewnętrznymi templatami.

Podejście do release'ów też jest pragmatyczne. Lokalne dry-runy sprawdzają, czy wszystko działa, zanim coś wypuścisz. CLI inspector, TestApp i opcjonalny dashboard pozwalają zweryfikować strukturę route'ów, module graph i output OpenAPI w runtime.

Czy Nidus to dobry wybór dla twojego projektu?

Jeśli budujesz backend service'y w Rust i cenisz eksplicytność nad konwencją, type safety nad runtime'owym odkrywaniem zależności, i minimalne drzewo zależności nad "wszystko-w-pudełku" domyślnie – Nidus zasługuje na twoją uwagę.

Nidus nie próbuje być frameworkiem, który robi za ciebie wszystko. Próbuje być frameworkiem, który schodzi ci z drogi, ale jednocześnie zapewnia structural rigor, który utrzymuje duże codebase'y w ryzach. Dla zespołów, które marzyły o Rust web development bez magicznych rozwiązań, ale z pełną kontrolą – to może być to, na co czekały.

Rzuć okiem na przykłady, odpal CLI inspector i sam zdecyduj, czy podejście "eksplicytne domyślnie" pasuje do twojej filozofii programowania.