DEV Community: Rayen Mabrouk

Why We Ditched Node for Bun in 2026 (And Why You Should Too)

Rayen Mabrouk — Thu, 08 Jan 2026 16:00:00 +0000

For years the JavaScript ecosystem felt like a settled landscape, Node was the undisputed king, Deno was the academic alternative, and "speed" was something we just accepted as "fast enough"

But as we hit 2026, the baseline has shifted. We recently completed a full migration from Node to Bun for our all our repos. What started as an experiment ended as a permanent shift in our engineering culture.

Here is why we made the leap and why 2026 is the year you should leave node_modules headaches behind.

1. The Death of the Toolchain Sprawl

In the Node world, starting a project meant an immediate tax of configuration. You needed npm for packages, tsc for TypeScript, jest or vitest for testing, and webpack or esbuild for bundling.

Bun is a single binary that does all of it.
By switching to Bun, we deleted hundreds of lines of configuration files.

Native TypeScript: We no longer use ts-node or tsx. Bun runs .ts files out of the box.
Unified Tooling: bun test is up to 20x faster than Jest and built-in. No more waiting 30 seconds for a test suite to initialize.

2. ElysiaJS: The Bun Backend Framework

The biggest catalyst for our migration was choosing ElysiaJS as our main backend framework.

Elysia is a Bun-first framework designed specifically to leverage Bun's low-level performance. Since it’s optimized for the JavaScriptCore engine, the throughput is staggering.

End-to-End Type Safety: With Elysia and Bun, types flow from the server to the client (via Eden Treaty) automatically. No more manual type synchronization!!

The Speed Gap: In our benchmarks, Elysia on Bun handled over 250,000 requests/sec, making our old Express/Node services look like they were running in slow motion.

Zero Overhead: Because Elysia is built on Web Standard APIs (Fetch, Request, Response), there is zero "framework tax."

"With Bun + Elysia, we finally reached the 'Single Binary' dream. Our backend is now just one tool that handles everything from the database driver to the HTTP server."

3. Performance That Actually Saves Money

Benchmarks are one thing; cloud bills are another..
In 2026, with the rise of edge computing and serverless architectures, startup time is currency.

Metric	Node.js (v23+)	Bun (v1.3+)
Cold Startup	~150ms	~40ms
HTTP Requests/sec	~90k	~125k
Idle Memory	~95MB	~65MB

By switching our serverless functions to Bun, we reduced our execution duration by 35%, directly lowering our AWS Lambda costs. Bun’s use of the JavaScriptCore (JSC) engine—the same tech powering Safari—prioritizes rapid start times over the heavy JIT (Just-In-Time) optimization overhead of Node's V8.

4. "Bun Install" is the New Standard

If you’ve ever waited 2 minutes for npm install, yarn install, or even pnpm install to finish on a CI/CD pipeline, you know the pain. Bun’s package manager is roughly 20x to 40x faster than npm. It uses a binary lockfile (bun.lockb) and global caching that makes dependency installation feel instantaneous.

This is the real deal, the speed diff is no joke here

For our team, this meant our CI/CD pipelines went from 30-minute builds to under 5 minutes for our big monorepos.

5. The 2026 Reality: Compatibility is No Longer an Issue

The biggest argument against Bun in 2024 was "it doesn't support all npm packages." By 2026, that argument is dead. Bun now supports >95% of Node APIs, including complex native modules like buffer, fs, and path.

Following its acquisition by Anthropic, Bun has reached a level of enterprise stability we hadn't seen before. It’s no longer just for "side projects"; it’s powering production-grade AI agents and high-concurrency APIs globally.

How to Start Your Migration

You don't have to rewrite your whole app overnight. Start where we did:

Swap your Package Manager: Run bun install in your Node project. It’s a drop-in replacement.
Run your Tests: Try bun test. You'll see the speed difference immediately.
Migrate Scripts: Change node index.js to bun index.ts in your package.json.

My Personal Thoughts..

Node isn't "bad" but in 2026 it feels like using a heavy manual typewriter in a world of high-speed digital keyboards..
Bun offers the performance, the developer experience, and the cost-savings that modern full-stack development demands.

For the geeks reading this who want to see the cold, hard numbers:

Node vs Deno vs Bun: Performance & JavaScript runtime comparison

This video provides a deep dive into 2026 performance benchmarks to help you visualize the raw speed differences between these runtimes.

Nx Architecture Guide

Rayen Mabrouk — Wed, 10 Sep 2025 15:54:05 +0000

Purpose & Principles

Goal: Build a scalable, maintainable monorepo for TypeScript, React, Elysia.js ( or NestJS) — optimized for speed and clarity as the team and codebase grow.

Guiding principles:

Single source of truth for shared code → packages live in /packages.
Apps are independent, only depend on packages.
Strict boundaries enforced by Nx rules to prevent spaghetti dependencies.
Smart automation → generate, lint, build, and test only what changed.
Developer happiness → fast feedback, consistent tooling, minimal cognitive overhead.

Why This Matters

When multiple teams and apps share a codebase, things can spiral out of control quickly:

Apps start depending on each other → deployment coupling and hidden breakage.
Shared logic gets duplicated or inconsistently implemented.
Build times explode as the repo grows.
Onboarding new developers becomes painful — they don’t know where code should live or what’s safe to change.

By following this structure:

Independent apps
- You can deploy, test, and scale each app without worrying about others.
- Example: Your LMS web app doesn’t break if someone changes the e-commerce backend.
Single source of truth in /packages
- Shared utilities, models, contracts, and UI components live in one place.
- No code duplication → no “bug fixed here but missed there”.
Fast pipelines with Nx caching
- Nx knows exactly which code depends on what → it only rebuilds and tests the minimal set of affected projects.
- This keeps CI and local dev blazing fast.

Problems This Solves

Problem	How This Doc Solves It
Apps depend directly on each other	Strict rule: Apps can only depend on packages, never other apps.
Code duplication across apps	Centralize shared code in `/packages`.
Confusing folder structures	Clear, predictable conventions for folder layout and naming.
Slow builds & tests	Nx affected graph + smart caching = only run what changed.
Fragile FE/BE type syncing	Shared `contracts` package with Zod → FE/BE stay type-safe.
Env chaos	Clear rules for `.env` handling and config packages.
New dev onboarding takes weeks	Generators, clear docs, and tags → consistent, fast ramp-up.

Workspace Layout

apps/                  # Standalone deployable apps
 web/                 # React frontend (Next.js or Vite)
 admin/               # Admin dashboard
 marketing/           # Public marketing site
 mobile/              # React Native app
 api-nest/            # NestJS backend service
 api-scheduler/       # Background jobs service

packages/              # Reusable code (FE & BE)
 shared/
  util/              # Pure utility functions
  models/            # Shared TypeScript models
  contracts/         # Zod schemas + API contracts
lms/                 # LMS domain
 feature/           # State orchestration / hooks
 ui/                # UI components
 data-access/       # API clients or DB repositories 
 util/              # LMS-specific helpers
ecommerce/           # E-commerce domain
 feature/
 ui/
 data-access/
 util/
tools/                 # Custom Nx generators + scripts

Core Rules

1 — Apps are Standalone

Apps live in /apps/.
They cannot import anything from another app.
They only import from /packages.
This ensures clean deployment boundaries and eliminates hidden coupling.

Example (✅ Allowed):

apps/web → imports → packages/lms-ui
apps/web → imports → packages/shared-contracts

Example (❌ Forbidden):

apps/web → imports → apps/admin
apps/admin → imports → apps/api-nest

2 — Packages Are the Source of Truth

All shared code lives in /packages/.
apps/ are thin shells that glue together packages and runtime configuration.

Naming, Tags & Boundaries

Package Naming

Format: <scope>-<type>

scope = domain (lms, ecommerce, shared)
type ∈ (feature, ui, data-access, util, models, contracts)

Examples:

lms-ui, lms-data-access, shared-contracts.

Enforcing Boundaries with Nx

// root .eslintrc.js
rules: {
  "@nx/enforce-module-boundaries": [
    "error",
    {
      enforceBuildableLibDependency: true,
      allow: [],
      depConstraints: [
        { "sourceTag": "type:app", "onlyDependOnLibsWithTags": ["type:package"] },
        { "sourceTag": "type:ui", "onlyDependOnLibsWithTags": ["type:util","type:models","type:contracts","scope:shared","scope:<same>"] },
        { "sourceTag": "scope:shared", "onlyDependOnLibsWithTags": ["scope:shared"] }
      ]
    }
  ]
}

Contracts & FE/BE Sync

// packages/shared/contracts/course.ts
import { z } from "zod";

export const Course = z.object({
  id: z.string().uuid(),
  title: z.string(),
  published: z.boolean(),
});

export type Course = z.infer<typeof Course>;

Frontend: use these schemas to type API clients and validate responses.
Backend (Nest or Elysia): use schemas for input/output validation.

Environment & Config Rules

Apps own their .env files.
Packages must never read directly from process.env.
Create a config package that:
- Reads env variables at runtime.
- Validates them with Zod.
- Exports a strongly-typed config object.

Caching, Targets & Bun

1 — Default Targets (`nx.json`)

{
  "targetDefaults": {
    "build": { "cache": true },
    "test": { "cache": true },
    "lint": { "cache": true },
    "typecheck": { "cache": true }
  }
}

2 — Bun Commands

bun i                # Install dependencies
bun run nx serve web # Run a frontend app
bun run nx serve api-nest # Run backend
bun run nx affected -t lint,typecheck,test,build

Affected Workflow

Local Dev:

  bun run nx affected:graph

Before Commit:

  bun run nx affected -t lint,test,typecheck

  - run: bun run nx affected -t lint,typecheck,test,build --parallel

Testing Strategy

Unit tests → close to source in __tests__.
Component tests → React Testing Library.
E2E tests → Playwright for apps.
Contract tests → Validate BE against Zod contracts.

Performance & DX Tips

Use barrel files (index.ts) to curate package exports.
Keep packages small and domain-focused.
Turn packages that need Node consumption into buildable: true.
Use tsup or esbuild for tiny backend bundles.

Why Nx Over Competitors

Feature	Nx	Turborepo	Lerna
Dependency graph	✅ Auto	❌ Manual	❌ None
Task scheduling & caching	✅ Smart (local + remote)	⚠️ Limited	❌
Built-in generators	✅ Yes	❌ No	❌
Enforceable boundaries	✅ Yes	❌ No	❌
Polyglot support (React, Elysia, Nest)	✅ Excellent	⚠️ Limited	❌
Remote caching (team-wide)	✅ Built-in	⚠️ Third-party	❌

Quick Commands Cheat Sheet

bun run nx g @nx/js:lib lms-ui --directory=lms --tags="scope:lms,type:ui,platform:browser"
bun run nx graph
bun run nx affected -t test
bun run nx serve web

Final Thoughts

By enforcing these practices:

Each app remains deployable and testable on its own.
Shared logic lives in packages, not copied between apps.
Nx automatically keeps builds and tests fast even as the codebase grows.
The team has clear rules, reducing onboarding friction and bugs.

Why We Ditched Drizzle & Knex in favor of Kysely's Querybuilder

Rayen Mabrouk — Sat, 05 Apr 2025 07:46:17 +0000

Building scalable applications often hinges on precise database interactions. While ORMs promise rapid development, they can obscure SQL and become bottlenecks as complexity grows. Even popular query builders like Knex and Drizzle present challenges. After navigating various projects, we found Kysely offered the best balance of control, maintainability, and crucially, end-to-end type safety.

The Challenge: Balancing Abstraction and Control (The Pitfalls of Traditional ORMs)

1. The Illusion of Simplicity: Hidden Complexity

ORMs abstract away SQL generation, which can be useful for simple operations. However, this abstraction conceals real database interactions, making it difficult to optimize queries or troubleshoot performance issues. Debugging queries often requires reverse engineering ORM-generated SQL, adding unnecessary complexity,
this is very crucial when working with large scale complex apps that often require complex query logic.

2. Limited Customization

Many ORMs enforce strict patterns and conventions. When query requirements deviate from standard use cases whether for performance optimizations or non standard joins ORM constraints become a bottleneck. Developers often resort to workarounds, leading to convoluted, less maintainable code..

3. The Spaghetti Code Scenario: Complex Queries in ORM Syntax

For simple CRUD operations, ORM syntax is manageable. However, for queries involving multiple joins, subqueries, or aggregations, ORM APIs become cumbersome and difficult to follow. This not only makes debugging more challenging but also increases the risk of subtle errors, especially in production-grade systems, a nightmare to work with for new devs joining to project.

Type Safety: A Crucial Distinction

A system is either type-safe or it isn't—there is no in-between. Partial type safety slows development by introducing misleading assurances that a query is correct when, in reality, it's not. A truly type-safe query builder should catch errors at compile time rather than runtime, preventing incorrect table references and typos.

Drizzle, for example, gives the impression of type safety, but only applies type validation to query results not the queries themselves. This means you can still write invalid queries, much like with Knex.

Kysely, however, aims for stricter, end-to-end type safety. Its typings are designed to understand the query's structure, including aliases and subqueries, making it much harder to formulate logically incorrect joins or references that would only fail at runtime.

Kysely vs. Knex vs. Drizzle: A Practical Comparison

To illustrate how Kysely improves query safety and maintainability, let's examine a real world SQL query involving subqueries and joins. The goal is to fetch a list of books along with the name of the last lender for each book.

SQL Query Representation

SELECT
  "books"."name",
  "u"."name" AS "username"
FROM
  "books"
  LEFT JOIN (
    SELECT
      MAX("id") AS "last_lending_id",
      "lendings"."book_id"
    FROM
      "lendings"
    GROUP BY
      "book_id"
  ) AS "l" ON "l"."book_id" = "books"."id"
  INNER JOIN "lendings" AS "l1" ON "l1"."id" = "l"."last_lending_id"
  INNER JOIN "users" AS "u" ON "u"."id" = "l1"."user_id";

Knex Implementation: SQL-Like but Error-Prone

Knex provides a SQL-like API but lacks type safety, making it prone to runtime errors due to typos or incorrect references.

knex("books")
  .select("books.name", "u.name as username")
  .leftJoin(
    (query) => {
      query
        .max("id as last_lending_id")
        .select("lendings.book_id")
        .from("lendings")
        .groupBy("book_id")
        .as("l");
    },
    function () {
      this.on("l.book_id", "books.id");
    }
  )
  .innerJoin("lendings as l1", "l1.id", "l.last_lending_id")
  .innerJoin("users as u", "u.id", "l1.user_id");

While the syntax is intuitive for SQL users, Knex does not provide static type validation. Mistakes such as referencing l.book_id incorrectly will only be caught at runtime.

Drizzle Implementation: Improved Readability but Partial Type Safety

Drizzle attempts to balance SQL-style query building with type safety but falls short in enforcing correctness during query construction.

const l = db
  .select({
    book_id: schema.lendings.book_id,
    last_lending_id: max(schema.lendings.id).as('last_lending_id'),
  })
  .from(schema.lendings)
  .groupBy(schema.lendings.book_id).as('l');

const l1 = aliasedTable(schema.lendings, 'l1');
const u = aliasedTable(schema.users, 'u');

db
  .select({
    name: schema.books.name,
    username: u.name,
  })
  .from(schema.books)
  .leftJoin(l, eq(l.book_id, schema.books.id))
  .innerJoin(l1, eq(l1.id, l.last_lending_id))
  .innerJoin(u, eq(u.id, l1.user_id))
  .execute();

Drizzle improves readability and provides type safety for results and basic query elements. However, notice how aliases (l, l1, u) are defined. While Drizzle types the result correctly, it doesn't inherently prevent runtime errors if you mistakenly used schema.lendings.id instead of l.last_lending_id in the later joins within the query construction. The types guide you, but the logical connection isn't always enforced at compile time in these complex cases.

Kysely Implementation: Fully Type-Safe and SQL-Like

Kysely enforces strict type safety across the entire query-building process, preventing incorrect joins and typos at compile time.

db
  .selectFrom("books")
  .leftJoin(
    (eb) =>
      eb
        .selectFrom("lendings")
        .select((sl) => [
          sl.fn.max("id").as("last_lending_id"),
          "lendings.book_id",
        ])
        .groupBy("book_id")
        .as("l"),
    (join) => join.onRef("l.book_id", "=", "books.id")
  )
  .innerJoin("lendings as l1", "l1.id", "l.last_lending_id")
  .innerJoin("users as u", "u.id", "l1.user_id")
  .select(["books.name", "u.name as username"]);

Kysely's strict typing shines here. The use of functions like (eb) => eb.selectFrom(...) and (join) => join.onRef(...) allows Kysely's types to track the available tables and columns within the current scope, including aliases from subqueries (l). Referencing l.book_id is type-checked against the subquery's output. Attempting to reference an invalid column or alias here would result in a compile-time TypeScript error, preventing runtime failures.

Unlike Knex and Drizzle, Kysely ensures that every part of the query is type-checked, preventing errors before execution. Additionally, its API remains readable while enforcing correctness.

Key Takeaways: Why Kysely Stands Out

Strict Type Safety: Kysely prevents incorrect table references, column names, and joins at compile time, eliminating common runtime errors.
SQL-Like Query Construction: While different from traditional SQL in ordering, Kysely's API ensures logical query composition.
Dynamic Yet Maintainable: Kysely's API maps closely to SQL concepts while ensuring logical query construction.
Avoids the Pitfalls of ORMs: Unlike ORMs, Kysely doesn’t obscure SQL execution, giving developers full control over performance optimizations.

Conclusion: Embrace Type-Safe Query Building

While Knex offers flexibility and Drizzle provides a good step towards type safety, both can still allow subtle bugs in complex queries to reach runtime.
Drizzle improves upon Knex by adding type safety to query results but falls short in enforcing correctness during query construction.

Kysely, on the other hand, achieves full end-to-end type safety while maintaining a SQL-like, flexible API. If your system demands precise control over database interactions and robust type validation, Kysely provides the clarity and safety needed for scalable, high-performance applications.

For us, adopting Kysely was a game changer, and for anything beyond simple prototypes, it's now our go-to choice.

What are your experiences with these query builders? Share your thoughts in the comments!

Why NestJS Is The New Gold Standard For Node Backend Development

Rayen Mabrouk — Tue, 14 Jan 2025 12:06:00 +0000

As a Node.js developer who has tried every Node framework under the sun, here’s why I believe NestJS must be the new gold standard for Node.js backend development. At first, the framework seemed like too much—the learning curve was steep, and I found it hard to understand coming from Express. Why all this complexity? But with time, I came to admire every aspect of this framework.

1. Why OOP is the Best for Backend Development

Object-Oriented Programming (OOP) is not just a paradigm; it's a methodology that addresses the core challenges of backend development. At its heart, OOP allows you to model real-world problems in a way that makes systems easier to design, implement, and maintain. NestJS utilizes OOP through its class-based approach, enabling you to organize logic into cohesive, reusable components.

For instance, consider the concept of services in NestJS. A service class encapsulates business logic, promoting separation of concerns. This encapsulation not only makes your codebase easier to navigate but also simplifies testing. Using decorators like @Injectable(), NestJS takes dependency injection a step further, allowing seamless integration of service dependencies without manual wiring.

Code Example

import { Injectable } from '@nestjs/common';

@Injectable()
export class UserService {
  private users = [];

  createUser(name: string) {
    const user = { id: Date.now(), name };
    this.users.push(user);
    return user;
  }

  getUsers() {
    return this.users;
  }
}

Moreover, inheritance in OOP allows developers to extend and reuse functionality without duplicating code. Polymorphism, another cornerstone of OOP, lets you define common interfaces for varying implementations. In a NestJS context, this could be seen in abstract classes for database repositories, where specific implementations handle details for MongoDB, PostgreSQL, or other data stores.

So as your codebase grows larger, you can maintain a well-structured codebase within every module.

2. NestJS is Future-Proof

NestJS positions itself as a framework built to withstand the test of time. Its adoption of TypeScript ensures that your code is reliable and maintainable.

NestJS also uses decorators extensively, aligning with modern JavaScript standards such as ES6+ and ECMAScript proposals. These decorators, like @Controller(), @Get(), and @Post(), provide declarative syntax that makes code intuitive and reduces boilerplate.

Code Example

import { Controller, Get } from '@nestjs/common';

@Controller('users')
export class UserController {
  @Get()
  findAll() {
    return 'This action returns all users';
  }
}

3. Ideal for Microservices and Enterprise Applications

NestJS shines in environments where modularity and scalability are non-negotiable. For microservices, NestJS provides native support for distributed systems using patterns like message brokers and event-driven communication. The framework includes modules for integration with RabbitMQ, Kafka, and Redis, making it easy to design resilient and decoupled systems.

Code Example

import { Controller } from '@nestjs/common';
import { MessagePattern } from '@nestjs/microservices';

@Controller()
export class AppController {
  @MessagePattern('notifications')
  handleNotification(data: any) {
    console.log('Received notification:', data);
  }
}

For enterprise-grade applications, NestJS's modular architecture allows teams to work on isolated modules without stepping on each other’s toes. Features like DynamicModule allow you to configure modules dynamically, simplifying the management of multi-tenant systems or applications with environment-specific configurations.

4. Built-in Support for Everything

NestJS eliminates the need for cobbling together third-party libraries by offering built-in support for a wide array of features. Need WebSocket support for real-time applications? NestJS provides an out-of-the-box module for that. Building a GraphQL API? NestJS's GraphQL module integrates seamlessly with decorators for schema-first or code-first approaches.

Code Example

Integrating JWT authentication using Passport.js:

import { Injectable } from '@nestjs/common';
import { PassportStrategy } from '@nestjs/passport';
import { Strategy, ExtractJwt } from 'passport-jwt';

@Injectable()
export class JwtStrategy extends PassportStrategy(Strategy) {
  constructor() {
    super({
      jwtFromRequest: ExtractJwt.fromAuthHeaderAsBearerToken(),
      secretOrKey: 'secretKey',
    });
  }

  validate(payload: any) {
    return { userId: payload.sub, username: payload.username };
  }
}

For authentication, the @nestjs/passport library integrates Passport.js directly into your project, providing strategies for OAuth, JWT, and local authentication. NestJS also simplifies database interaction with its @nestjs/typeorm and @nestjs/mongoose modules, providing tight integration with popular ORMs like TypeORM and Mongoose.

This all-inclusive approach reduces decision fatigue and ensures consistency across your application, allowing you to focus on solving business problems rather than configuring your stack.

5. Modular Architecture That Scales

NestJS’s modular system is a game-changer for large-scale applications. By encapsulating features into dedicated modules, it allows developers to maintain clean boundaries between different parts of the application. Each module in NestJS acts as a self-contained unit, bundling together controllers, services, and other components.

Code Example

Creating a user module:

import { Module } from '@nestjs/common';
import { UserController } from './user.controller';
import { UserService } from './user.service';

@Module({
  controllers: [UserController],
  providers: [UserService],
})
export class UserModule {}

The modular design allows you to separate concerns and easily scale your application by adding new modules.

NestJS also supports lazy loading of modules, a crucial feature for microservices or applications with large, complex dependencies. This ensures that your application starts faster and consumes fewer resources.

6. Very Hard to Mess Up in NestJS

NestJS offers guardrails that make it difficult to write bad code. Its opinionated structure enforces best practices, such as the separation of concerns, dependency injection, and modular design. The framework's CLI (@nestjs/cli) helps scaffold components with a consistent folder structure, eliminating the guesswork in organizing your codebase.

Code Example

Using guards for role-based access control:

import { Injectable, CanActivate, ExecutionContext } from '@nestjs/common';

@Injectable()
export class RolesGuard implements CanActivate {
  canActivate(context: ExecutionContext): boolean {
    const request = context.switchToHttp().getRequest();
    const user = request.user;
    return user && user.roles.includes('admin');
  }
}

Additionally, NestJS makes full use of TypeScript to catch errors during development, reducing runtime bugs. Features like guards (@CanActivate), interceptors (@Interceptor()), and pipes (@PipeTransform) provide clear patterns for handling concerns like validation, transformation, and access control. This layered approach ensures that even junior developers can contribute effectively while adhering to established conventions.

Even error handling is simplified. By extending the built-in HttpException, you can create custom exceptions with ease, ensuring your APIs remain consistent and predictable. NestJS takes care of the rest, including sending the appropriate HTTP response codes and error messages.

Final Thoughts

NestJS isn’t just another Node.js framework; it’s a paradigm shift in backend development. It’s an ideal choice, offering everything you need to succeed. From my experience, I believe this framework strikes the perfect balance between rapid delivery and long-term maintainability. It represents the ultimate evolution of Node.js backend development, setting a new standard for scalability and efficiency.
For more in-depth insights, check out the book Scalable Application Development with NestJS, available here.

The Ultimate Tech Stack for Startups in 2025

Rayen Mabrouk — Fri, 27 Dec 2024 23:33:44 +0000

As the tech landscape evolves, choosing the right tech stack is like picking the perfect recipe for success. At Evowave, we’ve crafted a tech stack that’s powerful, efficient, and delightful, enabling us to build fast, modern, and visually stunning applications. Let’s dive into the tools and technologies we’re using in 2025—and why we believe they’re startup gold.

Frontend: Next.js 14 with React Query and Context API

💻 NextJs 14 is our secret weapon for building web applications that are lightning-fast and user-friendly. Here’s why:

Server-side rendering (SSR) and static site generation (SSG) deliver outstanding performance.
Built-in app directory and routing make development efficient and streamlined.
Features like TurboPack and enhanced performance optimizations take the developer experience to the next level.
The framework is constantly updated, with exciting new features in the pipeline, especially in NextJs 15.

For state management and data fetching, we rely on React Query and Context API. Here's where the magic happens:

React Query is a powerhouse for remote state management, simplifying data synchronization, caching, and background updates. It’s packed with advanced features that make complex data flows effortless.
Context API is our lightweight solution for sharing state across components. Paired with custom hooks, it’s simple, yet powerful—perfect for most commercial websites. 💡 This dream team lets us prefetch data like pros, ensuring seamless, fast, and highly responsive user experiences.

Backend: Supabase and NestJS

⚡ When it comes to the backend, we tailor our approach to the project’s needs, alternating between Supabase and NestJS:

Supabase Think of it as the ultimate backend-as-a-service solution. It offers real-time subscriptions, PostgreSQL database hosting, and built-in authentication. Combined with Next.js, it’s an unbeatable combo that speeds up development like nothing else. Plus, the paid tier provides exceptional value for the features it offers.
NestJS For larger, more complex projects, NestJS is our go-to framework for organization and scalability, built to support enterprise-grade applications with TypeScript. If you want a backend that scales with your app, NestJS is the perfect choice.

Together, these tools give us unmatched flexibility and power, allowing us to build whatever our projects demand, all while maintaining quality and performance.

UI Framework: shadcn/UI

🎨 For creating visually stunning and accessible interfaces, we swear by Shadcn/UI:

Packed with customizable components built on Tailwind CSS.
Simplifies maintaining a cohesive design system.
Easy to customize, intuitive to use, and a joy for developers.

The result? User interfaces that are not only beautiful but also incredibly functional!

Why This Stack Works for Startups

🚀 This stack has been a game-changer for us because:

It Balances Speed and Quality: Tools like Supabase and shadcn/UI reduce boilerplate code, allowing us to focus on building quality features without compromising on performance.
It’s Lightning-Fast: Next.js 14 and React Query ensure our apps load quickly and deliver buttery-smooth interactions.
It Scales Effortlessly: Whether it's a small MVP or a full-fledged enterprise app, NestJS and Supabase can handle the load as your project grows.
It’s Beautiful and Functional: With shadcn/UI, our interfaces are both head-turners and highly functional.

🌍 In 2025, startups must strike the perfect balance between development speed, scalability, and high-quality user experiences. By combining Next.js 14, React Query, useContext, Supabase, NestJS, and shadcn/UI, we’ve built a stack that achieves just that.

If you’re gearing up for your next project, give this stack a shot. It might just become your secret weapon too..
💬🤔 What stack are you using for your projects in 2025? Let me know in the comments!

Why Astro’s New Actions are the Upgrade React 19 Devs Have Been Waiting For

Rayen Mabrouk — Sat, 26 Oct 2024 21:59:40 +0000

React 19 introduced several exciting features, particularly in server-side interaction with Server Actions. These actions aim to streamline server calls, allowing developers to handle requests more effectively without extensive API boilerplate. However, they brought challenges, particularly in form handling, error management, and debugging. Astro’s new Actions, introduced with Astro 4.15, provide a promising alternative that addresses some of the limitations observed in React 19’s Server Actions.

Issues with React 19 Server Actions

React’s Server Actions simplify server-side interactions but come with specific limitations that can impact developer experience:

Complex Form Data Handling: Server Actions in React require handling form data manually as FormData objects. This manual extraction means developers need to cast or convert values into the desired types, often resulting in boilerplate code.

   const formData = new FormData(event.target);
   const name = formData.get("name");
   const age = Number(formData.get("age")); // Converts to a number
   const isActive = formData.get("isActive") === "on"; // Handles checkbox values

Limited Error Handling: Server Actions in React 19 lack built-in server-side error handling mechanisms. Errors in the server response default to a 200 OK status code, which can complicate client-side error management, making it challenging to distinguish success from failure.
Obfuscated Endpoint Names: Server Actions are not treated as traditional server endpoints but as function-like units. This approach can lead to hashed endpoint names, making debugging challenging as developers may struggle to map these hashed endpoints to actual functionality.

Astro’s Actions: A Game-Changer

Astro’s Actions address these limitations, offering an improved approach to server-side interaction. Here’s how Astro’s features provide enhanced support over React 19’s Server Actions:

Simplified Form Data Handling with Type Safety: Astro's Actions utilize zod for schema validation, allowing automatic parsing and type-safe form data handling. This reduces boilerplate and ensures that form inputs are converted to the correct data types by default.

   import { defineAction } from 'astro:actions';
   import { z } from 'astro:schema';

   export const server = {
     getGreeting: defineAction({
       input: z.object({
         name: z.string(),
       }),
       accept: 'form', // Specifies form data handling
       handler: async ({ input }) => {
         // this is a typesafe object now !
         const { name } = input;
         return `Hello, ${name}!`;
       }
     })
   };

Improved Error Handling: Astro’s Actions introduce ActionError, enabling more accurate HTTP status codes and messages for error handling, resembling traditional server endpoints. This functionality offers granular error control and clearer client-server communication.

   import { defineAction, ActionError } from "astro:actions";
   import { z } from "astro:schema";

   export const server = {
     likePost: defineAction({
       input: z.object({ postId: z.string() }),
       handler: async (input, ctx) => {
         if (!ctx.cookies.has('user-session')) {
           throw new ActionError({
             code: "UNAUTHORIZED",
             message: "User must be logged in.",
           });
         }
         // Process request if authorized
       },
     }),
   };

Readable Endpoint Names: Unlike React's hashed endpoints, Astro’s Actions use developer-defined names for endpoints, which makes debugging and tracing calls significantly easier.

Progressive Enhancement and Additional Resources: Astro focuses on Progressive Enhancement, allowing functionality to work even with JavaScript disabled. This aligns with Astro’s commitment to a lighter, more accessible web, ensuring that core functionalities remain intact without relying on JavaScript execution.

For further insights on Astro’s Actions, explore Astro actions docs, which dives into the details of integrating Actions in modern applications.

Keycloak: The Ultimate Open-Source Access Management Solution

Rayen Mabrouk — Tue, 30 Jul 2024 17:37:00 +0000

What is Keycloak?

Keycloak is a robust, flexible, and feature-rich IAM (Identity and Access Management) platform developed by Red Hat. It provides a centralized authentication and authorization service for web applications, mobile apps, and RESTful web services. Keycloak acts as a standalone server that can be easily integrated with existing systems, offering Single Sign-On (SSO), social login, user federation, client adapters, and an administration console out of the box.

Why Red Hat is Awesome

Red Hat is like the superhero of the tech world! They’re the wizards behind some of the coolest open-source tools that businesses use every day. Think of them as the friendly giants who make sure everything is secure, up-to-date, and running smoothly. They’re always innovating and working with the community to create awesome enterprise-grade solutions like Red Hat Enterprise Linux (RHEL) and OpenShift. Basically, Red Hat is the techie you want on your side if you want things done right and with a touch of magic!

Centralized Authentication and Authorization

Keycloak allows you to centralize your authentication services, eliminating the need to implement security features in each application separately. This means that instead of copying the same code across multiple apps, you can simply use the client feature and create a new client in your Keycloak realm, allowing you to scale and add more apps easily.

Single Sign-On (SSO), Social Login and Identity Brokering

Keycloak supports all of them out of the box! With Keycloak, users can authenticate once and access multiple applications without the need to log in again. It also supports login with popular social media platforms like Google, Facebook, and GitHub. Additionally, it allows for easy integration with existing identity providers, making it simple to federate user identities across different systems.

Customizable and Extensible

Keycloak offers extensive customization options, from theming login pages to extending core functionalities through custom Service Provider Interfaces (SPIs). This flexibility allows organizations to tailor the authentication experience to their specific needs.

Role Management System

Roles can be defined globally or at the client level, enabling flexible and scalable access control strategies. Here are some key features of the role management system:

Global and Client Roles: Global roles apply across the entire realm (All your apps), while client roles are specific to individual applications.
Composite Roles: Roles can be grouped into composite roles, allowing for hierarchical and modular permission management.
Role Mapping: Users and groups can be assigned specific roles, and roles can be mapped to specific permissions, making it easy to manage user access.

Advanced Use Cases Support

Keycloak also supports a wide range of advanced use cases:

Multi-tenancy Support: With its concept of "realms," Keycloak enables organizations to manage multiple tenants or client organizations within a single instance, each with its own set of users, roles, and configurations.
Robust Security Features: Keycloak includes built-in security features such as brute force detection, password policies, and session management, helping to protect against common security threats.
User Federation: Keycloak can integrate with existing user directories like LDAP or Active Directory, allowing organizations to leverage their current user management systems while benefiting from its advanced features.

Keycloak is a powerful and flexible access management solution. Its simple integration with existing systems makes it a top choice for enhancing application security without extra hassle. Developers can focus on building core features, trusting Keycloak to handle security!

Of course his article gives a general overview of this amazing open-source IAM. We'll dive deeper into its usage and maintenance in future articles.

Understanding Concurrency and Parallelism: What's the Difference?

Rayen Mabrouk — Tue, 18 Jun 2024 17:23:13 +0000

In this article, we will discuss the concepts of concurrency and parallelism, the differences between them, and the challenges we might face while implementing them. Let's dive in 🚶‍♀️.

What is Concurrency?

To understand concurrency, let's start with a simple example.

Imagine we have an app that receives user requests, and we are operating on a single thread. This means we handle one request at a time, respond to it, and then move on to the next one.

‼️ But what happens when the number of users increases over time?

In this case, the system will become very slow, similar to a restaurant where many customers arrive, but only one person is working to serve all of them.

So, you might think of hiring more people in the restaurant to serve the customers faster.
Similarly, to handle multiple requests in the app simultaneously, we need to use multiple threads to speed up the process and improve performance.

✅ This is exactly what Concurrency means – working on multiple tasks at the same time 🤝.

What is the Difference Between Concurrency and Parallelism?

Both concurrency and parallelism aim to improve performance, but they work differently.
If you have a set of threads, each performing a specific task:

In Concurrency:
The system runs them together through context switching, meaning it runs one thread for a while, then pauses it, and runs another thread, and so on until all tasks are completed.
In Parallelism:
The threads run simultaneously without switching between them; they operate in parallel.

To achieve parallelism, you need a multi-core processor to run the threads in parallel. In contrast, concurrency can be achieved on a single core by context switching between threads.

Should You Always Use Multiple Threads to Improve Performance?

◀️ There are many challenges and potential issues to be aware of and avoid (which we will discuss later).
If your task is simple and doesn't require multiple threads, then avoid adding unnecessary complexity. However, if you really need to improve performance, then using multiple threads is fine.

Here are some common problems you might encounter and should be careful about to prevent issues in your application:

Race Condition
Deadlock
Starvation

We will discuss these problems in detail in future articles..

Step-by-Step Guide to Typesafe Translations in Next.js Without Third-Party Tools

Rayen Mabrouk — Mon, 10 Jun 2024 17:44:10 +0000

Multilingual support is a critical feature for modern web applications. In this guide, we will walk through how to implement a typesafe translation system in a Next.js application without relying on any third-party libraries. This approach ensures that our translations are robust and maintainable.

Step 1: Define Translation Data

Create a directory named locales at the root of your project to store your translation files. Inside this directory, create JSON files for each language you want to support. For example, en.json for English and es.json for Spanish.

locales/en.json:

{
  "greeting": "Hello",
  "farewell": "Goodbye"
}

locales/es.json:

{
  "greeting": "Hola",
  "farewell": "Adiós"
}

Step 2: Create Server Action getTranslation

Define a server action named getTranslation.ts to fetch translation data. Here, we utilize an object called dictionaries, mapping language codes to functions that dynamically import the corresponding JSON file.

getTranslation.ts:

"use server";

const dictionaries = {
  en: () => import("./locales/en.json").then((module) => module.default),
  es: () => import("./locales/es.json").then((module) => module.default),
};

export default async function getTranslation() {
  const { defaultLang, error } = await getPreferredLang(); // Optional: Determine user's preferred language
  const lang = await dictionaries?.[defaultLang ?? "en"]?.();
  return {
    lang,
    error,
  };
}

Step 3: Create useTranslation Hook

In this example, I used React Query for managing state, but feel free to use any other state management solution of your choice. The main objective remains constant: crafting a versatile hook responsible for fetching translations, thereby enabling its use as a client-side state.

useTranslation.ts:

"use client";

import getTranslation from "@/translation/getTranslation";
import { useQuery } from "@tanstack/react-query";

export default function useTranslation() {
  return useQuery({
    queryKey: ["lang"],
    queryFn: () => getTranslation(),
  });
}

Step 4: Integrate Translation in Your Components

Now, let's use our custom hook in an Next.js client component.

You can also use the getTranslation() server action directly in your server components.

Advanced Server Rendering | React Query with Next.js App Router

Rayen Mabrouk — Thu, 30 May 2024 18:10:05 +0000

In this guide you'll learn how to use React Query with server rendering.

What is Server Rendering?

Server rendering is generating the initial HTML on the server so users see some content immediately when the page loads. This can be done in two ways:

Server-Side Rendering (SSR): Generates HTML on the server each time a page is requested.

Static Site Generation (SSG): Pre-generates HTML at build time or uses cached versions from previous requests.

Why is Server Rendering Useful?

With client rendering, the process looks like this:

Load markup without content.
Load JavaScript.
Fetch data with queries.

This requires at least three server roundtrips before the user sees any content.

Server rendering simplifies this process:

Load markup with content and initial data.
Load JavaScript.

The user sees content as soon as step 1 is complete, and the page becomes interactive after step 2. The initial data is already included in the markup, so there's no need for an extra data fetch initially!

How Does This Relate to React Query?

Using React Query you can Prefetch data before generating/rendering the markup On the server then use the data on the client to avoid a new fetch.
Now how to implement these steps..

Initial setup

The first steps of using React Query is always to create a queryClient and wrap the application in a <QueryClientProvider>. When doing server rendering, it's important to create the queryClient instance inside of your app, in React state (an instance ref works fine too). This ensures that data is not shared between different users and requests, while still only creating the queryClient once per component lifecycle.

store.tsx:

"use client";
import { useState } from "react";
import { QueryClient, QueryClientProvider } from "@tanstack/react-query";

export default function Store({ children }: { children: React.ReactNode }) {
  const [queryClient] = useState(
    () =>
      new QueryClient({
        defaultOptions: {
          queries: {
            staleTime: 5 * 60 * 1000,
          },
        },
      }),
  );
  return (
    <QueryClientProvider client={queryClient}>
      {children}
    </QueryClientProvider>
  );
}

layout.tsx:

import Store from "@/provider/store";

export default async function RootLayout({
  children,
}: {
  children: React.ReactNode;
}) {
  return (
    <html lang="en">
      <body>
        <Store>{children}</Store>
      </body>
    </html>
  );
}

Using the Hydration APIs

With just a little more setup, you can use a queryClient to prefetch queries during a preload phase, pass a serialized version of that queryClient to the rendering part of the app, and reuse it there. This avoids the drawbacks mentioned earlier.

hydration.tsx :

import {
  QueryClient,
  dehydrate,
  HydrationBoundary,
} from "@tanstack/react-query";
import getData from "@/api/getData";
import React from "react";
export default async function Hydration({
  children,
}: {
  children: React.ReactNode;
}) {
  const queryClient = new QueryClient({
    defaultOptions: {
      queries: {
        staleTime: 5 * 60 * 1000, // this sets the cache time to 5 minutes
      },
    },
  });
  await Promise.all([
    queryClient.prefetchQuery({
      queryKey: ["profiles", "user"],
      queryFn: () => getData("profiles"),
    }),
    queryClient.prefetchQuery({
      queryKey: ["permissions", "user"],
      queryFn: () => getData("permissions"),
    }),
  ]);
  return (
    <HydrationBoundary state={dehydrate(queryClient)}>
      {children}
    </HydrationBoundary>
  );
}

The new layout.tsx:

import Hydration from "@/provider/hydration";
import Store from "@/provider/store";

export default async function RootLayout({
  children,
}: {
  children: React.ReactNode;
}) {
  return (
    <html lang="en">
      <body>
        <Store>
          <Hydration>{children}</Hydration>
        </Store>
      </body>
    </html>
  );
}

at a general level, these are the extra steps:

Create a constant queryClient using new QueryClient(options) (It is important that you set a staleTime otherwise, React Query will refetch the data as soon as it reaches the client).
Use await queryClient.prefetchQuery(...) for each query you want to prefetch.
Use await Promise.all(...) to fetch the queries in parallel when possible.
It's fine to have queries that aren't prefetched. These won't be server-rendered; instead, they will be fetched on the client after the application is interactive. This can be great for content shown only after user interaction or content far down on the page to avoid blocking more critical content.
Wrap your tree with <HydrationBoundary state={dehydrate(queryClient)}> where dehydratedState comes from the framework loader.

An Important Detail

When using React Query with server rendering, there are actually three queryClient instances involved in the process:

Preloading Phase:
Before rendering, a queryClient is created to prefetch data.
Necessary data is fetched and stored in this queryClient.
Server Rendering Phase:
Once data is prefetched, it's dehydrated (serialized) and sent to the server rendering process.
A new queryClient is created on the server and injected with dehydrated data.
This ensures the server generates fully populated HTML for the client.
Client Rendering Phase:
Dehydrated data is passed to the client.
Another queryClient is created on the client and rehydrated with the data.
This ensures the client starts with the same data, maintaining consistency and skipping initial data fetching.

This ensures all processes start with the same data, so they can return the same markup.

Then with the useQuery() hook, you can use your prefetched queries as you normally would, and the data will be prefetched during the preloading phase. This means that when you use useQuery() to fetch data in your components, React Query will automatically handle the prefetching of that data before the component renders. This helps improve the performance of your application by ensuring that the data is available when needed.

"use client";
import getData from "@/api/getData";
import { useQuery } from "@tanstack/react-query";

 const { data: profiles } = useQuery({
   queryKey: ["profiles", "user"],
   queryFn: () => getData("profiles"),
 });
 const { data: permissions } = useQuery({
   queryKey: ["permissions", "user"],
   queryFn: () => getData("permissions"),
 });

High memory consumption on the server

When you create a QueryClient for each request in React Query, it generates an isolated cache specific to that client. This cache remains in memory for a specified period known as the gcTime. If there's a high volume of requests within that period, it can lead to significant memory consumption on the server.

By default, on the server, gcTime is set to Infinity, meaning manual garbage collection is disabled, and memory is automatically cleared once a request is completed. However, if you set a non-Infinity gcTime, you're responsible for clearing the cache early to prevent excessive memory usage.

Avoid setting gcTime to 0, as it might cause a hydration error. The Hydration Boundary places necessary data into the cache for rendering. If the garbage collector removes this data before rendering completes, it can cause issues. Instead, consider setting it to 2 * 1000, allowing sufficient time for the app to reference the data.

To manage memory consumption and clear the cache when it's no longer needed, you can call queryClient.clear() after handling the request and sending the dehydrated state to the client. Alternatively, you can opt for a smaller gcTime to automatically clear memory sooner. This ensures efficient memory usage and prevents memory-related issues on the server.

example:

const queryClient = new QueryClient({
    defaultOptions: {
      queries: {
        gcTime: 2 * 2000, // this sets the garbage collection time to 2 seconds
      },
    },
  });

In wrapping up, React Query simplifies the process of fetching and caching data, especially when dealing with server-side rendering. By fetching data in advance on the server and seamlessly transferring it to the client, React Query ensures a smooth and consistent user experience. Plus, with features like adjusting the memory management settings, developers can fine-tune performance to meet their application's needs. With React Query, developers can focus on building engaging applications without worrying about complex data management tasks, ultimately delivering faster and more responsive user experiences.

DEV Community: Rayen Mabrouk

Why We Ditched Node for Bun in 2026 (And Why You Should Too)

1. The Death of the Toolchain Sprawl

2. ElysiaJS: The Bun Backend Framework

3. Performance That Actually Saves Money

4. "Bun Install" is the New Standard

5. The 2026 Reality: Compatibility is No Longer an Issue

How to Start Your Migration

My Personal Thoughts..

Nx Architecture Guide

Purpose & Principles

Why This Matters

Problems This Solves

Workspace Layout

Core Rules

1 — Apps are Standalone

2 — Packages Are the Source of Truth

Naming, Tags & Boundaries

Package Naming

Enforcing Boundaries with Nx

Contracts & FE/BE Sync

Environment & Config Rules

Caching, Targets & Bun

1 — Default Targets (nx.json)

2 — Bun Commands

Affected Workflow

Testing Strategy

Performance & DX Tips

Why Nx Over Competitors

Quick Commands Cheat Sheet

Final Thoughts

Why We Ditched Drizzle & Knex in favor of Kysely's Querybuilder

The Challenge: Balancing Abstraction and Control (The Pitfalls of Traditional ORMs)

1. The Illusion of Simplicity: Hidden Complexity

2. Limited Customization

3. The Spaghetti Code Scenario: Complex Queries in ORM Syntax

Type Safety: A Crucial Distinction

Kysely vs. Knex vs. Drizzle: A Practical Comparison

SQL Query Representation

Knex Implementation: SQL-Like but Error-Prone

Drizzle Implementation: Improved Readability but Partial Type Safety

Kysely Implementation: Fully Type-Safe and SQL-Like

Key Takeaways: Why Kysely Stands Out

Conclusion: Embrace Type-Safe Query Building

Why NestJS Is The New Gold Standard For Node Backend Development

1. Why OOP is the Best for Backend Development

Code Example

2. NestJS is Future-Proof

Code Example

3. Ideal for Microservices and Enterprise Applications

Code Example

4. Built-in Support for Everything

Code Example

5. Modular Architecture That Scales

Code Example

6. Very Hard to Mess Up in NestJS

Code Example

Final Thoughts

The Ultimate Tech Stack for Startups in 2025

Frontend: Next.js 14 with React Query and Context API

Backend: Supabase and NestJS

UI Framework: shadcn/UI

Why This Stack Works for Startups

Why Astro’s New Actions are the Upgrade React 19 Devs Have Been Waiting For

Issues with React 19 Server Actions

Astro’s Actions: A Game-Changer

Keycloak: The Ultimate Open-Source Access Management Solution

What is Keycloak?

Why Red Hat is Awesome

Centralized Authentication and Authorization

Single Sign-On (SSO), Social Login and Identity Brokering

Customizable and Extensible

Role Management System

Advanced Use Cases Support

Understanding Concurrency and Parallelism: What's the Difference?

What is Concurrency?

What is the Difference Between Concurrency and Parallelism?

Should You Always Use Multiple Threads to Improve Performance?

Step-by-Step Guide to Typesafe Translations in Next.js Without Third-Party Tools

Step 1: Define Translation Data

1 — Default Targets (`nx.json`)