Show HN: Rikta – A modular, TypeScript-first back end framework for Node.js
2 points
17 hours ago
| 1 comment
| github.com
| HN
Hi HN,

I’ve been working on Rikta, a backend framework for Node.js designed to make building scalable TypeScript applications more intuitive and modular.

After working with various Node frameworks, I felt there was a need for something that strictly enforces modularity and provides powerful out-of-the-box integrations without the "magic" that often makes debugging difficult.

What is Rikta? Rikta is a collection of packages designed to work together seamlessly. It’s built around a core that handles the application lifecycle and dependency injection, allowing you to plug in exactly what you need.

Key Features:

Zero-Config Autowiring No imports: [], exports: [], or providers: [] arrays. Just decorate your class, and it works.

Fastify Powered: Built on top of Fastify for maximum performance and low overhead. Rikta is 32% faster than NestJS on average.

Built-in TypeScript Support: Developed in TS for TS. You get full type safety across your entire backend stack.

First-class Integrations: Native support for TypeORM (database) and Swagger (automatic API documentation) via @riktajs/typeorm and @riktajs/swagger.

Developer Experience: A dedicated CLI (@riktajs/cli) to scaffold components and manage the project structure efficiently.

Lightweight Core: The core remains lean; you only add the features your specific application requires.

Why I'm building this: The goal of Rikta is to bridge the gap between "unstructured" Express apps and "overly complex" enterprise frameworks. I wanted a developer experience that feels fast but results in a codebase that a team can maintain for years.

Looking for Feedback & Collaborators: The project is currently in its early stages, and I’m looking for the HN community to help shape its direction. I’d love to hear your thoughts on:

The modularity pattern and Dependency Injection implementation.

The integration of Swagger/OpenAPI as a default.

What's missing in your current Node.js backend workflow that Rikta could solve?

Documentation is available at rikta.dev. I'm looking forward to your critiques and suggestions!

bryanrasmussen
11 hours ago
[-]
Obviously any observation I make is limited by my experience, but my experience of the last few years is that hardly anyone uses 'this' anymore in JavaScript because everyone uses arrow function, generally mandated by leadership. This observation is of course just limited to the places I've worked.

So the @Get('/') index() { return { message: this.greetingService.getGreeting() }; } example was weird for me to see, although not unwelcome.

I am however not that great at Typescript, which again my experience of work is that most of the developers I encounter aren't, and just use it as a lightweight structuring tool for JavaScript.

The @ decorator is thus always hard for me to reason about what is actually going on.

On the other hand I might be using this in the new year [despite my relative incompetence in Typescript], if I decide to build my next project on Node (I am considering Elixir to use Phoenix, hence having to say "might"), all of which is a long-winded way of saying looks pretty interesting and nice work.

reply
riktar
6 hours ago
[-]
Thanks for the feedback, Bryan! I really appreciate the honesty, and you’ve touched on a very real shift in the JS ecosystem.

Regarding the this and class-based approach: you’re absolutely right that the industry has leaned heavily towards functional patterns and arrow functions recently. The choice to use classes in Rikta is specifically to support Dependency Injection (DI).

In modular backend systems, DI makes it much easier to manage services (like the GreetingService in the example) and, more importantly, makes unit testing significantly simpler because you can easily swap real services for mocks.

As for the decorators (@): I completely understand why they can feel like "magic" or be hard to reason about. In Rikta, we use them to declaratively attach metadata to your code (e.g., "this method should handle GET requests"). It keeps the boilerplate out of your logic, but I realize it requires a bit of a mental shift if you're used to a more literal, functional style.

Don't worry about the "TypeScript competence" part! One of my goals with Rikta is actually to provide enough structure so that you don't have to be a TS wizard to build something solid. The framework handles the "heavy lifting" of the types, leaving you to focus on your business logic.

Elixir and Phoenix are fantastic choices (concurrency there is hard to beat!), but if you do decide to stick with Node for your next project, I’d love to have you try Rikta. Feel free to reach out if you hit any walls—I’m always looking to make the "getting started" experience smoother for everyone, regardless of their TS experience level.

Thanks again for the kind words!

reply
bryanrasmussen
11 hours ago
[-]
when I say "not unwelcome", I generally have not been overly traumatized by 'this' usage as some people have, its tricky nature being somehow enjoyable to my mind.
reply