DEV Community: Raiyan C

Database Development Without ORM: A Pragmatic Approach to SQL-First Workflows

Raiyan C — Tue, 18 Aug 2026 04:52:35 +0000

The Problem with ORM Abstraction

Many developers express frustration with ORM tooling, particularly around SQL migrations. The desire to work directly with SQL is common, yet existing solutions often fall short when handling testing, seeding, staging environments, and team onboarding.

A SQL-First Alternative

A new approach addresses these pain points without introducing additional abstractions. The tooling is built on Kysely, allowing developers to maintain typed queries while gaining support for stored procedures and table-valued parameters. The JavaScript/TypeScript layer remains responsible for IO coordination and business logic, with the database layer handling schema management.

Key features include:

No domain-specific language (DSL)
No code generation
No subscription requirements
Native SQL validation and debugging support
Integration with visual database clients

Supporting AI Agents

The platform includes safeguards for AI agent interactions, with built-in skills, MCP support, and per-agent role configurations. This prevents automated processes from making destructive changes to production environments while enabling efficient development workflows.

Data Modeling and Schema Design

A separate tool, Ignatius, handles data modeling and planning. It supports multiple schema description formats, including IDEF1X with modern symbols, and is designed for iterative development. The markdown-based workflow allows developers to maintain context details for themselves and their LLM assistants.

Practical Benefits

This approach eliminates the translation layer between SQL and JavaScript, allowing developers to:

Copy and debug SQL directly in visual clients
Maintain full language server validation for SQL
Use SQL migration files without additional wrappers
Avoid the cognitive overhead of ORM method translation

Conclusion

The solution provides a middle ground between raw SQL management and full ORM tooling, serving developers who prefer direct database interaction while still offering TypeScript integration and modern development workflow support.

Why HTTP 429 Should Not Count Against a Job's Retry Budget

Raiyan C — Tue, 18 Aug 2026 04:34:12 +0000

Most retry implementations—including BullMQ, custom wrappers, and managed queues—treat every non-2xx HTTP response as an identical failure. Each attempt increments the retry counter, applies backoff, and after N attempts moves the job to a dead-letter queue (DLQ).

However, a 429 status code indicates rate limiting, not a failure. The downstream service explicitly tells the client when to retry, often via a Retry-After header. Counting a 429 as a failed attempt means sustained rate limiting can move valid jobs to the DLQ, while the actual error budget—intended for 500s, timeouts, and connection resets—remains unused.

An alternative approach treats 429 (and similarly 503/529) as deferrals rather than failures: honor Retry-After, requeue the job, and do not decrement the retry count. This preserves the retry budget for genuine errors.

Ceilings for Deferred Jobs

A deferral strategy requires safeguards to prevent indefinite requeuing. Two ceilings are commonly used:

Wall-clock deadline: A job expires after a fixed time (e.g., 24 hours) regardless of deferral count.
Maximum defer count: A separate limit on how many times a job can be deferred.

When a job exceeds the defer ceiling, it moves to the DLQ with a distinct reason—separate from "out of retries." This distinction matters because exceeding retries suggests the downstream is broken, while exceeding deferrals suggests the service has been unusable long enough to be treated as broken.

Monitoring and Visibility

Deferred jobs are invisible in standard failure metrics. They do not trigger alerts or appear as failures, so a queue can remain undrained while appearing healthy. This requires dedicated state tracking and alerts for deferred jobs, rather than folding them into "pending" or "processing" counts.

Distinguishing 503 from 429

503 Service Unavailable is more ambiguous than 429. It may indicate temporary overload, maintenance, or a gateway issue. Some implementations lump 503 with 429 as deferrals, but the ambiguity means additional context (e.g., presence of Retry-After, service health checks) may be needed to decide whether to defer or count it as a failure.

I Built Genesis: The First Brain for AI Agents (Agent-skills)

Raiyan C — Mon, 10 Aug 2026 13:35:36 +0000

AI coding agents are getting better at writing code.

But there is still a problem I keep seeing:

Every new agent session starts by rediscovering the project.

It has to figure out the architecture.

It has to discover conventions.

It has to understand previous decisions.

It has to learn how the team works.

And after the session ends, a lot of that understanding disappears.

So I built something to address that problem.

Genesis.

GitHub — raiyanu/agent-genesis
Skill.sh — raiyanu/agent-genesis

What is Genesis?

Genesis is a project-local cognitive layer for AI agents.

I think of it as the first brain of an agent.

Before an agent starts working on a project, Genesis gives it a structured way to:

Understand the project
Learn the existing architecture
Follow established conventions
Reuse previous knowledge
Learn from new discoveries
Preserve useful knowledge for future sessions

The core idea is simple:

Understand before acting. Learn while working. Remember for the next agent.

The Genesis Flow

The workflow looks like this:

        Genesis
           ↓
      Understand
           ↓
         Plan
           ↓
        Execute
           ↓
          Learn
           ↓
        Remember
           ↺

The important part is the last step.

The agent doesn't just finish a task.

It can leave behind knowledge that makes the next session better.

Why project-local knowledge?

I didn't want Genesis to depend on a particular AI provider, IDE, or agent runtime.

The knowledge belongs to the project.

That means it can live alongside the codebase and be version controlled with Git.

A simplified structure looks like:

.agents/
├── SKILL.md
└── agent_md/
    ├── project-learn.md
    ├── user-learn.md
    ├── domains/
    ├── patterns/
    ├── decisions/
    └── debugging/

This makes project knowledge:

Human-readable
Version-controlled
Shareable
Agent-agnostic
Persistent across sessions

The Problem I'm Trying to Solve

Imagine three developers working on the same project.

Developer A teaches an AI agent about an important architectural decision.

Developer B starts a new session tomorrow.

Without persistent knowledge, the agent may have to rediscover that decision.

With Genesis, the project can retain it.

Developer A
     ↓
   Agent
     ↓
  Discovers
  Knowledge
     ↓
   Genesis
     ↓
Project Memory
     ↓
Developer B
     ↓
   Agent
     ↓
Starts with
that knowledge

The project gradually becomes better at communicating with its agents.

Genesis Is Not Just Memory

This is an important distinction.

I don't see Genesis as simply a memory folder.

Memory is only one part of it.

Genesis is about the agent's relationship with the project:

Before the task

Understand what already exists.

During the task

Follow the project's architecture and conventions.

After the task

Identify what was learned and preserve knowledge that can help future work.

That creates a continuous learning loop.

Why Markdown?

I intentionally kept the foundation simple.

No database.

No vector store.

No proprietary format.

Just files that humans and AI agents can both understand.

That gives the knowledge the same benefits as source code:

Git
 ↓
Versioning
 ↓
Review
 ↓
History
 ↓
Collaboration

Project knowledge becomes part of the project itself.

The Bigger Idea

I think we're moving toward a world where projects won't just contain source code.

They will also contain context for the agents working on that source code.

Today we have:

Source Code
Documentation
Tests
Configuration

I think we'll increasingly have:

Source Code
Documentation
Tests
Configuration
Agent Knowledge
Agent Instructions
Agent Decisions

The goal isn't to make agents magically smarter.

It's to make sure they don't have to forget everything every time they start.

What Changed for Me

After using Genesis in my own agent workflow, I noticed a significant reduction in the time spent on project discovery and repeated context-building.

For my workflow, it was roughly 80% faster to get an agent into a productive state.

The important part isn't that Genesis makes the AI model itself faster.

It reduces the repeated work around the model:

Without Genesis
Agent → Explore → Rediscover(grepping 10+ function and reading 1200+ lines of code) → Understand → Start Working

With Genesis
Agent → Load Context → Understand → Start Working

That difference becomes especially noticeable when working across multiple sessions or switching between CLI and IDE agents.

The agent doesn't have to start from zero every time.

It starts with what the project has already learned.

For every Module, First prompt was slower but second prompt doesnt matter if it's different session or account or agent or system it become faster than before. for my ecommerce project it improved agent time in searching for code from 2-3 minute to 20 seconds.

Genesis

The name comes from the idea of a beginning.

Genesis is the point where the agent starts.

Not with assumptions.

Not with a blank context.

But with the knowledge the project has already accumulated.

Every agent session should start smarter than the previous one.

Genesis is my first step toward that idea.

The project is open source, and I'm interested in seeing how this concept evolves with the rapidly changing AI-agent ecosystem.

If you're building CLI agents, IDE agents, coding agents, or autonomous development workflows, I'd love to hear how you're solving the persistent context problem.

Check out Genesis on GitHub → raiyanu/agent-genesis

Check out on Skill.sh → raiyanu/agent-genesis

Native HTTP Engine for Node: Performance Benchmarks Against uWS, Bun, Fastify, and Hono

Raiyan C — Mon, 10 Aug 2026 07:05:20 +0000

Overview

A native HTTP engine for Node.js has been developed with the goal of providing a faster, built-in alternative to the standard node:http module. This engine is designed to address performance bottlenecks and reduce the overhead of third-party native addons.

Performance Benchmarks

Benchmarks were conducted on a Node 24.11 environment running on an M2 Ultra machine. The testing tool was wrk with 100 connections over a 40-second duration, recording the best result of three runs. All packages were pulled from npm rather than built locally.

Requests per Second

Server	Non-pipelined	Pipelined ×10
`@morojs/engine`	105,974	663,735
uWebSockets.js	103,744	647,530
raw `Bun.serve`	107,119	21,686
raw `node:http`	69,045	109,538
Hono	56,926	100,278

Observations

Non-pipelined Performance: The non-pipelined column appears to be limited by the test machine's maximum capacity, with native transports converging around 105k requests per second. Bun.serve marginally leads in this metric. Adding a framework like Elysia on top of Bun.serve reduces its performance to 96.7k requests per second.
Pipelined Performance: The new engine shows a significant advantage in pipelined requests, achieving about a 10% improvement over uWebSockets.js once a framework is integrated. This is attributed to response corking and batching pipeline requests into a single write operation.

A full performance matrix and testing harness are available in the benchmark repository.

Technical Architecture

The engine is built with a C++ core using raw V8 bindings instead of N-API. The primary design principle is to minimize boundary crossings between C++ and JavaScript.

General-purpose bindings typically perform 10-20 JavaScript crossings per request.
This engine reduces crossings to 2-4 per request by batching request snapshots and response writes.

Corking and Optimization

Corking is central to the performance gains, particularly for pipelined requests. Version 1.1.0 introduced batching of an entire pipeline into a single write, along with a zero-allocation hot path, resulting in a 3.7x improvement in pipelined performance over version 1.0.0.

Trade-offs and Build Strategy

N-API vs. Raw V8: While N-API offers a stable ABI and easier maintenance, it did not achieve the desired performance levels. Raw V8 bindings were chosen for performance, at the cost of ABI-locking.
ABI Compatibility: To manage the ABI matrix, the project builds and ships precompiled binaries from tagged CI builds with npm provenance. This ensures day-one compatibility with new Node.js releases, avoiding delays often associated with third-party native addons.
Fallback Mechanism: In environments where a prebuilt binary is not available, the engine gracefully falls back to node:http and logs the reason via app.engine.fallbackReason.

Security

The engine has zero external dependencies. It handles query, cookie, multipart, and route-pattern parsing directly within the framework.

Fuzzing: These parsers are property-fuzzed with a fixed seed on every push and nightly with a rotating seed at 500,000 iterations per property.
C++ Parser: The underlying C++ HTTP parser has its own dedicated fuzzing harness within the engine repository.

Availability

This engine is the default server for a framework maintained by the author. The source code and project repositories are publicly available.

Engine Repository: https://github.com/Moro-JS/engine
Framework Repository: https://github.com/Moro-JS/moro
Project Site: https://morojs.com

Building a TypeScript SDK for Secure Direct Uploads to AWS S3 and ImageKit

Raiyan C — Mon, 03 Aug 2026 08:30:30 +0000

Introduction

Handling file uploads in web applications often involves a trade-off between security, performance, and developer experience. A new open-source TypeScript SDK, Upload SDK, addresses these concerns by enabling secure direct uploads from the browser to cloud storage providers such as AWS S3 and ImageKit.

How It Works

The SDK shifts the responsibility of file transfer away from the application server. The workflow is as follows:

The Node.js server validates the upload request.
The server generates a short-lived, signed upload target.
The browser uploads the file directly to the storage provider using the signed details.

This approach ensures that the application server never needs to stream or proxy the actual file data, reducing bandwidth usage and server load.

Configuration and Usage

Developers define named upload types (e.g., avatar, invoice) to manage different file categories. Each type includes configuration rules:

Allowed MIME types and file extensions
Maximum file size
Expiry time for the upload request
Storage destination and key prefix

To initiate an upload, the browser sends the asset name and file metadata to the server. The server then calls prepareUpload(), which validates the request, generates a collision-resistant storage key, and returns signed multipart POST details to the client.

Multiple Storage Profiles

The SDK supports multiple storage profiles within the same application. For instance, developers can configure:

One S3 bucket for public files
Another S3 bucket for private documents
ImageKit for image-specific storage

This configuration maintains a consistent upload flow across different providers.

Security with Signed Policies

For Amazon S3, the SDK includes security constraints directly in the signed POST policy. This policy can enforce:

File size limits
Content type validation
Specific storage keys
Expiration times

These restrictions are enforced by S3 during the upload process, adding an additional layer of security.

Next Steps

The project is open for feedback on its current API and for suggestions regarding which storage providers to support next.

Xberg v1: A High-Performance Content Intelligence Framework

Raiyan C — Mon, 03 Aug 2026 07:53:35 +0000

Overview

Xberg v1 has been released as the successor to Kreuzberg, representing a significant evolution in content intelligence processing. The framework handles a wide range of input types including documents (101 formats), code and data (367 types), audio/video transcription, and URLs with static or JavaScript-rendered content.

Performance and Architecture

Xberg is engineered as a high-performance engine with substantial improvements over its predecessor. For PDF and image processing, it handles native PDFs with high performance and accuracy, and includes multiple OCR engines that match the quality of leading Python libraries such as docling, PaddleOCR, and RapidOCR, while offering better performance and stability.

Key Technical Changes

The transition from Kreuzberg v4 to Xberg v1 introduces several major architectural changes:

Pure-Rust PDF backend (pdf_oxide) replaces pdfium, eliminating native pdfium dependencies
Layout-aware pipeline with ONNX layout detection using PP-DocLayoutV3/RT-DETR and Docling-style predecessor-graph reordering
Per-page scanned-page detection with selective OCR, plus AcroForm/XFA form field support and outline-based headings
Optimized OCR and PDF extraction with improved memory discipline, pooled model sessions, and streamed conversions
Native PaddleOCR backend supporting PP-OCRv6 with medium/small/tiny tiers alongside Tesseract

Inference and Model Support

The framework includes multiple inference paths:

Pure-Rust Candle OCR/VLM stack supporting TrOCR, GLM-OCR, GOT-OCR, DeepSeek-OCR, and PaddleOCR-VL without ONNX Runtime or native Tesseract dependencies
Secondary inference path via tract enabling ONNX-free execution for in-browser (WASM) and mobile inference
Named-entity recognition natively in Rust (GLiNER2) extensible to all bindings, including in-browser WASM models with no server round-trip

Structured Extraction and Retrieval

Xberg provides comprehensive content processing capabilities:

Structured LLM extraction (extract_structured/split_and_extract) with rasterization, chunking, citations, caching, and configurable policies
Audio and video transcription via Whisper ONNX engine supporting .mp3, .wav, .m4a, .mp4, and .webm formats
Retrieval building blocks including sparse embeddings (SPLADE), ColBERT late-interaction retrieval, cross-encoder reranking, and dense embeddings
Text intelligence features including reversible redaction, summarization, translation, VLM image captioning, QR-code detection, document diffing, and page/chunk classification

Web and Format Support

URL and web ingestion with sitemap discovery (map_url) and batched multi-URL crawling
New document formats including WordPerfect (.wpd/.wp/.wp5), HEIC/HEIF/AVIF, OpenDocument Presentation (.odp), Quarto/R Markdown, and configurable Jupyter cell rendering
Expanded code intelligence with tree-sitter coverage growing from 248 to 367+ languages

Cross-Platform and Bindings

Four new language bindings (Dart/Flutter, Swift, Kotlin/Android, and Zig) bring the total to 15 language bindings over one engine. The framework now includes full mobile support for Flutter, Android, and iOS, with cross-compilation capabilities.

Benchmark Results

Performance benchmarks for PDF and image processing demonstrate Xberg's capabilities:

Composite Quality (Markdown Pipeline, higher is better):

Xberg (layout): 0.958 (Native PDF), 0.836 (Scanned PDF)
docling: 0.779 (Native PDF), 0.762 (Scanned PDF)
mineru: 0.408 (Native PDF), 0.792 (Scanned PDF)

Structure and Layout Fidelity (SF1: tables and reading order, higher is better):

Xberg: 0.949 (Native PDF), 0.531 (Scanned PDF)
docling: 0.612 (Native PDF), 0.366 (Scanned PDF)

For native PDFs, Xberg leads on quality (0.958 vs 0.837 for the next-best framework) and table/reading-order fidelity (SF1 0.949 vs 0.612 for docling). On scanned PDFs, it ranks first on both quality and raw text fidelity.

Migration and Support

A migration guide is available for transitioning from Kreuzberg to Xberg. Kreuzberg remains in LTS mode until the end of the year with continued bug fixes and security updates. The full changelog documents all changes, with over 150 bugs fixed during the 1.0 cycle plus security hardening including bounded RTF/PDF allocations, redaction leak fixes, and Excel DDE warnings.

Testing title

Raiyan C — Fri, 31 Jul 2026 13:40:57 +0000

Testing body