DEV Community: Riccardo Tartaglia

Why We Need a Standard Language for Agentic Workflows (And Why I Built One)

Riccardo Tartaglia — Fri, 13 Mar 2026 16:19:21 +0000

Everyone is building **multi-agent systems. Nobody agrees on how to describe them.

I've been building with LLMs for the past two years. I've used LangChain, CrewAI, AutoGen, and a dozen smaller AI agent frameworks. Every single time, the experience follows the same arc: excitement, followed by a slow descent into configuration hell, vendor lock-in, and code that nobody on my team can actually read without opening a Python debugger.

At some point, I started asking a different question. Not "which agent framework should I use?" but "why do we keep building frameworks at all?"

Think about it. When you want to query a database, you don't write a Java class that wraps a PostgreSQL driver that wraps a connection pool that wraps a query builder. You write SQL. A few lines, declarative, portable, readable by literally everyone on the team, from the junior dev to the DBA to the PM who just wants to understand what data we're pulling.

We never got that for agentic workflows. And I think it's the single biggest bottleneck holding multi-agent AI systems back from real adoption.

The Reproducibility Crisis in AI Agent Orchestration

There's a dirty secret in the AI agent space: most multi-agent workflows are not reproducible. Not across teams, not across providers, not even across time.

You build something in CrewAI. Your colleague prefers LangGraph. Your client uses AutoGen. Each framework has its own way of defining agents, its own execution model, its own opinions about how data flows between steps. The workflow itself, the actual logic of "this agent researches, that agent analyzes, a third one reviews," gets buried under layers of SDK boilerplate.

This means three things. First, you can't share workflows without also sharing your entire stack. Second, switching LLM providers (or even models) requires rewriting code, not just changing a config line. Third, non-developers are completely locked out. Your PM can't read a CrewAI pipeline. Your domain expert can't verify that the agent flow matches what they described in the meeting. The workflow becomes a black box owned by whoever wrote it.

I kept running into this wall. I'd sketch a multi-agent flow on a whiteboard, everyone would nod, and then translating that whiteboard sketch into running code would take days. The sketch was simple. The code was not. Something was fundamentally wrong with the abstraction layer.

What SQL Taught Us About Declarative Languages (And We Forgot)

SQL was invented in the 1970s. Before SQL, if you wanted to query data, you wrote procedural code. You iterated over records, applied filters manually, joined tables in loops. It worked, but it was slow to write, hard to read, and impossible to port between database systems.

SQL changed everything not because it was more powerful than procedural code. It was actually less powerful. You can't write a web server in SQL. That's the point. It was a constrained, declarative language that did one thing well: describe what data you want, not how to get it.

The consequences were enormous. Suddenly anyone could read a query. DBAs, analysts, product managers. Suddenly queries were portable across databases (mostly). Suddenly tools could optimize execution because the language described intent, not implementation.

I believe agentic workflows are at the exact same inflection point. We're in the "procedural code" era. Everyone is writing imperative, framework-specific agent code. What we need is the declarative orchestration layer. A language that describes what agents should do and how they coordinate, independent of any runtime, any provider, any programming language.

Introducing SLANG: A Declarative Language for Multi-Agent Orchestration

SLANG stands for Super Language for Agent Negotiation & Governance. It's a minimal, declarative meta-language for multi-agent workflows. And it fits on a napkin.

The entire language has three primitives. stake means "produce something and send it somewhere." await means "wait until someone sends you something." commit means "I'm done, here's my result." That's it. Everything else, conditionals, loops, variables, structured output, those are built on top of these three operations.

Here's what a real agent workflow looks like:

flow "research" {
  agent Researcher {
    tools: [web_search]
    stake gather(topic: "quantum computing") -> @Analyst
  }
  agent Analyst {
    await data <- @Researcher
    stake analyze(data) -> @out
    commit
  }
  converge when: all_committed
}

Read it out loud. The Researcher gathers information about quantum computing and sends it to the Analyst. The Analyst waits for that data, analyzes it, outputs the result, and commits. The flow ends when everyone has committed.

Your PM can read this. Your designer can read this. An LLM can read this. And more importantly, an LLM can execute this, with zero tooling, zero installation, zero configuration.

Zero-Setup Mode: Run Agent Workflows in Any LLM Chat

Here's the thing I'm most excited about, and the part that took the longest to get right.

The same .slang file works in two completely different ways. You can paste it into ChatGPT, Claude, or Gemini with a system prompt, and the LLM becomes your runtime. It reads the flow, simulates each agent, passes data between them, and produces real output. No install. No API key. No SDK. I call this zero-setup mode.

Or you can run it with the SLANG CLI or API, and you get a full production runtime. Parallel agent execution, real tool handlers, checkpoint and resume, structured output contracts, deadlock detection, and support for 300+ models through OpenRouter. Different agents in the same flow can even use different LLM providers.

The same file. Both ways. Start by prototyping in ChatGPT, move to production when you're ready. This isn't something you can do with a framework, because a framework is, by definition, tied to a specific runtime. A language isn't.

Why JSON and YAML Fail as Agent Workflow Standards

I know what some of you are thinking. "Why not just use JSON or YAML to describe workflows?" I tried that. Everyone tries that. It doesn't work, and the reason is subtle.

JSON and YAML are data formats, not languages. They don't have semantics. When you write {"action": "research", "send_to": "analyst"}, that blob means nothing without a runtime that interprets it. And every runtime interprets it differently. You haven't created a standard, you've created a configuration file for one specific tool.

A language has grammar. It has a parser that validates structure. It has defined execution semantics. It has error codes and static analysis. SLANG has all of these. You can parse a .slang file, build a dependency graph, detect deadlocks before running anything, and get real-time diagnostics in your editor through LSP support. Try doing that with a JSON config.

More importantly, a language is something LLMs can learn, generate, and reason about. SLANG's syntax was designed from day one to be LLM-native. Function names are semantic labels, not code references. stake gather(topic: "AI trends") tells the LLM what to do in natural language. The structure tells it how to coordinate. This means you can literally ask an LLM to "write me a SLANG flow that does X," and it produces working code. Text-to-SLANG works the same way text-to-SQL works.

Lessons From Building an Open Source Agent Language

I shipped the first version of SLANG about six months ago. Since then, I've iterated through seven minor releases, adding variables, loops, conditionals, structured output, retry logic, a web playground, IDE support with full Language Server Protocol, and an MCP server that integrates with Claude Code and Claude Desktop.

A few lessons stood out.

Constraints are features. SLANG is deliberately not Turing-complete. You can't write arbitrary logic in it. That's by design. The limited surface area means the language is easy to learn, easy to parse, and easy for LLMs to generate correctly. Every time I was tempted to add a general-purpose feature, I asked myself: "Can this be handled by the LLM inside a stake call instead?" The answer was almost always yes.

The execution model matters more than syntax. The hardest part wasn't designing keywords. It was defining what a "round" means, how parallel execution works, when agents block, how data flows through mailboxes. Getting the execution model right meant that advanced patterns like iterative review loops, competitive analysis, and hierarchical delegation fell out naturally from the three primitives.

Zero-setup mode is the killer feature. I originally built it as a demo gimmick. But it turned out to be the thing people use most. Being able to paste a workflow into any LLM chat and have it execute immediately, that removes every single adoption barrier. No install, no signup, no configuration. Just paste and go. When I see someone go from "what is this" to "this is running" in under sixty seconds, I know the abstraction is working.

The Future of Declarative Agent Orchestration

I don't think SLANG is the final answer. I think it's the right question, phrased as code. The question is: can we separate the description of what agents should do from the mechanics of how they do it?

If the answer is yes, and I believe it is, then the implications are significant. Workflows become shareable artifacts, like SQL queries or Docker images. Teams can collaborate on agent logic without agreeing on a tech stack. LLMs can generate, modify, and optimize workflows directly. And the entire ecosystem can move faster because the orchestration layer is standardized.

SLANG is open source and available on npm. You can install it with npm install -g @riktar/slang, open the playground with slang playground, or just grab the zero-setup prompt and paste it into your favorite LLM right now. The spec, grammar, and full documentation are all on the GitHub repo.

I built this because I got tired of rewriting the same agent coordination logic in different frameworks. If you've ever felt that frustration, I think you'll find something useful here.

The SQL of AI agents. That's the bet. Let's see where it goes.

SLANG is **open source* under MIT license. Star the repo, open issues, contribute. The language is young and there's a lot of surface area to cover. If you're building multi-agent systems and want to help shape what this becomes, I'd love to hear from you.*

Find everything at: github.com/riktar/slang

Stop Fighting with NestJS Modules: Meet Rikta

Riccardo Tartaglia — Mon, 19 Jan 2026 16:45:07 +0000

You love NestJS. The decorators feel elegant. The structure keeps your codebase clean. TypeScript integration works well.

Then you add a new service.

You import it in one module. Export it in another. Inject it somewhere else. Suddenly, you get this error:

Nest can't resolve dependencies of the UserService (?). 
Please make sure that the argument at index [0] 
is available in the current context.

Sound familiar?

The Module Problem

NestJS modules solve a real problem: dependency boundaries. They prevent chaos in large codebases.

But they come at a cost.

Every new service requires you to:

Create the service with @Injectable()
Add it to a module's providers array
Add it to the exports array if other modules need it
Import the module in every place that uses it

Here's what a typical NestJS module looks like:

// user.module.ts
@Module({
  imports: [
    DatabaseModule,
    ConfigModule,
    AuthModule,
    LoggingModule,
  ],
  controllers: [UserController],
  providers: [
    UserService,
    UserRepository,
    UserValidator,
    UserMapper,
  ],
  exports: [UserService, UserRepository],
})
export class UserModule {}

This is boilerplate. Pure configuration overhead.

And it grows. Fast.

A medium-sized app has 20+ modules. Each module has 5-10 providers. You spend more time managing arrays than writing business logic.

The worst part? A typo in any array breaks your entire dependency graph. Debugging takes hours.

What If You Didn't Need Modules?

Rikta is a new TypeScript framework built on Fastify. It keeps the parts developers love about NestJS (decorators, DI, structure) and removes the module configuration entirely.

No imports arrays.
No exports arrays.
No providers arrays.

Decorate your class. Everything works.

// user.service.ts
import { Injectable } from '@riktajs/core';

@Injectable()
export class UserService {
  getUsers() {
    return ['Alice', 'Bob'];
  }
}

// user.controller.ts
import { Controller, Get, Autowired } from '@riktajs/core';
import { UserService } from './user.service';

@Controller('/users')
export class UserController {
  @Autowired()
  private userService!: UserService;

  @Get()
  getUsers() {
    return this.userService.getUsers();
  }
}

That's it. No module file. No registration. Rikta scans your code at startup and resolves dependencies automatically.

How Zero-Config Autowiring Works

Rikta uses three mechanisms:

1. Automatic Discovery

At startup, Rikta scans your project for classes decorated with @Controller() or @Injectable(). It builds a dependency graph from constructor parameters and @Autowired() decorators.

2. Global Provider Registry

All providers live in a single registry. Any injectable class is available anywhere in your app. No need to export or import.

3. Dependency Resolution

Rikta reads TypeScript metadata (via reflect-metadata) to understand what each class needs. It creates instances in the correct order and injects them automatically.

The framework detects circular dependencies during initialization and throws a clear error:

Error: Circular dependency detected: 
UserService -> AuthService -> UserService

No cryptic stack traces. No runtime surprises.

A Side-by-Side Comparison

Creating a new feature in NestJS:

// 1. Create the service
@Injectable()
export class PaymentService {
  constructor(private configService: ConfigService) {}
}

// 2. Create the module
@Module({
  imports: [ConfigModule],
  providers: [PaymentService],
  exports: [PaymentService],
})
export class PaymentModule {}

// 3. Import in app.module.ts
@Module({
  imports: [PaymentModule, /* ... */],
})
export class AppModule {}

// 4. Import in any module that needs it
@Module({
  imports: [PaymentModule],
  providers: [OrderService],
})
export class OrderModule {}

Creating the same feature in Rikta:

@Injectable()
export class PaymentService {
  @Autowired()
  private configService!: ConfigService;
}

Done.

Performance Benefits

Rikta uses Fastify as its HTTP layer. Fastify handles up to 30,000 requests per second in benchmarks.

Benchmark results from the official repository:

Metric	Rikta vs NestJS
Startup time	43% faster
GET requests	41% faster
POST requests	25% faster
Route parameters	46% faster

Rikta adds minimal overhead (2-5%) over vanilla Fastify. You get dependency injection and decorators without sacrificing speed.

Built-in Zod Validation

NestJS uses class-validator decorators for validation. This works, but you define types twice: once for TypeScript, once for validation.

Rikta integrates Zod natively. Define a schema once. Get validation and TypeScript types automatically.

import { Controller, Post, Body, z } from '@riktajs/core';

const CreateUserSchema = z.object({
  email: z.string().email(),
  name: z.string().min(2),
  age: z.number().optional(),
});

@Controller('/users')
export class UserController {
  @Post()
  create(@Body(CreateUserSchema) user: z.infer<typeof CreateUserSchema>) {
    // 'user' is validated AND typed
    // Invalid requests return 400 automatically
    return { created: user };
  }
}

No duplicate type definitions. No manual error handling for validation failures.

When To Use Rikta

Rikta works best for:

Startups and MVPs where development speed matters
Small to medium teams (1-15 developers)
Microservices where each service stays focused
Developers who know NestJS and want less boilerplate

Consider NestJS if:

You have a large team that needs strict module boundaries
You require the extensive NestJS ecosystem (specific adapters, plugins)
Your organization mandates explicit dependency documentation

Getting Started

Create a new project in seconds:

npx @riktajs/cli new my-app
cd my-app
npm run dev

Your API runs at http://localhost:3000.

The CLI generates a complete project with:

TypeScript configuration optimized for Rikta
Example controller with REST endpoints
Example service with dependency injection
Hot reload development server

Resources

Documentation: rikta.dev
GitHub: github.com/riktaHQ/rikta.js
NPM: @riktajs/core

Rikta is MIT licensed and open source.

Have you tried zero-config frameworks? What do you think about the module vs. autowiring tradeoff? Share your experience in the comments.

How I build Rikta: a Zero-Config TypeScript Backend Framework

Riccardo Tartaglia — Fri, 09 Jan 2026 16:06:23 +0000

TL;DR: Rikta is an open source TypeScript framework that eliminates NestJS "module hell" through automatic dependency injection and decorator-based routing. Built on Fastify, it delivers 32% better performance than NestJS while maintaining full type safety.

GitHub Repository https://github.com/riktaHQ/rikta
Documentation https://rikta.dev

What is Rikta and Why Does It Exist?

Rikta is an open source TypeScript backend framework designed for developers who want structure without complexity.

The Node.js ecosystem offers two extremes. On one side, you have Express: minimal, flexible, but unstructured. On the other, NestJS: enterprise-ready, but verbose and configuration-heavy.

Rikta occupies the middle ground. It provides dependency injection, decorator-based routing, and automatic validation without requiring manual module configuration.

The Problem: NestJS Module Hell

NestJS dominates enterprise Node.js development. It brings Angular-style architecture to the backend: modules, providers, dependency injection, and decorators.

But developers consistently report the same frustration: module configuration overhead.

Here is a typical NestJS module:

@Module({
  imports: [DatabaseModule, AuthModule, CacheModule],
  controllers: [UserController],
  providers: [UserService, UserRepository],
  exports: [UserService],
})
export class UserModule {}

Every service needs explicit registration in providers. Every cross-module dependency requires imports and exports arrays. Circular dependencies trigger cryptic error messages.

The community calls this "Module Hell."

Common NestJS Pain Points

Verbose boilerplate: Creating a simple service requires touching multiple files
Circular dependency errors: The infamous "Nest can't resolve dependencies" message
Configuration drift: Forgetting to export a service breaks consumers silently
forwardRef everywhere: Workarounds become the norm, not the exception

Rikta's Solution: Zero-Config Autowiring

Rikta takes a radically different approach. You decorate a class, and the framework handles everything else.

@Injectable()
export class GreetingService {
  getGreeting(): string {
    return 'Welcome to Rikta!';
  }
}

@Controller()
export class AppController {
  @Autowired()
  private greetingService!: GreetingService;

  @Get('/')
  index() {
    return { message: this.greetingService.getGreeting() };
  }
}

No module files. No imports/exports arrays. No providers configuration.

The framework automatically discovers decorated classes, resolves dependencies, and wires everything together at startup.

Technology Stack and Architecture Decisions

Rikta's stack reflects three core goals: performance, type safety, and developer experience.

Why Fastify Instead of Express?

Rikta builds on Fastify rather than Express. This choice stems from three factors.

1. Raw Performance

Fastify handles up to 30,000 requests per second in benchmarks. Its schema-based validation compiles JSON schemas into optimized functions at startup. Express runs validation at runtime for every request.

2. Plugin Architecture

Fastify encapsulates functionality into isolated plugins with their own dependency injection scope. This maps cleanly to Rikta's service architecture.

3. Native TypeScript Support

Fastify ships with complete type definitions. The type system uses generics for request/response typing, eliminating manual type assertions.

Why TypeScript is Mandatory

TypeScript is not optional in Rikta. The framework uses experimental decorators and reflect-metadata for dependency injection.

This enables powerful features like automatic type inference from Zod schemas:

@Post()
create(@Body(UserSchema) user: z.infer<typeof UserSchema>) {
  // TypeScript infers the user type from the Zod schema
  // Runtime validation happens automatically
}

Why Zod for Validation

Zod schemas define both runtime validation rules and TypeScript types in a single source of truth.

This prevents the common problem of validation logic diverging from type definitions. One schema, two purposes.

Monorepo Structure

The project uses npm workspaces to manage multiple packages:

packages/
├── core/       # DI, routing, lifecycle
├── cli/        # Project scaffolding
├── swagger/    # OpenAPI documentation
└── typeorm/    # Database integration

This structure keeps the core lightweight. Developers install only what they need.

Architecture Deep Dive

Rikta's architecture centers on three systems: dependency injection, routing, and lifecycle management.

High-Level Architecture Diagram

┌─────────────────────────────────────────────────────────────────┐
│                     APPLICATION BOOTSTRAP                        │
│                        Rikta.create()                           │
└─────────────────────────────────────────────────────────────────┘
                                │
                                ▼
┌─────────────────────────────────────────────────────────────────┐
│                    AUTO-DISCOVERY ENGINE                         │
│                                                                  │
│   File Scan ──▶ Decorator Detection ──▶ Metadata Extraction     │
│                                                                  │
└─────────────────────────────────────────────────────────────────┘
                                │
                                ▼
┌─────────────────────────────────────────────────────────────────┐
│                 DEPENDENCY INJECTION CONTAINER                   │
│                                                                  │
│   ┌───────────┐ ┌───────────┐ ┌───────────┐ ┌───────────┐      │
│   │ Singleton │ │ Transient │ │  Factory  │ │   Value   │      │
│   │   Scope   │ │   Scope   │ │  Provider │ │   Token   │      │
│   └───────────┘ └───────────┘ └───────────┘ └───────────┘      │
│                                                                  │
└─────────────────────────────────────────────────────────────────┘
                                │
                                ▼
┌─────────────────────────────────────────────────────────────────┐
│                      ROUTE REGISTRATION                          │
│                                                                  │
│   Controller Metadata ──▶ Route Building ──▶ Fastify Handler    │
│                                                                  │
└─────────────────────────────────────────────────────────────────┘
                                │
                                ▼
┌─────────────────────────────────────────────────────────────────┐
│                        FASTIFY SERVER                            │
│                 HTTP Request/Response Handling                   │
└─────────────────────────────────────────────────────────────────┘

How Dependency Injection Works in Rikta

Rikta's DI system uses TypeScript decorators and the reflect-metadata library. Here is how the pieces connect.

The @Injectable Decorator

import 'reflect-metadata';

const INJECTABLE_KEY = Symbol('injectable');

export function Injectable(): ClassDecorator {
  return (target: Function) => {
    Reflect.defineMetadata(INJECTABLE_KEY, true, target);
  };
}

This decorator marks a class as a provider. The metadata flag tells the container this class should be managed.

The @Autowired Decorator

const AUTOWIRED_KEY = Symbol('autowired');

export function Autowired(token?: symbol): PropertyDecorator {
  return (target: Object, propertyKey: string | symbol) => {
    const type = Reflect.getMetadata('design:type', target, propertyKey);
    const autowiredDeps = Reflect.getMetadata(AUTOWIRED_KEY, target) || [];
    autowiredDeps.push({ propertyKey, type, token });
    Reflect.defineMetadata(AUTOWIRED_KEY, autowiredDeps, target);
  };
}

This decorator records which properties need injection. It captures the property name, the type (from TypeScript's emitted metadata), and an optional token for custom providers.

Container Resolution Logic

The container performs topological sorting to resolve dependencies in the correct order.

class Container {
  private providers = new Map<Function | symbol, any>();

  resolve<T>(target: Function | symbol): T {
    // Return cached instance if exists (Singleton pattern)
    if (this.providers.has(target)) {
      return this.providers.get(target);
    }

    // Get constructor parameter types via reflect-metadata
    const paramTypes = Reflect.getMetadata('design:paramtypes', target) || [];

    // Resolve each dependency recursively
    const dependencies = paramTypes.map((type: Function) => this.resolve(type));

    // Instantiate with resolved dependencies
    const instance = new (target as any)(...dependencies);

    // Handle @Autowired properties
    const autowired = Reflect.getMetadata(AUTOWIRED_KEY, target.prototype) || [];
    for (const dep of autowired) {
      instance[dep.propertyKey] = this.resolve(dep.token || dep.type);
    }

    // Cache and return
    this.providers.set(target, instance);
    return instance;
  }
}

Understanding Provider Scopes

Rikta supports two scopes: Singleton and Transient.

Scope	Behavior	Use Case
Singleton (default)	One instance for entire app	Services, repositories, configs
Transient	New instance on every injection	Request loggers, unique IDs

@Injectable({ scope: 'transient' })
export class RequestLogger {
  private requestId = crypto.randomUUID();

  log(message: string) {
    console.log(`[${this.requestId}] ${message}`);
  }
}

Routing System Implementation

Rikta's routing wraps Fastify's router with decorator-based configuration.

Controller and Route Decorators

export function Controller(prefix: string = ''): ClassDecorator {
  return (target: Function) => {
    Reflect.defineMetadata('controller:prefix', prefix, target);
    Reflect.defineMetadata('controller', true, target);
  };
}

export function Get(path: string = ''): MethodDecorator {
  return (target, propertyKey, descriptor) => {
    const routes = Reflect.getMetadata('routes', target.constructor) || [];
    routes.push({ method: 'GET', path, handler: propertyKey });
    Reflect.defineMetadata('routes', routes, target.constructor);
  };
}

Parameter Extraction

Rikta provides decorators for automatic request data extraction:

@Post('/users')
createUser(
  @Body() body: CreateUserDto,
  @Query('role') role: string,
  @Param('id') id: string,
  @Headers('authorization') auth: string
) {
  // Parameters are automatically extracted and injected
}

Each decorator stores metadata about which request property to extract. The route handler reads this metadata and builds the argument list before invoking the controller method.

Validation with Zod Integration

Rikta integrates Zod validation directly into the request pipeline.

Defining Schemas

import { z } from 'zod';

export const CreateUserSchema = z.object({
  email: z.string().email(),
  password: z.string().min(8),
  name: z.string().optional(),
});

export type CreateUserDto = z.infer<typeof CreateUserSchema>;

Automatic Request Validation

When you pass a Zod schema to the @Body decorator, Rikta validates incoming requests automatically:

@Post('/users')
createUser(@Body(CreateUserSchema) user: CreateUserDto) {
  // If validation fails: 400 Bad Request with error details
  // If validation passes: user is typed and validated
}

The framework compiles Zod schemas into Fastify's JSON schema format at startup. This enables Fastify's optimized validation path.

Lifecycle Hooks and Event Bus

Rikta provides hooks for application lifecycle events and an internal event bus for cross-service communication.

Available Lifecycle Hooks

Hook	When It Fires
OnProviderInit	After provider instantiation, dependencies injected
OnApplicationBootstrap	After all providers initialized, before server starts
OnApplicationShutdown	When app receives termination signal

@Injectable()
export class DatabaseService implements OnProviderInit {
  async onProviderInit() {
    await this.connect();
    console.log('Database connected');
  }
}

Event Bus for Loose Coupling

The event bus enables services to communicate without direct dependencies:

@Injectable()
export class UserService {
  @Autowired()
  private eventBus!: EventBus;

  async createUser(data: CreateUserDto) {
    const user = await this.repository.save(data);
    this.eventBus.emit('user.created', user);
    return user;
  }
}

@Injectable()
export class NotificationService {
  @OnEvent('user.created')
  async handleUserCreated(user: User) {
    await this.sendWelcomeEmail(user.email);
  }
}

Performance: Rikta vs NestJS Benchmarks

Rikta targets NestJS performance as a baseline. Here are the benchmark results from the official repository:

Metric	Improvement vs NestJS	Winner
Startup Time	37.7% faster	Rikta
GET Requests	44.3% faster	Rikta
POST Requests	14.8% faster	Rikta
Param Requests	36.7% faster	Rikta
Average	32.0% faster	Rikta

Why Rikta is Faster

The performance gains come from three sources:

Fastify's optimized HTTP handling vs Express (NestJS default)
Reduced abstraction layers in the DI system
No module resolution overhead at runtime

Production Optimization Tips

For maximum performance in production:

const app = await Rikta.create({
  port: 3000,
  silent: true,    // Disable console output
  logger: false    // Disable Fastify logging
});

Technical Challenges and Solutions

Building Rikta required solving several non-trivial technical problems.

Challenge 1: TypeScript Decorator Metadata

Problem: TypeScript's reflect-metadata requires specific compiler settings. Without emitDecoratorMetadata: true, the framework cannot read constructor parameter types.

Solution: The CLI scaffolds projects with the correct tsconfig.json:

{
  "compilerOptions": {
    "experimentalDecorators": true,
    "emitDecoratorMetadata": true
  }
}

Challenge 2: Circular Dependencies

Problem: Unlike NestJS, Rikta has no module boundaries to catch circular dependencies early. Two services injecting each other creates an infinite resolution loop.

Solution: Rikta detects cycles during container initialization and throws a clear error message identifying the circular path:

Error: Circular dependency detected:
  UserService -> AuthService -> UserService

Challenge 3: Property Injection Timing

Problem: The @Autowired decorator injects into class properties. But TypeScript initializes properties before the constructor runs. Default values overwrite injected dependencies.

Solution: Use the definite assignment assertion pattern:

@Autowired()
private greetingService!: GreetingService;  // Note the !

The ! tells TypeScript the property will be assigned externally.

Challenge 4: Auto-Discovery Performance

Problem: Scanning the filesystem for decorated classes adds startup time. Large projects with thousands of files see noticeable delays.

Solution: Rikta scans only specific directories (src/controllers, src/services by default). Configuration allows customizing scan paths.

Best Practices Applied in Rikta

1. Single Responsibility for Decorators

Each decorator does one thing. @Injectable marks providers. @Controller marks controllers. @Get defines routes.

2. Fail Fast on Configuration Errors

Rikta validates configuration at startup, not at runtime. Missing dependencies, invalid schemas, and circular references throw immediately.

3. Minimal Core, Optional Packages

The core package includes DI, routing, and lifecycle. Database integration, Swagger documentation, and CLI tooling live in separate packages.

4. Convention Over Configuration

Default behaviors match common patterns. Controllers live in src/controllers. Services live in src/services. The default scope is Singleton.

Lessons Learned

Lesson 1: Module Systems Have Trade-offs

NestJS modules feel verbose, but they provide explicit dependency boundaries. Rikta's autowiring feels magical, but debugging requires understanding the implicit resolution order.

Neither approach is universally better. The choice depends on team size and project complexity.

Lesson 2: Decorator Magic Needs Documentation

Decorators hide implementation details. This improves developer experience when everything works. It creates confusion when things break.

Rikta invests heavily in error messages that explain what the framework expected and what it found.

Lesson 3: Fastify Plugin Scoping

Fastify plugins have encapsulation by default. A plugin registered in one scope cannot access decorators from another scope.

Rikta's global DI container works around this, but integrating with Fastify plugins requires careful scoping.

Lesson 4: TypeScript Decorators Are Experimental

The decorator specification has changed multiple times. TypeScript 5 introduced the new standard, but Rikta uses legacy decorator syntax for reflect-metadata compatibility.

This creates migration risk for future TypeScript versions.

Lesson 5: Zero-Config Has Limits

Auto-discovery works for small to medium projects. Enterprise applications with hundreds of services need explicit control over instantiation order, lazy loading, and module boundaries.

Rikta provides escape hatches, but the core design assumes simpler use cases.

Getting Started with Rikta

Install and scaffold a new project in seconds:

npx @riktajs/cli new my-app
cd my-app
npm run dev

The CLI generates a complete project structure:

my-app/
├── src/
│   ├── controllers/
│   │   └── app.controller.ts
│   ├── services/
│   │   └── greeting.service.ts
│   └── main.ts
├── package.json
└── tsconfig.json

Your API runs at http://localhost:3000.

Conclusion

Rikta offers a compelling alternative for TypeScript backend development. It combines the performance of Fastify, the structure of decorator-based DI, and the simplicity of zero-config autowiring.

The framework is MIT licensed and welcomes contributions. If you are tired of NestJS module boilerplate but need more structure than Express provides, Rikta deserves your attention.

Star the repository on GitHub and try it in your next project.

GitHub Repository https://github.com/riktaHQ/rikta
Documentation https://rikta.dev

I Used to Work 12-Hour Days. Then I Let AI Do Half My Job.

Riccardo Tartaglia — Mon, 27 Oct 2025 15:18:05 +0000

Last Tuesday at 3 PM, I caught myself staring at my screen. I had written the same authentication middleware for the fourth time that month. Different project. Same code. Copy, paste, tweak variable names, ship.

This is what they don't tell you about software development. You spend 60% of your time rewriting things you already wrote.

I needed help. Not the "read another productivity blog" kind. Real help.

So I started experimenting with developer productivity AI tools. Here's what I learned after three months of trial and error.

The Autocomplete Trap

GitHub Copilot showed up first. I typed a function name and it autocompleted entire blocks. Impressive for a week. Then I noticed something. It suggested code I wrote last year. Good code. Bad code. All code. The AI didn't judge. It regurgitated.

I needed something smarter.

TabNine came next. Better context awareness. It learned my coding style. But it still felt like autocomplete on steroids. I wanted a tool that understood what I was building, not what I was typing.

Then I found artiforge.ai.

It’s not an AI coding agent, it is an AI Enhancer

It works in every IDE that use an MCP client.

The Difference

The difference hit me on day one. With one prompt my LLM can retrieve my project documentation. The entire spec. User stories. API contracts. Database schemas. Everything that had a logic sense in the context of the feature.

I asked it to generate a complete REST API endpoint with validation, error handling, and tests.

It delivered in 90 seconds.

Production-ready code that followed my project's conventions. The error messages matched my existing patterns. The tests covered edge cases I forgot existed.

I spent the next hour reviewing instead of writing. Found two logical issues. Fixed them. Shipped the feature before lunch.

The Mental Shift

Here's what clicked for me. Most AI coding tools treat you like you're writing a novel. One word at a time. artiforge.ai treats you like an architect. You describe the building. It handles the bricks.

I still use Copilot for quick completions. I still use ChatGPT to explain complex algorithms. But when I need to build something from scratch, I go to artiforge.ai.

My New Workflow

Morning: Review tickets and write specs. Feed them to artiforge.ai. Get initial implementations.

Midday: Review generated code. Refine. Test. Deploy.

Afternoon: Focus on architecture decisions. Complex business logic. Things that need human judgment.

My 12-hour days became 8-hour days. My output doubled.

The Irony

The irony? I worried AI would make developers obsolete. Instead, it made me better at being a developer. I stopped being a code monkey. I became a code reviewer. A decision maker. An architect.

Your tools define your workflow. Choose tools that multiply your skills instead of replacing them.

The Real Productivity Hack

I'm not saying artiforge.ai is perfect. No tool is. But it changed how I think about productivity. Stop optimizing for speed. Start optimizing for leverage.

The best developers aren't the fastest typers. They're the ones who know when to write code and when to generate it.

Try It Yourself

Try artiforge.ai for your next feature. Upload your specs. See what happens. Worst case, you waste 10 minutes. Best case, you get your afternoon back.

I got mine back. Now I spend it learning Rust instead of rewriting Express middleware.

Worth it.

5 Essential MCP Servers Every Developer Should Know

Riccardo Tartaglia — Fri, 10 Oct 2025 15:51:41 +0000

I've been experimenting with Model Context Protocol servers for a few months now, and I have to say, they've changed the way I work. If you're not familiar with MCP, think of it as a universal adapter that lets your AI coding assistant actually do things, access your files, push to GitHub, search the web, whatever you need. It's like giving your AI a set of hands instead of just a voice.

The thing is, there are hundreds of MCP servers out there now, and it's easy to get lost in the noise. So I wanted to share the five that have actually made a difference in my daily workflow. These aren't just cool demos. They're tools I reach for without thinking about it anymore.

1. Artiforge.ai

Let me start with the one that surprised me the most.
Artiforge isn't just another MCP server—it's more like a complete AI development toolkit that happens to work through MCP. I stumbled across it when I was frustrated with context switching between my IDE and various AI tools, and it ended up solving problems I didn't even know I had.

What makes Artiforge different is that it brings orchestration directly into your coding environment. Instead of bouncing between terminals, documentation, and chat windows, you can plan complex features, generate documentation, and coordinate multiple AI agents from one place. The setup is surprisingly straightforward too, you generate a personal access token from their dashboard, install the MCP server in Cursor or Windsurf, and you're ready to go.

The two features that made me a believer:

First, the orchestration tool lets you deploy complex features from simple prompts. It creates plans, workflows, and integrates multiple AI agents without you having to manually wire everything together.

Second, the documentation generator is incredible. It automatically creates detailed guides and API references from your codebase, which has saved me countless hours of writing docs that nobody wants to write but everyone needs.

The free trial gives you 15 days with full access and 80 credits to test everything out. I ended up subscribing because the workflow improvements were too valuable to give up.

2. Filesystem

This one feels obvious once you have it, but working without it now seems ridiculous. The Filesystem MCP server gives your AI assistant actual access to your local files. Not just reading them and pasting content into a chat, real file operations.

I use it constantly for things like "organize all the images on my desktop into a new folder" or "find all the TODO comments across my project files." It handles the tedious file management stuff that interrupts your flow when coding. You can also have your AI write content directly to files, which is perfect for generating boilerplate, updating configs, or creating documentation.

The security model is smart. You explicitly define which directories the server can access, so there's no risk of your AI wandering off into sensitive folders. It uses the Model Context Protocol's standard approach, you specify allowed directories when you start the server, and everything is sandboxed within those boundaries.

What I appreciate most: It removes friction from the development process. Instead of copying file paths, opening multiple windows, or context switching to handle basic file operations, your AI just does it. The mental overhead reduction is real.

3. GitHub

The official GitHub MCP server has become essential for how I interact with repositories. It gives your AI direct access to GitHub's platform, so you can manage issues, review pull requests, and analyze code without leaving your conversation.

GitHub recently rewrote this server in Go and added a bunch of improvements. The remote version uses OAuth authentication, which means you don't need to manage personal access tokens or worry about Docker containers. It's one-click setup in VS Code, and you're connected.

Two things that make this indispensable:

First, repository intelligence. You can search code, stream files, and open pull requests without cloning anything locally. When I'm reviewing someone's PR or trying to understand a new codebase, being able to ask "show me where authentication is handled" and getting actual code references is invaluable.

Second, the CI/CD visibility. Being able to inspect workflow runs, fetch logs, and re-run failed jobs from a chat interface has eliminated so much tab switching and waiting around.

The server also surfaces security insights, code scanning alerts and Dependabot warnings so you can address vulnerabilities before they become problems. It's the kind of integration that feels like it should have existed years ago.

4. Sequential Thinking

This one's less about automation and more about problem-solving. The Sequential Thinking server helps you work through complex problems by breaking them down into discrete thought sequences. It's particularly useful when you're debugging something gnarly or architecting a new feature.

I find myself using it when I'm stuck on architectural decisions or trying to reason through edge cases. You describe what you're working on, and it walks through the problem step by step, exposing assumptions and helping you think more clearly. It's like having a really patient rubber duck that actually talks back.

The dynamic reflection aspect is what sets it apart. As you work through a problem, it adjusts its approach based on what's working and what isn't. It doesn't just follow a rigid template, it adapts to how you think and the specific problem you're solving.

5. Fetch

The Fetch server does one thing exceptionally well: it grabs web content and converts it into something your AI can actually use efficiently. When you need to pull documentation, analyze a competitor's site, or incorporate external content into your workflow, this is what you reach for.

What makes it valuable is the conversion process. It doesn't just dump raw HTML at your AI. It processes web content into a clean, LLM-friendly format that preserves the important structure while stripping out the noise. This means your AI can actually understand and work with web content instead of getting confused by markup and styling.

I use it most often when researching APIs or checking documentation. Instead of copy-pasting from a dozen browser tabs, I can just point the server at the URLs I need, and it handles the rest. The time savings add up fast, especially when you're comparing approaches across multiple sources.

The other win: It respects your context window. By intelligently processing content, it ensures you're not wasting tokens on irrelevant markup, which becomes critical when you're working with multiple sources.

The Bigger Picture

MCP servers are still relatively new, but they're quickly becoming the standard way to extend AI capabilities. What I've learned from using these five is that the best tools are the ones that disappear, they solve problems so cleanly that you forget they're even there.

If you're just getting started with MCP, I'd recommend beginning with Artiforge and the Filesystem server. They'll give you immediate productivity gains without a steep learning curve. From there, add GitHub if you're working with repositories regularly, and Sequential Thinking when you're tackling complex problems.

The ecosystem is growing fast, and new servers are popping up constantly. But these five have proven themselves in daily use. They're not experimental, they're reliable tools that make development work better.

The future of development is collaborative, with AI as a genuine partner in the process. MCP servers are what make that partnership actually work.

JSX Unchained: Make a template engine without React

Riccardo Tartaglia — Wed, 18 Oct 2023 14:20:36 +0000

Hello, developer.

Today, let's talk about JSX, the love-hate relationship of all React developers. Many hate it, many love it, but have you ever wondered how you could make the most of the power of JSX outside the usual React context?

Well, you're in the right place!

In the vast world of web development, the use of JSX in combination with React has changed how we create dynamic and responsive user interfaces. It must be admitted that the developer experience (DX) offered by React dominates over other frameworks, and JSX is one of the factors that has contributed to the success of this endeavor.

However, at times, you might feel the need to free JSX from this tight connection with React, thus opening the doors to new creative possibilities.

Let's peek behind the scenes.

Here's where the questions arise: how can we use JSX independently, without the weight of React? This article is here to guide you through the construction of a template engine that will allow you to do just that.

Imagine being able to leverage the powerful syntax of JSX in scenarios outside the traditional framework, customizing how JSX elements are evaluated and rendered (pretty cool, huh?).

Before diving into the creation of our template engine, let's take a quick look at what's behind the scenes between JSX and React:

JSX, which stands for JavaScript XML, is a kind of markup language that looks very similar to HTML. In reality, behind a JSX tag, there's the React.createElement function that handles the transformation of components. Yes, JSX tags are actually JavaScript functions (when you've recovered from the shock, keep reading).

Initially, JSX was designed to be used exclusively with React, but over time, it has evolved more and more to be considered a project on its own.

Our goal is, therefore, to create a template engine that adapts to our needs using JSX. Whether you're building a lightweight and fast app or exploring unusual scenarios, this template engine will be the key to opening new doors to our creativity.

Template Engine Design

Let's start with this:

I want to maintain the DX of React and write a core capable of translating my JavaScript functions, enriched with JSX, into a representation of pure HTML.

Imagine being able to define your user interface declaratively and then, with a magical touch, make it ready for action.

But how do we achieve all this?

Simple, we need a bundler! In particular, in this article, I'll use Webpack, but you can reconstruct everything with Vite, EsBuild, etc.

I'll try to guide you step by step.

Let's initialize the project.

Create a new folder and type:

npm init -y

Done? Great.

Now we need two things in particular:

The first thing is to install Webpack, and the second is to use a transpiler to "transform" our JSX into JavaScript objects.

As for the second point, we'll use Babel, but let's focus on Webpack for now.

npm i -D webpack webpack-cli webpack-dev-server html-webpack-plugin

Great! Now let's install Babel.

npm i -D @babel/cli @babel/core @babel/preset-env babel-loader

Last piece: we need a Babel plugin that allows us to transpile JSX. We'll delve into its usage later.

npm i -D @babel/plugin-transform-react-jsx

Now that we've installed all the necessary dependencies, let's add the following scripts to our package.json.

"scripts": {
    "test": "echo \"Error: no test specified\" && exit 1",
    "build": "webpack",
    "start": "webpack serve --open",
    "dev": "webpack-dev-server --open"
}

Plainly put, these scripts are for running our project and building it if we want to. Now, we need to create our "magic." Thanks to the babel/plugin-transform-react-jsx plugin, we can tell Babel to handle a custom runtime for transpiling JSX.

Essentially, we will now customize how Babel should "evaluate" JSX expressions. So, in the root of our project, let's create the file jsx-runtime.js.

const add = (parent, child) => {
  parent.appendChild(child?.nodeType ? child : document.createTextNode(child));
};

const appendChild = (parent, child) => {
  if (Array.isArray(child)) {
    child.forEach((nestedChild) => appendChild(parent, nestedChild));
  } else {
    add(parent, child);
  }
};

export const jsx = (tag, props) => {
  const { children, ...rest } = props;
  if (typeof tag === 'function') return tag(props, children);
  const element = document.createElement(tag);

  for (const p in rest) {
    if (p.startsWith('on') && p.toLowerCase() in window) {
      element.addEventListener(p.toLowerCase().substring(2), props[p]);
    }
  }

  appendChild(element, children);
  return element;
};

export const jsxs = jsx;

This very minimal runtime allows us to transform our "components" with props into pure HTML, bidding farewell to the Virtual DOM. Consider that we could extend the runtime to handle custom components, directives, or anything else that comes to mind. In short, see it as the foundation of our template engine or a future framework.

Let's add the last piece of the puzzle: the webpack configuration file. Again, in the root of the project, let's create the webpack.config.js file.

const HtmlWebpackPlugin = require('html-webpack-plugin');

const path = require('path');
module.exports = {
  entry: './src/index.js',
  mode: 'production',
  output: {
    path: `${__dirname}/dist`,
    filename: 'bundle.js',
  },
  module: {
    rules: [
      {
        test: /\.(?:js|jsx|mjs|cjs)$/,
        exclude: /node_modules/,
        use: {
          loader: 'babel-loader',
          options: {
            presets: [['@babel/preset-env']],
            plugins: [
              [
                '@babel/plugin-transform-react-jsx',
                {
                  runtime: 'automatic',
                  importSource: path.resolve(__dirname + '/./'),
                },
              ],
            ],
          },
        },
      },
    ],
  },
  resolve: {
    extensions: ['', '.js', '.jsx'],
  },
  plugins: [
    new HtmlWebpackPlugin({
      template: './public/index.html',
    }),
  ],
};

If we look at the module attribute, we find the configuration for Babel and the plugin plugin-transform-react-jsx, which refers to the root of the project to find our custom runtime file.

Aaaaaand that's it, we're done.

If you want a working example of what I've described so far, I've prepared a functional project for you on StackBlitz.

What's missing? A reactivity system. But that's another story...

Conclusion

And so, our journey into the discovery of an independent template engine based on JSX comes to an end. We've explored the reasons behind the need to free JSX from React, delved into the architecture of the template engine, and tackled the challenge of implementing a flexible and powerful templating language.

With this tool at your disposal, you're now armed with a new perspective in web development. Take a look at the benefits that this freedom can bring to your daily workflow.

Your feedback is valuable. If you've experimented with the proposed template engine, have questions, or suggestions on how to improve it, feel free to share them in the comments. If the article has been helpful, share it with your developer friends!

React Advanced: Manage Server States in the right way

Riccardo Tartaglia — Fri, 29 Sep 2023 18:54:42 +0000

Hello, developer. Today we'll tackle a crucial topic: managing server states in an advanced React app. No frills, just the essential facts on how to make this aspect work efficiently.

React and its Dirty Work

You know how powerful React is in handling the frontend. But now, let's talk about something more substantial: how does React manage data exchange with the backend? The answer? Server states.

Connecting the Dots

Server states are the glue that holds together the frontend and backend. Nothing magical, just the need to make these two worlds communicate coherently and without frills.

Order in Chaos

Centralization is the key. Imagine having a central place where all the data resides. Sounds neat, right? And that's exactly what you want to avoid chaos when things get more complex.

A Bit of Realism

We're not here to tell you fairy tales. Managing server states can be complicated. It's the practical and sometimes challenging side of development. But no need to panic; we'll face the challenges together.

Beyond the Basic Concept

We won't stop at defining the basic concept. We want to equip you with tools to go beyond, to tackle complex scenarios, and enhance your application.

So, enough talk. We're here to handle the dirty work and give you the information you need to make server states work smoothly in React. Ready to dive into the details? Let's get to it.

Role of Server States in a React Application

The effective management of server states forms the backbone of an advanced React application. In this chapter, we will delve into the crucial role that server states play in the React development ecosystem.

Dynamic Communication

Server states act as a vital bridge between the frontend and backend of an application. They enable dynamic communication, allowing the frontend to efficiently receive and send data to the server. This interaction is essential for real-time and dynamic applications, such as those requiring instant or live updates.

Centralization of State

A crucial aspect is the centralization of server states. By maintaining a centralized state, the application reduces the chances of inconsistencies and simplifies data management. This approach promotes a clear and organized structure, making code understanding and maintenance more straightforward.

Managing Complexity

In complex projects, manually handling server states can become a challenge. Utilizing tools like Redux or React's Context API helps simplify this management. These libraries provide a structured way to organize states, facilitating their management and manipulation.

State Preservation

Once received, server states must be efficiently preserved to ensure a consistent user experience. This may involve caching strategies or local state preservation techniques, thereby reducing the continuous dependency on the server for static data.

UI Reactivity

Thanks to server states, the user interface can dynamically react to changes in the server-side state. For example, a real-time chat could instantly update messages without requiring a page reload, thereby enhancing the overall user experience.

Reducing Network Traffic

By maintaining a centralized server state, network traffic can be reduced. Instead of constantly requesting data from the server, the application can optimize requests, reducing loading times and improving overall performance.

In summary, fully understanding and leveraging the role of server states in a React app is crucial for the development of modern and high-performance applications. In the upcoming chapters, we will explore in-depth how to recognize, manage, and address issues arising from poorly managed server states.

How to Recognize a Server State

Alright, now that we have a good overview of what server states are, it's time to learn how to recognize them when you encounter them in the wild world of React. Don't worry, they're not invisible, just a bit elusive.

HTTP Request

One of the most obvious ways to understand that you're dealing with a server state is the good old HTTP smoke signal. When you send requests to the server and receive responses, you're looking at server state traffic. It's like the server sending you a message saying, "Hey, I've got something for you!"

State Manipulation in Effects

Whenever you see a useEffect manipulating data reactively, you're probably playing with a server state. It's like React telling you, "Hold on, I need to sync up with the server."

Outdated States

If you have to update data because it became outdated after a user's change, well, maybe that data is coming from a server.

In essence, recognizing a server state is a bit like learning to read tracks in the desert. There are signs everywhere; you just need to know what to look for. Ready to follow the tracks of server states in your code? Let's track them down!

Problems Arising from Poor Management

Now that we've learned how to recognize server states, it's time to tackle the less glamorous part of the equation: what happens when things go wrong. Yes, because even server states can cause trouble, especially if they're not handled with the right dose of attention.

Data Inconsistency

Imagine your server state as a group of musicians playing together. If they're not synchronized, you'll have sonic chaos. Similarly, poor management of server states can lead to inconsistent data. One component thinks the state is one way, another thinks it's another, and you end up with a dissonant orchestra.

Uncontrolled Complexity

Server states can become monstrous if you don't keep an eye on them. Poor management can lead to uncontrollable complexity. Components start fighting against each other, and your application becomes an intricate jungle of logic hard to navigate.

Nightmare Debugging

You know those horror movies where the protagonist tries to escape something but can't because there are No escape routes? Well, imagine having to debug poor state management. It's a bit like being in that movie but without a flashlight.

Performance Impact

If you let server states get too comfortable, they can impact performance. Unnecessary requests, too frequent updates, and non-optimized data traffic can bog down your application. It's like driving a Ferrari with the brakes on.

UI Fragility

Poor management can make your user interface as fragile as glass. One state update, and your UI falls like a house of cards.

Resource Waste

If you don't manage server state well, you'll end up sending unnecessary requests, storing superfluous data, and overall wasting resources. It's like throwing money out the window.

In short, poor management of server states can lead to a series of problems that no developer wants to face. But that's where we come in. In the next sections, we'll see how to avoid these troubles and make server states work in our favor. Ready to fix those glitches? Let's dive in.

Management and Updating of Server States

To effectively handle Server State over time, various React libraries have emerged, excelling in fetching, caching, and accessing server-side application state fragments.

In this article, I'll show you how TanStack Query (formerly React Query) can come to our rescue (logically, you can use any alternatives you prefer).

Think of TanStack Query as your personal assistant for managing server states. It simplifies fetching data from the server, keeps it in sync with your local state, and frees you from the headaches of typical HTTP requests.

Let's see how we use it in action, focusing on the use of the useQuery hook and the creation of a custom hook to handle data fetching.

Installation of TanStack Query:

First and foremost, make sure you have TanStack Query installed in your project:

npm i @tanstack/react-query

Now we can use the useQuery hook

import { useQuery } from '@tanstack/react-query';

const fetchData = async () => {
  const response = await fetch('/api/data');   if (!response.ok) {
    throw new Error('Errore nel recupero dei dati');
  }
  return response.json();
};

function App() {
  const { data, error, isLoading } = useQuery('myData', fetchData);

  if (isLoading) {
    return <p>Loading...</p>;
  }

  if (error) {
    return <p>Error: {error.message}</p>;
  }

  // Now 'data' contain server data.
  return <div>{JSON.stringify(data)}</div>;
}

In this example, useQuery intelligently handles data fetching from the server. If the data is loading, it will display a loading message. If there are errors, it will show an error message. Otherwise, you'll have access to the updated data.

Now, let's see how to build a custom hook that allows us to "recycle" our fetching logic in an optimal way.

import { useQuery } from '@tanstack/react-query';

const useDataFetching = () => {
  const { data, error, isLoading } = useQuery('myData', fetchData);

  return {
    data,
    error,
    isLoading,
  };
};

function App() {
  const { data, error, isLoading } = useDataFetching();

  if (isLoading) {
    return <p>Caricamento...</p>;
  }

  if (error) {
    return <p>Errore: {error.message}</p>;
  }

  return <div>I dati dal server sono: {JSON.stringify(data)}</div>;
}

With the custom hook useDataFetching, you have a more modular structure. You can reuse it in different parts of your application to handle fetching.

Let'use the Cache

TanStack Query shines when it comes to cache management too. It uses an intelligent caching system that efficiently stores data, reducing the need for repeated server requests. Let's see how this cache magic works.

Automatic Cache

By default, TanStack Query automatically saves the results of queries in a local cache. When you request the same data later on, TanStack Query will return the locally stored data instead of making a new request to the server. This not only improves performance but also reduces the load on the server.

Configurable Cache Policies

You can configure cache policies based on your specific needs. For example, you can set the cache to automatically invalidate data after a certain period or after a change in server-side data. TanStack Query gives you control to adapt the cache to the dynamics of your application.

const { data, error, isLoading } = useQuery('myData', fetchData, {
  cacheTime: 60000, // Invalid after 60 seconds
});

Custom Cache Keys

You can also use custom cache keys to store and retrieve specific data. This is useful when you need to manually manipulate the cache or when working with dynamic data.

useQuery(['myData', { id: 1 }], fetchData);

In this example, the cache key becomes ['myData', { id: 1 }], and you can access the data using this custom key.

Cache Clearing

TanStack Query also provides methods to manually clear or invalidate the cache. For instance, you can call queryClient.invalidateQueries('myData') to force a new request when needed.

import { useQueryClient } from '@tanstack/react-query';

function ClearCacheButton() {
  const queryClient = useQueryClient();

  const handleClick = () => {
    queryClient.invalidateQueries('myData');
  };

  return <button onClick={handleClick}>Invalidate Cache</button>;
}

In this way, you have total control over the cache and can tailor it to the specific needs of your application. Tanstack Query makes cache management a smooth and customizable experience. Ready to cache in on this knowledge?

Conclusions

And with that, we conclude our journey through the intriguing world of server states in React. Now you're armed with knowledge to tackle challenges, manage complexities, and build reactive applications.

You've learned to recognize server states, use Tanstack Query as your trusted ally, and avoid the pitfalls of poor management. Now it's your turn, developer!

If you have questions, concerns, or stories to share about server state management, leave a comment below. The community is here to help and share experiences.

If you found this article helpful, share it with your fellow developers or on social media. Sharing is the key to growing our community and spreading knowledge.

React Advanced: Decoupling your components in the right way

Riccardo Tartaglia — Sun, 24 Sep 2023 16:44:56 +0000

Every developer's dream is to write less code and, if possible, make it all reusable.

In React, this translates into knowing how to properly decouple the logic of a component from its presentation.

Easier said than done, right?

In this article, I'll show you how to effectively decouple your components to make your code extremely reusable.
Before we get started, let's take a look at the fundamental concept of "coupling."

Coupling

In computer science, coupling is a concept that denotes the dependence between two or more components. For instance, if a component A depends on another component B, then A is said to be coupled with B.

Coupling is the enemy of change because it ties together things that can change in parallel.

This makes it extremely challenging to modify a single point in your application. Touching a single component can introduce anomalies in various parts of the application.

You must spend time tracking down all the parts that need to be modified, or you'll find yourself wondering why everything has gone haywire.

If we view a React component as a pure presentation element, we can say that it can be coupled with many things:

Business logic that determines its behavior (hooks, custom hooks, etc.).
External services (APIs, databases, etc.).
Another React component (for example, a component responsible for managing the state of a form).

This tight coupling, when modified, can lead to unpredictable side effects on other parts of the system.

Let's take a closer look at this component.

import { useCustomerHook } from './hooks';

const Customer = () => {
  const { name, surname } = useCustomerHook();
  return (
    <div>
      <p>{name}</p>
      <p>{surname}</p>
    </div>
  );
};

It all seems fine at first glance, but in reality, we have a problem: this component is coupled with the custom hook useCustomerHook, which retrieves customer data from an external service. Therefore, our Customer component is not a "pure" component because it depends on logic that is not solely related to presenting its UI.

Now, let's consider that the custom hook useCustomerHook is also used in other components. What can we expect if we decide to modify it? Well, we should brace ourselves for quite a bit of work because we'll have to modify all the components that use it and are coupled with it.

Decoupling the Logic of a React Component

Let's revisit the previous example. I mentioned that the Customer component is coupled with the custom hook useCustomerHook, which applies fetching logic to retrieve customer data.

Now, let's explore how to decouple the logic of this component, so that we can transform it into a pure presentation component.

import { useCustomerHook } from './hooks';

const Customer = ({name, surname}) => {
  return (
    <div>
      <p>{name}</p>
      <p>{surname}</p>
    </div>
  );
};

const CustomerWrapper = () => {
  const { name, surname } = useCustomerHook();
  return <Customer name={name} surname={surname} />;
};

export default CustomerWrapper;

Now, the Customer component is indeed a pure presentation component because it no longer uses useCustomerHook and only handles UI logic.

I've employed a wrapper component to decouple the logic of the Customer component. This technique is known as Container Components and allows us to modify the UI of our component without worrying about "breaking" the underlying logic.

Customer now only needs to concern itself with displaying presentation information. All the necessary variables are passed as props, making it easy to nest it anywhere in our code without concerns.
However, I'm still not satisfied for two reasons:

The CustomerWrapper component is still coupled with the custom hook. So, if I decide to modify it, I would still need to modify the wrapper component.
I had to create an extra component, CustomerWrapper, to decouple the logic, which means I've written a bit more code. We can address these two issues by using composition.

Composition

In computer science, composition is a concept that refers to combining two or more elements to create a new one. For example, if we have two functions f and g, we can compose them to create a new function h, which is the composition of f and g.

const f = (x) => x + 1;
const g = (x) => x * 2;
const h = (x) => f(g(x));

We can apply the same concept to custom hooks as well. In fact, we can compose two or more custom hooks to create a new one.

const useCustomerHook = () => {
  const { name, surname } = useCustomer();
  const { age } = useCustomerAge();
  return { name, surname, age };
};

In this way, the custom hook useCustomerHook is composed of the custom hooks useCustomer and useCustomerAge.

By using composition, we can decouple the logic of a React component without having to create a wrapper component. To apply composition conveniently, we use the library react-hooks-compose

Let's see how we can apply composition to our example.

import composeHooks from 'react-hooks-compose';
import { useCustomerHook } from './hooks';

const Customer = ({name, surname}) => {
  return (
    <div>
      <p>{name}</p>
      <p>{surname}</p>
    </div>
  );
};

export default composeHooks({useCustomerHook})(Customer);

Now, the Customer component is indeed a pure presentation component. It's not coupled with any custom hooks and only handles UI logic. Furthermore, you didn't have to create any additional components to decouple the logic. In fact, composition allows you to create a cleaner and more readable component.

Another strength of this technique lies in how easy it makes testing the Customer component. You don't need to worry about testing the business logic; you only need to test the UI logic. Additionally, you can test the custom hooks separately.

As a final highlight, let's see what happens if you decide to add a new custom hook that adds some logic to the Customer component, such as a custom hook that handles logging customer information.

import composeHooks from 'react-hooks-compose';
import { useCustomerHook, useLoggerHook } from './hooks';

const Customer = ({name, surname, age}) => {
  return (
    <div>
      <p>{name}</p>
      <p>{surname}</p>
    </div>
  );
};

export default composeHooks({
  useCustomerHook,
  useLoggerHook
})(Customer);

Perfect, you've added the custom hook useLoggerHook to the Customer component without having to modify the component itself.

This is because useLoggerHook was composed with the useCustomerHook.

Conclusions

In this article, we've explored how to decouple the logic of a React component through hook composition, turning it into a pure presentation component. The art of hook composition provides us with a powerful tool to enhance the modularity and maintainability of our React components.

By clearly separating business logic from presentation, we make our components more readable and easier to test. This methodology promotes code reusability and the scalability of React applications, allowing developers to focus on creating cleaner and more performant components.

If you have any suggestions or questions on this topic, please feel free to share them in the comments below. And if you found this article helpful, don't forget to share it with your fellow developers!

Uncino 🪝 Fast, tiny and solid hooks system for Javascript and NodeJS

Riccardo Tartaglia — Wed, 31 Aug 2022 10:48:34 +0000

Uncino is italian word for hook

See on Github

Do you know Wordpress hooks system? Uncino is a hooks system highly inspired to it!

Async / Await support
Node or Browser support
Actions / Hooks system
Easy to use
No Dependencies

Philosophy

Uncino permit to your code to interact/modify another piece of code at specific, pre-defined spots.

Uncino has two types of hooks: Actions and Hooks. To use either, you need to write a custom function, and then register for a specific action or hook.

Actions allow you to add data or change how your code operates. Actions will run at a specific point in the execution. Callback functions for Actions can perform some kind of a task, like echoing output to the user or inserting something into the database. Callback functions for an Action do not return anything back to the calling Action hook.

Hooks give you the ability to change data during the execution of your code. Callback functions for Filters will accept a variable, modify it, and return it. They are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. Filters expect to have something returned back to them.

With Uncino you can create your own hook spots so that other developers can extend and modify your code or you can create your pluggable core.

Pull Requests?

I'd love them!

Comments?

Let's hear them! (The nice ones please!)

Me?

In case you're interested I'm @riktarweb

React Holmes 🔍 - Elementary State Orchestrator for React

Riccardo Tartaglia — Fri, 27 May 2022 09:26:50 +0000

React Holmes is a 0 config, fast and elementary state orchestrator for React.

Holmes has a very minimal API. It is as simple to use as React’s integrated hooks, but all state is globally accessible.

💡 Easy as React state hooks

🔄 State synchronization between components

🛰️ Distributed and not centralized state

🤯 No mutable objects

🚀 Fast

React Holmes on Github

Motivation

React components has a built-in state object, where you store property values that belongs to the component.

When the state object changes, the component re-renders.

This behaviour has certain limitations:

Component state can only be shared by pushing it up to the common ancestor, but this might include a huge tree that then needs to re-render.
React-Holmes adopts a new vision when talking about state handling.

As other state managers use an external single source of truth to hydrate app client on state change, React-Holmes does not create an external store and does not need to wrap your app in a context.

So, where is the global state?
There is no global state, actually.
The state is decentralized into components themselves.

The ONLY differences are the hook declared for state management and a key to identify state chunk.

While to declare a React state we need to declare it as:

const [state, setState] = React.useState('test');

with React-Holmes we need to declare it as:

const [state, setState] = useHolmesState('key', 'test');

What does useHolmesState do?
When a state is set with useHolmesState, the hook is responsible to set state with React and add some power ups to it.

In fact, when a component using useHolmesState is mounted, it will create (if not exists) a new RxJs Observable identified by specified key.

If we register another component with the same key, it will not create another Observable, instead it will subscribe to existing one, allowing access to its value and its callback to mutate the state.

This allows state handling to be delegated to React itself, guaranteeing reactish updates and shared state too.

So React-Holmes can be considered a React state orchestrator because its hooks can be used into very small and deeply nested components without performance impacts generated by multiple re-renders.

React Holmes on Github

Blur Animation: CSS Transition

Riccardo Tartaglia — Wed, 29 Dec 2021 11:42:23 +0000

Little experiment for create a blur movement effect using CSS animation.

New Skeleton component in windy - React UI Kit based on Tailwind

Riccardo Tartaglia — Wed, 14 Jul 2021 15:18:03 +0000

Hi there, new update from windy - React UI Kit based on Tailwind!

We have added a new Skeleton component in Windy (https://windy-docs.vercel.app)

Let's use it in 5 lines of code!

<div className="w-full">
  <Skeleton className="w-3/4 mb-3" />
  <Skeleton className="mb-3" />
  <Skeleton className="w-1/2" />
</div>

you can see other example in https://windy-docs.vercel.app/docs/components/skeleton

I'm working hard to improve windy so every feedback is important. 👨‍💻 Let's try it and let me know 🔥🙏