# Nestia: typed NestJS decorators, an SDK generator, and Swagger for LLM function calling > Nestia is a set of MIT-licensed TypeScript helper libraries for NestJS that replace class-validator and class-transformer with compile-time generated validators, and generate client SDKs from the same types. It is for teams already committed to NestJS who want type safety end to end. **samchon/nestia** — NestJS Helper + AI Chatbot Development - Repository: https://github.com/samchon/nestia - Website: https://nestia.io/ - Stars: 2,178 · Forks: 126 - Language: TypeScript - License: MIT - Published: 2026-09-10 · Updated: 2026-09-10 · Language: en - Canonical page: https://hysenlabs.com/projects/samchon-nestia ## The problem Nestia targets: the same DTO written three times In a plain NestJS application a request body is usually declared three times over. A TypeScript interface describes it for the compiler, a class with class-validator decorators describes it for runtime validation, and a Swagger decorator block describes it for the generated API document. Nothing keeps the three in sync, and the client is a fourth copy written by hand. Nestia's answer is to make the pure TypeScript type the single source. The README states the pitch directly: "Only one line required, with pure TypeScript type". A controller method annotated with @TypedBody takes a plain interface, and Nestia's compiler plugin turns that interface into a runtime validator and a JSON serializer at build time. The audience is narrow and specific. This is for teams that have already chosen NestJS and TypeScript, and that feel the cost of the DTO triplication. It is not a general purpose validation library and it does not try to be framework neutral. ## How the mechanism works: a compiler plugin plus generated artifacts Nestia is not a runtime reflection layer. The repository is a pnpm workspace whose root package.json is named @nestia/station, with the actual libraries under packages/ and integration tests under tests/test-*. The build script runs pnpm --filter=./packages/* -r build, and the test script sets TTSC_GO_BINARY=go and TTSC_CACHE_DIR=node_modules/.cache/ttsc before building. That points at a Go-based transformer invoked during TypeScript compilation, with a cache directory the build reuses. Compilation is where the work happens. The transformer reads the TypeScript types attached to the Nestia decorators and emits validation and serialization code for them, which is why the README can claim a runtime validator that is "20,000x faster" than class-validator and JSON serialization that is "200x faster" than class-transformer: there is no decorator metadata to read at request time, only generated functions. Treat those multipliers as the project's own claims. The repository does publish benchmark results under benchmark/results/, and that directory is the place to check the methodology rather than the README table. The second half is code generation outside the compiler. @nestia/sdk reads the compiled application and produces a Swagger document, a client SDK, mockup simulators and E2E test function stubs. The packages are split so you can take only the piece you need: @nestia/core for the decorators and WebSocket routes, @nestia/sdk for the generators, @nestia/e2e and @nestia/benchmark for test and benchmark programs built on those generated E2E functions, and @nestia/editor for a Swagger UI with an online TypeScript editor. The nestia package itself is described as "Just CLI (command line interface) tool". ## Installing Nestia and generating a first SDK The README points to https://nestia.io/docs/setup/ for setup rather than spelling the steps out inline, so there are no install commands or configuration snippets to quote here. Nestia ships to npm under the @nestia scope, and the workspace is managed with pnpm, as the root package.json and pnpm-workspace.yaml show. The README does name the decorators you configure once the packages are in place. @TypedBody is the one it highlights, and @TypedRoute, @TypedParam, @TypedQuery, @TypedFormData, @TypedHeaders and @TypedException cover the rest of the request surface. @WebSocketRoute handles WebSocket routes. The setup page at nestia.io/docs/setup/ is where the project documents how these are registered in your TypeScript build. The generation step is the nestia CLI, which the README describes as "Just CLI (command line interface) tool". Running it against the compiled application produces the Swagger document and the client SDK, and the SDK is a collection of typed fetch functions with DTO structures, which the README compares to tRPC. The generated SDK also carries a mockup simulator, described as similar to msw but fully automated, which lets a frontend run against an embedded backend simulator before the real server exists. The exact CLI flags are on the SDK builder page under nestia.io/docs/sdk/. ## The build step is the real cost, and the benchmarks are the project's own The trade-off is structural, not incidental. Nestia moves work from request time to build time, and that means the build now depends on a Go binary. The root test script exports TTSC_GO_BINARY=go, so a Go toolchain has to be present wherever the transformer runs. Any environment that compiles your NestJS server, including CI, needs that toolchain and a writable TTSC_CACHE_DIR. Teams that expect a pure npm install and a plain tsc invocation will find an extra moving part. Generated artifacts create a second cost. The SDK, the Swagger document and the E2E test functions are outputs, and the README does not document a rollback or migration path for a project that wants to stop using Nestia later. Removing the decorators means replacing them with class-validator classes and hand-written Swagger decorators, which is the triplication Nestia was adopted to avoid. There is no documented escape hatch that keeps the generated SDK working after the decorators are gone. The performance claims deserve the same caution. "30x", "20,000x" and "200x" are the project's numbers, and they compare generated code against reflection-based libraries, so the direction of the result is plausible even if the magnitude depends on payload shape. The repository keeps raw results in benchmark/results/, which is the honest place to look. A small JSON payload with a handful of fields will not see a 20,000x difference in wall clock time, because validation is rarely the bottleneck in a request that touches a database. Nestia is also the wrong tool outside NestJS. The decorators are NestJS decorators, the SDK generator reads a NestJS application, and the E2E tooling is built around NestJS controllers. A Fastify or Express codebase gets nothing from @nestia/core. ## Nestia compared with typia and with plain class-validator The closest relative is typia, which is also by the same author and also uses a compiler transformer to turn TypeScript types into validation and serialization code. The difference is scope. typia is a general purpose library: you call typia.assert(input) anywhere in any TypeScript program, and there is no framework involved. Nestia is the NestJS integration layer built on that idea, adding the decorators, the Swagger generator, the SDK generator and the E2E test scaffolding. If you only need fast validation in a non-NestJS service, typia is the smaller dependency; if you want the generated client SDK, that is Nestia's territory and typia does not provide it. The other comparison is staying with class-validator and class-transformer. That route keeps a standard NestJS ValidationPipe, needs no Go toolchain, and has a large body of tutorials behind it. What it does not give you is a single declaration: you still write the validator class, the Swagger decorators and the client types, and validation still runs through reflection at request time. Nestia's advantage is not only speed, it is that the interface in the controller is the interface in the generated SDK. The cost is a build pipeline that differs from the default NestJS one. ## Licence, maintenance and upgrade cost Nestia is MIT licensed, and the LICENSE file sits at the repository root alongside the workspace package.json, which also declares "license": "MIT". MIT is permissive: it allows commercial use and modification, and it requires the copyright notice and licence text to be preserved in distributions. That is a statement about the licence text, not legal advice for a specific product. On maintenance, the last push to the default branch was on 2026-09-02, and the most recent releases listed are v13.0.2 on 2026-08-25, v13.0.1 on 2026-08-22 and v13.0.0 on 2026-08-21. The repository is not archived. The jump from v12 to v13 is the cost signal that matters here: the root package.json is already at version 13.0.3 while the published packages are at 13.0.2, and a major version bump in a package that generates code means the generated SDK and the server decorators have to move together. Budget for reading the release notes before each major upgrade rather than pinning and forgetting. The monorepo structure adds a smaller ongoing cost. @nestia/core, @nestia/sdk, @nestia/e2e, @nestia/benchmark and @nestia/editor are separate packages, so the versions you install can drift apart. Keeping them on the same minor line avoids a class of mismatch that the README does not warn about. ## Who should adopt Nestia, and what to check first Adopt it if you are building a NestJS backend and a TypeScript client from the same repository. The generated SDK removes the hand-written API client entirely, and the mockup simulator means the frontend can be built before the backend endpoints are finished. The E2E test function generator is a genuine multiplier for a team that already wants end-to-end coverage but keeps postponing it. Do not adopt it if your server is not NestJS, if your CI cannot install a Go toolchain, or if your validation lives in shared classes used by non-NestJS code. Do not adopt it for the benchmark numbers alone. The speedup is real in the sense that generated code avoids reflection, but it is not the reason to restructure a build. Before committing, check three things. First, confirm the @nestia/core release you install declares a peer range that covers your NestJS version, since the decorators are tied to NestJS internals. Second, open benchmark/results/ and read how the comparison was run rather than accepting the README multipliers. Third, run the nestia CLI once against a throwaway controller and inspect the generated SDK, because the shape of that output is what your frontend team will live with. ## Conclusion Adopt Nestia if your backend is already NestJS and you want one TypeScript type to drive validation, Swagger output and a typed client SDK, and you accept a code-generation step in your build. Do not adopt it if you need a framework-agnostic validator, if you cannot run a CLI generator in CI, or if you depend on class-validator decorators that Nestia's TypedBody does not replace. Verify first that your NestJS version matches the peer range of the @nestia/core release you install, and read the benchmark results directory rather than the README headline numbers. ## FAQ ### What is Nestia? Nestia is a set of helper libraries for NestJS, written in TypeScript and licensed under MIT. It provides typed decorators such as @TypedBody and @TypedRoute in @nestia/core, plus generators in @nestia/sdk for Swagger documents, client SDKs, mockup simulators and E2E test functions. ### What is the Nestia app? The README describes Nestia as a NestJS helper library and CLI published on npm under the @nestia scope, not as an end-user application. It lists the packages it ships, including @nestia/core, @nestia/sdk, @nestia/e2e, @nestia/benchmark and @nestia/editor. ### Is the Nestia app down? There is no hosted Nestia service described in the README, so there is nothing that can be down. Nestia is installed into your own project as npm packages and a CLI, and it runs in your build pipeline. ## Sources - [License: MIT](https://github.com/samchon/nestia/blob/master/LICENSE) - [Project website](https://nestia.io/) - [README](https://github.com/samchon/nestia/blob/master/README.md) - [Releases](https://github.com/samchon/nestia/releases) - [samchon/nestia on GitHub](https://github.com/samchon/nestia) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/samchon-nestia