Nidus: Rust framework, který to dělá jinak

Přiznám se, že Rust backend frameworky mi vždycky připomínaly dvě krajnosti. Buď píšete všechno od nuly, nebo máte framework tak magický, že vlastně nevíte, co se pod kapotou děje. Nidus se vydává třetí cestou – a musím říct, že docela zajímavou.

Explicitnost na prvním místě

Filozofie Nidusu je vlastně překvapivě prostá. Všechno, co vaše aplikace dělá, by mělo být vidět přímo ve zdrojovém kódu. Žádné skryté konfiguráky, žádné runtime dekorátory, které se těžce sledují.

Nidus tomu říká module graph – prostě graf vašich modulů, kde vidíte importy, poskytovatele, controllery i exporty. Když něco nefunguje, podíváte se do kódu. Když potřebujete pochopit, jak se data pohybují službou, čtete kód, ne logy, které se snaží zpětně rekonstruovat, co framework vlastně udělal při startu.

Typová injekce závislostí, která dává smysl

Pokud jste někdy pracovali s DI kontejnery v jiných jazycích, víte, jak rychle se to změní ve string-based klíče a reflexi. Nidus to řeší jinak – používá přímo Rustí typový systém.

Závislosti registrujete podle typu a používáte vzory, které jsou v Rustu přirozené: singletony pro sdílený stav, request-scoped pro data per-request, lazy pro odloženou inicializaci, optional pro graceful degradaci, factory pro komplexní konstrukci. A ta nejlepší část? Všechno je typové, takže compiler chytne chyby dřív než uživatelé.

HTTP vrstva, která jde hezky skládat

Nidus staví na Axum a Tower – to jsou solidní volby v Rust ekosystému. Ale obaluje je vrstvou, kde je kompozice explicitní. Vaše routy, middleware, guards i validační pipeliny jsou definované v kódu, kde vidíte celý obrázek.

Pro validaci používá Garde, takže máte stabilní chybové odpovědi, na které se dá spolehnout. OpenAPI generace vychází přímo z definic rout – ne z oddělené dokumentace, která se nakonec stejně rozejde s realitou.

Jak je to s výkonem?

Tady to začíná být zajímavé. Nidus tým porovnával svůj framework s FastAPI, Spring Boot a Express. Testovali na homelab Kubernetes setupu s identickými PostgreSQL endpointy.

Výsledky? Nidus dosáhl nejrychlejší ping latence – 423.72 mikrosekund. Nula neúspěšných požadavků. Nejlepší propustnost pro write-heavy scénáře – 423.94 requests per second.

Ale co mi přijde nejdůležitější: tým dělá skromné a ohraničené claims. Říkají přesně, jak testovali, kde testovali a co měřili. Žádné nafouknuté marketingové čísla, jen důkazy z jejich homelab běhů.

Úzká fasáda aneb držte to čisté

Tohle je filosoficky zajímavý přístup. Nidus nepřitahuje vendory výchozí. Chcete SQLx podporu? Existuje samostatný adapter crate. Potřebujete cachování? Další adapter crate. Jádro frameworku zůstává úzké a přidáváte jen to, co skutečně potřebujete.

Proč to vadí? Zaprvé – dependency tree zůstává čistá. Zadruhé – máte přímý přístup ke klientům bez abstrakčních vrstev, které jedí výkon. Zatřetí – upgrade nebo výměna dependency neznamená boj s framework-level změnami.

Začínáme rychle

Framework se chlubí, že senior Rust engineer jede z nuly na běžící aplikaci pod minutu. Příklady v repository tomu odpovídají – od hello-world po produkční tvary s adapters a externími šablonami.

Release přístup je podobně praktický. Lokální dry-runy před publish. CLI inspector, TestApp a volitelný dashboard vám umožňují ověřit strukturu rout, module graph a OpenAPI výstup přímo za běhu.

Je Nidus pro vás?

Pokud stavíte backend služby v Rustu a preferujete explicitnost před konvencemi, typovou bezpečnost před runtime objevováním, a úzkou stopu závislostí před everything-and-the-kitchen-sink výchozími nastaveními, Nidus si zaslouží vaši pozornost.

Nidus se nesnaží být frameworkem, který za vás vyřeší všechno. Snaží se být frameworkem, který vám jde z cesty, ale přitom poskytuje strukturální disciplínu, která udržuje velké kódové báze udržovatelné.

Pro týmy, které si přály, aby Rust web development měl něco víc explicitního bez ztráty síly – tohle možná je to, co čekáte.

Mrkněte na příklady, spusťte CLI inspector a rozhodněte se sami, jestli vám explicitnost-na-výchozí přístup sedí.