Profile Picture

Ashutosh

Software Developer

Mathura, India

View Resume

About

I'm a full-stack developer with hands-on experience in building and deploying modern web applications. Skilled in Next.js, TypeScript, Prisma, PostgreSQL, and Docker-based deployments, with strong version control practices using Git/GitHub.

Projects

Greenchess

A real-time 1v1 online chess platform built with Next.js (TypeScript), featuring instant matchmaking, live move synchronization via Pusher, persistent game state with PostgreSQL + Prisma, and fast session handling using Redis.

Next-ts, Prisma, PostgreSQL, Redis, Pusher

GitHub Live Demo

Splitwise

Splitwise in an expense tracking application that simplifies tracking and splitting shared expenses and debts among friends, roommates, or family, making it easy to see who owes whom for things like rent, trips, or meals.

Next-ts, Shadcn, Prisma, PostgreSQL, JWT

GitHub Live Demo

Dopaminly

A social platform where users can create profiles, share photos, follow others, interact through likes and comments, and chat one-on-one in real time.

Next-ts, Tailwind, Prisma, PostgreSQL, Cloudinary, Pusher

GitHub Live Demo

QuietPages

AI-powered blogging platform built with Next.js. Provides real-time next-word suggestions using Gemini API, sup- ports image uploads via Cloudinary, and integrates Razorpay for payments.

Next-ts, Tailwind, Prisma, PostgreSQL, Cloudinary, Gemini API, Razorpay Integration, Clerk

GitHub Live Demo

Skills

Frontend

  • Next.js
  • React
  • JavaScript/TypeScript
  • TailwindCSS
  • Websockets

Backend

  • Node.js
  • Bun
  • Express.js
  • Prisma + PostgreSQL
  • JWT Authentication

Tools

  • Git/Github
  • VS Code
  • Postman
  • Docker
  • Bash

Articles

What problem does connection pooler solves?

January 2026 · 5 min read

A connection pool is a cache of database connections maintained so that they can be reused when future requests to the database are required. Instead of closing a connection after a query finishes, it is kept alive and placed back into the "pool." ..Read more

Problem Statement:

Imagine an app with thousands of users. Each time a user triggers a database query, the app opens a new connection. This process isn't free. Each new connection requires a network handshake, SSL negotiation, and authentication. On the database server, this consumes CPU and memory—Postgres, for example, spawns a new process for every connection. At scale, the overhead of creating the connection can take longer than the query itself. If too many users connect at once, the database hits its "connection limit" and starts rejecting requests, causing downtime.

..Read less

Solution: Connection Pooling

A connection pool is a cache of database connections maintained so that they can be reused when future requests to the database are required. Instead of closing a connection after a query finishes, it is kept alive and placed back into the "pool."

When a new client request comes in: - The app (or a dedicated pooler like PgBouncer) checks the pool for an idle connection. - If one is available, it’s "rented out" to the request immediately. - The query is executed over this existing connection, skipping the expensive handshake. - Once finished, the connection is returned to the pool for the next user.

The Benefits: - Reduced Latency: No more waiting for handshakes. - Resource Efficiency: Database CPU and RAM stay stable because the number of active processes is capped. - Request Queuing: If the pool is full, new requests wait in a queue for a few milliseconds instead of being immediately rejected.

Why didn’t Rust developers choose to have a garbage collector?

November 2025 · 2 min read

Rust was designed to solve memory safety differently — without sacrificing performance. ..Read more

Rust was designed to solve memory safety differently — without sacrificing performance.

Garbage collectors, like those used in Java or Go, automatically clean up memory at runtime. That’s convenient, but it comes with a cost: unpredictable pauses, extra CPU usage, and less control over performance-critical systems.

Rust takes another path. Instead of a runtime garbage collector, it uses a compile-time ownership system. The compiler tracks who owns what memory and ensures it’s safely freed when no longer needed. No runtime scanning, no pauses — just deterministic, efficient memory management.

This approach gives Rust C/C++-level performance with strong safety guarantees. It’s memory safety without garbage collection — and that’s what makes Rust stand out in the world of modern systems programming.

..Read less

A high-level overview of WebRTC.

June 2025 · 10 min read

WebRTC enables real-time audio, video, and data communication directly between browsers using a peer-to-peer model. It powers applications like video calls, voice calls, and live streaming without requiring plugins or native applications. ..Read more

WebRTC enables real-time audio, video, and data communication directly between browsers using a peer-to-peer model. It powers applications like video calls, voice calls, and live streaming without requiring plugins or native applications.

Even though WebRTC is primarily peer-to-peer, it still relies on servers during the connection setup phase to work reliably across different network conditions.

A signaling server is used to exchange metadata between peers, such as session descriptions and ICE candidates. WebRTC itself does not define how signaling should be implemented, and the signaling server does not carry media.

A STUN server helps a peer understand how it appears to the public internet by returning the public IP address and mapped port assigned by the NAT.

ICE candidates represent possible network endpoints that can be used to establish a connection. These candidates include IP address, port, protocol, and candidate type, and are gathered from local interfaces, STUN servers, and TURN servers.

A TURN server acts as a fallback when direct peer-to-peer communication is not possible due to restrictive NATs or firewalls. In such cases, media is relayed through the TURN server to ensure connectivity.

WebRTC uses an offer and answer model for negotiation. One peer initiates the connection by sending an offer, and the other peer responds with an answer that describes how the session should be established.

Session Description Protocol, or SDP, is a text-based format that describes the multimedia session, including media types, codecs, transport parameters, and ICE candidates.

RTCPeerConnection is the browser API responsible for managing connection setup, ICE candidate exchange, and media transmission between peers.

While peer-to-peer works well for small groups, it does not scale efficiently beyond a few participants. To support larger calls, Selective Forwarding Units, or SFUs, are commonly used.

An SFU receives media streams from each participant and selectively forwards them to others without mixing the media on the server.

A Multipoint Control Unit, or MCU, takes a different approach by mixing audio and video on the server and sending a single composite stream to each participant.

For large-scale systems, Distributed SFU architectures are used, where multiple SFUs forward streams between each other to improve scalability and reduce latency.

Simulcast allows a browser to send multiple video encodings of the same stream at different qualities, enabling better bandwidth usage and adaptive streaming.

WebRTC combines peer-to-peer efficiency with server-assisted reliability to enable real-time communication across real-world networks.

..Read less