PlayGround
Login

Performance

fetch 10k Users tanstack/virtual, react-window, fetching (bad performance)

Bad Performance

react-window

performance optimized.

TANSTACK VIRTUALIZED

performance optimized

Navigate to /10k-users/tanstack-virtualized

Tables

fetching data with tanstack-tables and shadcn

Tanstack Tables

with Shadcn Components

Open TanStack Tables demo

Chat

Socket.IO Private/Group chat

Socket IO/ Tanstack Query

with Shadcn Components

Open chat rooms

AI

Bots/ Livechat/ tanstack-hotkeywords/ tanstack-ai / tools

Admin

Controlling the database

Press Ctrl+Alt+9
Admin Page

Realtime Voice Chat

General Chat

Press Ctrl+Alt+8
General realtime chat

ChatEGY

deepsearch, upload images/PDF, execute code and more

Press Ctrl+Alt+0
Code Execution

Projects

My Projects & my stack used in them

CareerCast AI

Podcast Generator, CV Reviewer, Job Application Tailor

Playground

Performance & System Engineering Lab

Flower Obsession

E-commerce Flower shop billingual (Arabic & Enlgish)

Audits

Audit logs are intentionally public in this project to demonstrate how activity tracking works across users and system events. They are not indicators of bugs or implementation issues — they are an operational feature designed to provide visibility into what happens inside the application.

In production environments, audit logs are typically restricted to authorized roles such as administrators, auditors, and security teams. Access is limited because logs often contain sensitive operational context, security-relevant events, and traces of critical business actions.

Audit logging is essential for observability, troubleshooting, and accountability. When a production issue occurs — for example, a payment failure, permission change, failed API request, or unexpected system error — logs make it possible to trace exactly what happened, when it happened, and which user or system process triggered the event. This allows teams to investigate incidents with precise timestamps and reliable historical context.

Audit logs also provide an important layer of verification. If a specific action does not appear in the audit trail, there is no recorded evidence that the action was executed. In that sense, audit logs serve as operational proof of activity and are a core part of maintaining reliability, security, and trust in modern software systems.

NestJS Audit Logs

NestJS audit logs for internal platform events.

FastAPI Audit Logs

FastAPI audit logs for ecommerce platform events.

NoSQL vs SQL

A quick comparison between document databases like MongoDB and relational databases like PostgreSQL, focused on schema design, scaling, consistency, and real-world use cases.

Aspect
SQL
NoSQL
Structure
Tables with rows, columns, and explicit relationships.
Documents, key-value pairs, graphs, or wide-column records.
Schema
Strict and predefined, which keeps data predictable.
Flexible and easier to evolve while requirements are changing.
Scaling
Usually scales vertically by upgrading a single server.
Usually scales horizontally by spreading load across nodes.
Consistency
Strong transactional guarantees with ACID-friendly workflows.
Can trade strict consistency for availability and scale.

Rule of thumb

Model the data first, then pick the database.

SQL is usually the safer default when relationships and transactions matter. NoSQL shines when the shape of the data changes often or the system needs document-style flexibility at scale.

Best for SQL

Banking, ERP, orders

Best for NoSQL

Feeds, CMS, logs, chat

Tradeoff

Flexibility vs stronger constraints

Choose PostgreSQL / SQL

Payments, orders, and inventory rely on reliable transactions.
Your app depends on joins, foreign keys, and structured reporting.
Large teams need schema enforcement to reduce bad writes.

Choose MongoDB / NoSQL

Data shapes change often and you want faster iteration.
You store JSON-like content, feeds, logs, or nested objects.
You need to scale reads and writes across distributed systems.

SQL: normalized data + JOIN

SELECT posts.title, users.name
FROM posts
JOIN users ON users.id = posts.user_id;

NoSQL: nested document

{
  "name": "Mohamed",
  "posts": [
    { "title": "Post 1" },
    { "title": "Post 2" }
  ]
}

Reference

MongoDB guide comparing SQL and NoSQL database models.

Open resource

REST API vs GraphQL vs Socket.IO

These tools solve different communication problems. REST is great for standard HTTP APIs, GraphQL is strong when clients need flexible data fetching, and Socket.IO is built for real-time event updates.

Aspect
REST
GraphQL
Socket.IO
Communication style
Multiple endpoints, each one represents a resource.
Single endpoint where the client asks for exactly the fields it needs.
Persistent two-way connection for live events.
Best request pattern
Request/response over HTTP with clear routes and verbs.
Query, mutation, and subscription style data access.
Event-driven messaging between client and server.
Great for
CRUD APIs, public APIs, service-to-service communication.
Complex frontends, dashboards, mobile apps with varied data needs.
Chat, presence, notifications, live collaboration, streaming state.
Main tradeoff
Can overfetch or underfetch when screens need mixed resources.
More setup, schema design, and resolver complexity.
Connection state, scaling, and delivery rules need extra care.

Quick guide

Use the transport that matches the user experience.

If the user asks for data, REST is usually the simplest choice. If the screen needs many shapes of related data, GraphQL can reduce round trips. If the server must push updates instantly, use Socket.IO.

Simple default

REST for CRUD apps

Flexible reads

GraphQL for complex frontend data needs

Live updates

Socket.IO for chat, rooms, and presence

Choose REST API

You want predictable endpoints like /users, /orders, and /products.
Caching, HTTP status codes, and simple backend contracts matter.
Your app is mostly request/response and does not need real-time sync.

Choose GraphQL

One screen needs data from many related resources in one request.
Frontend teams need flexibility without adding many new endpoints.
You want a strongly typed schema shared across clients.

Choose Socket.IO

Users should see updates instantly without refreshing or polling.
Presence, typing indicators, room events, or live dashboards matter.
The server needs to push events to clients in real time.

REST endpoint

GET /api/users/42

{
  "id": 42,
  "name": "Mohamed"
}

GraphQL query

query {
  user(id: 42) {
    name
    posts {
      title
    }
  }
}

Socket.IO event

socket.emit("message:send", {
  roomId: "general",
  text: "hello"
});

Reference idea

REST handles standard APIs, GraphQL handles flexible queries, and Socket.IO handles real-time events.

See your Socket.IO example