DEV Community: Dhruv

My journey optimizing TensorFlow.js to run neural networks directly in the client's browser.

Dhruv — Mon, 01 Dec 2025 08:56:25 +0000

As a computer science student, most of my AI coursework was strictly Python-based. We used PyTorch or TensorFlow in Jupyter notebooks, running on Google Colab GPUs. It was powerful, but it felt disconnected from the web apps I loved building.

For my capstone project, I wanted to bridge that gap. I asked myself: Can I run a neural network directly in the browser, without a backend server?

The Discovery: TensorFlow.js

I stumbled upon TensorFlow.js, a library that lets you define, train, and run models in JavaScript. The coolest part? It uses WebGL to tap into the user's GPU. This means the heavy math of machine learning happens on the client's graphics card, not their CPU.

The Challenge
My first attempt was a simple object detection app using a pre-trained model (COCO-SSD).

Loading the Model: The model files were huge (MBs). Loading them on a slow network took forever.
The Lag: Initial inference took 2-3 seconds. The UI froze.

How I Fixed It
To optimize performance, I learned about:

Quantization: Using smaller, slightly less accurate models (Int8 instead of Float32) to drastically reduce download size.
Warmups: Running a "dummy" prediction through the network when the page loads to compile the WebGL shaders before the user actually interacts with it.

The Result
I built a webcam filter that detects faces in real-time at 30FPS. It was messy, but it worked. It taught me that the future of AI isn't just massive server farms—it's also edge devices and browsers.

Understanding the logic behind 'Chat with PDF' apps by building a Retrieval-Augmented Generation agent manually.

Dhruv — Mon, 01 Dec 2025 08:53:13 +0000

Everyone is talking about "Chat with PDF" apps. I wanted to build one, not by using a wrapper library that hides everything, but by understanding the logic underneath. This is my journey building a RAG (Retrieval-Augmented Generation) agent.

The Problem with LLMs
Large Language Models like GPT-4 are amazing, but they have two flaws:

They don't know my private data.
They hallucinate (make things up) when they don't know the answer.

The Architecture
RAG solves this by giving the LLM a "textbook" to study before answering.

Chunking: I split my document into small paragraphs (chunks).
Embeddings: I used an embedding model (text-embedding-3-small) to turn those text chunks into lists of numbers (vectors). Similar concepts have mathematically similar vectors.
Vector Store: I stored these vectors in a database (I used Pinecone, but a simple local JSON file works for testing).

The Flow
When a user asks: "What is the refund policy?"

I convert that question into a vector.
I search my database for the chunk of text mathematically closest to that question vector.
I find the text: "Refunds are processed within 14 days."
I send a prompt to GPT-4: "Using this context: 'Refunds are processed within 14 days', answer the question: 'What is the refund policy?'"

It felt like magic when it finally worked. The hardest part wasn't the AI—it was cleaning the data before feeding it in!

A breakdown of why MERN is the best starting point for new developers.

Dhruv — Mon, 01 Dec 2025 08:49:23 +0000

In university, we learned Java and C++. When I started looking at web development, the number of choices was overwhelming. Django? Laravel? Spring Boot? Ruby on Rails?

Eventually, I settled on the MERN Stack (MongoDB, Express, React, Node.js). Here is why I think it’s the best choice for new developers in 2024.

1. One Language to Rule Them All
The biggest benefit is Context Switching. In MERN, everything is JavaScript (or TypeScript).
Database query? JSON/JS objects.
Backend logic? JavaScript.
Frontend UI? JavaScript.
I didn't have to mentally switch between Python indentation rules and SQL syntax every 10 minutes. This helped me master the concepts of web dev (HTTP, REST, State) without fighting syntax errors.

2. JSON is Native
MongoDB stores data in BSON, which is basically binary JSON. In React, we consume data as JSON. In Node APIs, we send data as JSON. The data flow is seamless. I didn't need complex ORMs (Object-Relational Mappers) just to read a user profile.

3. The React Ecosystem
React is massive. If I had a problem (e.g., "How to handle form validation"), there were 50 tutorials and 3 libraries for it. As a beginner, having a huge community is a safety net.

Conclusion

Is MERN perfect? No. SQL is often better for complex data relationships. But for building a portfolio and getting hired fast? It’s hard to beat.

Authentication: JWTs vs. Sessions (My Study Notes)

Dhruv — Mon, 01 Dec 2025 08:40:04 +0000

Authentication was the scariest part of my backend journey. I kept hearing terms like "Session Cookies," "JWTs," "OAuth," and "Salting." Here is my attempt to de-mystify JWTs (JSON Web Tokens) based on what I implemented in my recent project.

The Old Way: Sessions

In the past, when you logged in, the server created a "session ID" and stored it in the server's memory. It gave you a cookie with that ID. Every time you clicked a page, the server looked up your ID in its memory.

Problem: If you have 1 million users, that's a lot of memory. If you have 2 servers, you need to sync that memory.

The New Way: JWT (Stateless)

JWTs are like a stamped movie ticket.

Header: "I am a JWT."

Payload: "User ID is 123. Role is Admin."

Signature: A cryptographic stamp signed by the server's secret key.

When I log in, the server creates this string and sends it to me. The server does not save anything.
When I request data later, I show my JWT. The server checks the Signature. If the math works out, it knows the token is real and hasn't been tampered with.

Where to store it?

I learned this the hard way:

LocalStorage: Easy to use, but vulnerable to XSS attacks (hackers running JS on your site can read it).