DEV Community: Prashant Patil

My First Open Source Contribution That Got Merged

Prashant Patil — Wed, 15 Jul 2026 13:17:03 +0000

While searching for my first software engineering role, I wanted experience beyond personal projects. I wanted to understand how real production software is built and maintained.

Open source was the best place to learn, so I started looking for a project where I could make a meaningful contribution.

Finding the Right Opportunity

Like many beginners, I first targeted highly active repositories. One of them was cal.com, where I raised an issue and implemented the fix immediately.

Unfortunately, another contributor's pull request was merged before mine.

Instead of getting discouraged, I decided to look for an issue that better matched my experience and where I could genuinely help.

Eventually, I found the Express Release Status website, a React-based project. One issue caught my attention because it had been opened by one of the maintainers and the requirements were clear.

Working on the Issue

The task was simple on paper: make the Express release timeline clickable.

Instead of jumping straight into coding, I first explored the project structure to understand where the timeline was being rendered.

After locating the relevant React component, I looked at how navigation was already implemented across the application. Rather than introducing a different approach, I wanted my solution to match the existing codebase.

I found that the project used React Router's Link component for internal navigation.

So instead of creating a custom solution or using HTML anchor tags, I followed the same pattern.

The actual code change was surprisingly small. I modified only the lines responsible for rendering the release timeline and wrapped them with the existing routing component.

By keeping the change minimal and focused on the issue, the pull request stayed clean and easy to review.

Practices I Followed

This contribution taught me a few habits that I still follow today:

Understand the codebase before writing code.
Follow the project's existing patterns instead of introducing your own.
Change only what is necessary.
Keep pull requests focused on a single issue.
Respect the review process and respond to maintainer feedback promptly.

Getting the Pull Request Merged

After opening the pull request, the maintainers requested verification before merging it, which I completed.

The pull request then remained open for almost 2–3 months.

During that time, I politely emailed the maintainers to follow up. They responded kindly, and after the review process was complete, my pull request was finally merged.

Seeing that merge notification felt incredibly rewarding because it was my first contribution to a real production project.

What I Learned

This experience taught me that open source isn't about writing the most code—it's about writing the right code.

Small, focused pull requests are easier to review than large ones.

Reading and understanding an existing codebase is just as important as writing new features.

Most importantly, patience matters. Reviews can take weeks or even months, but persistence pays off.

How To Implemented Email OTP Verification in Web Application

Prashant Patil — Sat, 04 Jul 2026 09:32:34 +0000

Email verification has become a standard feature in modern web applications. Whether you're building an e-commerce platform, a social media application, or a job portal, verifying a user's email helps ensure that accounts belong to real users while reducing spam and fake registrations.

During one of my MERN stack projects, I wanted to implement email-based OTP verification. Initially, I had no idea where to start. I knew the feature was important, but I wasn't sure how production applications handled it. So, I spent time researching different approaches, reading documentation, and even asking AI how large companies implement email verification systems.

This article summarizes what I learned and explains the approach I found easiest to implement.

Different Ways to Send OTP Emails

There are several ways to send verification emails from your application.

1. Nodemailer (The Simplest for MERN Applications)

If you're using Node.js, Nodemailer is one of the easiest libraries to integrate. It allows your backend to send emails through providers like Gmail, Outlook, or SMTP servers with very little setup.

For personal projects, learning, or small-scale applications, this is an excellent choice because it requires minimal configuration.

2. Email Service Providers (Recommended for Production)

As I researched further, I found that most large companies don't send emails directly using Gmail. Instead, they use dedicated email delivery services such as:

Amazon SES
SendGrid
Mailgun
Postmark
Brevo (formerly Sendinblue)

These services provide:

Better email deliverability
Higher sending limits
Analytics
Bounce handling
Spam protection
Improved reliability

Many of these services also provide Node.js SDKs, making integration straightforward.

3. SMTP Servers

Another option is connecting your application directly to an SMTP server. Many hosting providers and organizations provide SMTP credentials that applications can use to send emails.

This approach offers more control but usually requires additional configuration.

Why I Chose Nodemailer

Since my project was built using the MERN stack, I found Nodemailer to be the simplest solution.

It integrates seamlessly with Express.js and only requires a few lines of code to send emails. The extensive documentation and large community also make troubleshooting much easier.

For learning purposes and personal projects, I believe this is one of the best ways to understand how email verification works before moving on to enterprise-grade services.

Creating a Google Account and Getting Credentials

To use Gmail with Nodemailer, you'll first need a Google account.

Instead of using your normal Gmail password, Google recommends creating an App Password.

The general process is:

Create or use an existing Google account.
Enable 2-Step Verification on the account.
Navigate to your Google Account security settings.
Generate an App Password.
Use the generated email address and App Password inside your Node.js application.

These credentials allow Nodemailer to securely authenticate with Gmail without exposing your actual account password.

Database Design

While designing the User model, I added a simple field:

isEmailVerified: {
    type: Boolean,
    default: false
}

This field determines whether the user has successfully verified their email address.

Whenever a new account is created, this value remains false until the OTP verification process is completed.

Login Flow

One thing I wanted to avoid was allowing unverified users to access the application.

The login flow works like this:

User enters email and password.
Validate the credentials.
Check the isEmailVerified field.
If the value is true, allow login.
If the value is false, redirect the user to the OTP verification page.

On the OTP page, the user's email is already pre-filled, making the process faster and more user-friendly.

Sending the OTP

When the user clicks the Send OTP button:

Generate a random 6-digit OTP.
Set an expiration time (typically 5–10 minutes).
Send the OTP to the registered email using Nodemailer.

This creates a smooth experience while preventing unnecessary emails from being sent automatically.

Never Store OTPs in Plain Text

One important lesson I learned is that OTPs should never be stored directly in the database.

Instead:

Hash the OTP using a secure hashing algorithm such as bcrypt.
Store only the hashed version.
Keep an expiration timestamp.
Delete or invalidate the OTP after successful verification or expiry.

This ensures that even if someone gains database access, they cannot view users' OTPs.

Verifying the OTP

Once the user enters the OTP:

Retrieve the stored hashed OTP.
Compare the entered OTP with the hashed value.
Verify that the OTP hasn't expired.
If the OTP matches:
- Update isEmailVerified to true.
- Remove the stored OTP.
- Allow the user to continue using the application.
If the OTP is incorrect or expired, ask the user to request a new OTP.

Additional Best Practices

While implementing the feature, I also discovered several practices commonly used in production applications:

Limit the number of OTP requests within a certain time window.
Add a cooldown (for example, 30–60 seconds) before allowing another OTP request.
Set OTP expiration to 5–10 minutes.
Limit incorrect verification attempts.
Log verification events for auditing.
Use HTTPS to protect data during transmission.
Prevent brute-force attacks with rate limiting.

These measures improve both security and user experience.

What I Learned

Before implementing this feature, I assumed email verification would be difficult. After researching multiple approaches, I realized the overall concept is actually straightforward once you understand the authentication flow.

For my MERN stack application, Nodemailer turned out to be the easiest solution because it integrates naturally with Node.js and Express. Later, I also learned that larger companies usually rely on dedicated email services like Amazon SES or SendGrid for better scalability and reliability.

If you're building your first full-stack application, implementing email OTP verification is a great way to strengthen your understanding of authentication, backend development, database design, and application security. Once you understand the fundamentals, transitioning to enterprise-grade email providers becomes much easier.

Building GitHub-Inspired Version Control and Forking Without Duplicating Project Files

Prashant Patil — Thu, 18 Jun 2026 03:21:44 +0000

One of the challenges I faced while building my LaTeX Writer project was implementing version control and project forking in a storage-efficient way.

A typical LaTeX project contains multiple files. Even a simple project usually has a "main.tex" file, bibliography files, images, style files, and other supporting documents. If I stored a complete copy of every file for every version or fork, storage requirements would grow rapidly.

Imagine a project with four files and ten versions. Storing the entire project for every version would mean storing the same files repeatedly, even when only one line changed. Forking would create an even bigger problem because every fork would require another complete copy of the project.

Instead of accepting this inefficiency, I started researching how large platforms solve the same problem. GitHub was the obvious inspiration.

Learning from GitHub

GitHub does not store a complete copy of a repository every time a change is made. Instead, it stores content separately and uses references to connect files, commits, and repositories.

This idea became the foundation for my own implementation.

Project Structure

Whenever a new project is created, a default file called "main.tex" is generated automatically.

The project itself does not directly contain file contents. Instead, it stores metadata such as:

Project ID
Owner ID
Root Folder ID
File References

Each file also has its own metadata record containing:

File ID
File Name
Blob ID
Project ID
Owner ID
Folder ID

The actual content is not stored inside the file metadata.

Instead, the content lives inside a separate entity called a Blob.

Loading a Project

When the editor loads a project, it reconstructs the directory structure using metadata.

The process works like this:

Retrieve the project's Root Folder ID.
Find all folders belonging to that folder hierarchy.
Find all files belonging to each folder.
Build the directory tree for the frontend.

Because files and folders are stored independently, the entire project structure can be recreated efficiently without duplicating data.

Blob-Based Content Storage

The most important optimization is the Blob system.

A Blob represents the actual content of a file.

When a user edits a file:

The content is hashed.
A unique Blob ID is generated.
If a Blob with identical content already exists, the existing Blob is reused.
The file metadata simply points to the appropriate Blob.

This means identical file contents are stored only once, regardless of how many files, versions, or forks reference them.

How Forking Works

Forking was designed with the same principle.

When a user forks a project:

A new Project ID is created.
New file metadata records are created.
New folder metadata records are created.
Ownership information changes to the new user.

However, the file content is not copied.

The new file metadata points to the exact same Blob IDs as the original project.

As a result, a fork initially consumes very little additional storage because only metadata is duplicated.

What Happens When a Fork Is Edited?

Suppose User A creates a project and User B forks it.

Initially, both projects reference the same Blobs.

If User B edits a file:

The updated content is hashed.
The system checks whether a Blob with that content already exists.
If it exists, the existing Blob is reused.
If it does not exist, a new Blob is created.
User B's file metadata is updated to point to the new Blob.

The original project remains unchanged because its file metadata still points to the old Blob.

This creates behavior similar to Git's object storage model while keeping storage usage minimal.

The Result

By separating metadata from content and introducing Blob-based storage, I achieved:

Efficient version management
Storage-friendly project forking
Content deduplication
Faster project cloning
Reduced database growth
GitHub-inspired architecture without implementing Git itself

Instead of storing the same file hundreds of times, the system stores content once and uses references everywhere else.

This approach allows the platform to scale much more efficiently while supporting features like version history, project cloning, and collaborative workflows.

How Google AI Mode Works (Simple Explanation)

Prashant Patil — Tue, 12 May 2026 15:34:30 +0000

Google AI Mode is a new way of searching on Google where Artificial Intelligence (AI) gives direct answers instead of only showing a list of websites.

Normally, when you search something on Google, you see many blue links. You open different websites to find your answer. But in AI Mode, Google itself reads information from many websites and creates a smart answer for you.

It works more like talking to an AI assistant.

For example, if you search:

“Best laptop for coding under ₹60,000”

AI Mode may directly give:

Recommended laptops
Features comparison
Pros and cons
Buying suggestions
Links to websites for more details

Instead of making you open 10 different pages.

How Google AI Mode Generates Results

Google AI Mode works in multiple steps.

Step 1: Understand Your Question

The AI first tries to understand:

What you are asking
Your intent
Important keywords
Context of the question

For example:
"Best protein for skinny beginners"

Google understands:

User is probably trying to gain muscle
User is beginner
User wants protein recommendations

Step 2: Search the Internet

Then Google searches across:

Websites
Blogs
Forums
Product pages
Reviews
News articles

Google already has one of the biggest search indexes in the world. AI Mode uses this huge database.

Step 3: AI Reads and Combines Information

The AI model reads information from multiple sources and combines them into a single answer.

Instead of showing:

Website A
Website B
Website C

It creates one summarized response.

This is called:

AI-generated summary
AI overview
Generative search result

Step 4: Ranking and Verification

Google still uses its traditional ranking systems:

Website authority
Quality
Trustworthiness
Freshness of content

This is important because AI alone can sometimes generate wrong information.

So Google combines:

Traditional search ranking
AI language models

Together.

Step 5: Showing Follow-Up Suggestions

After giving an answer, AI Mode often suggests:

Related questions
Follow-up searches
Product comparisons
Deeper explanations

This keeps the search conversational.

How is Google AI Mode Different From Gemini?

Many people think Google AI Mode and Google Gemini are the same thing. But they are different.

Google AI Mode	Gemini
Built inside Google Search	Separate AI assistant
Focused on web search	Focused on conversation and tasks
Uses live search results heavily	Can answer from training knowledge too
Shows website links with answers	More chatbot-style
Better for finding information online	Better for brainstorming, writing, coding

Difference Between Google AI Mode and Other AI Chatbots

Google AI Mode vs ChatGPT

Google AI Mode	ChatGPT
Search-focused	Conversation-focused
Uses real-time web search	Depends on tools/web access
Best for finding latest info	Best for explanations and creativity
Gives source links	Can explain concepts deeply

Google AI Mode vs Perplexity

Perplexity AI is actually very similar to Google AI Mode.

Both:

Search the web
Summarize information
Give AI answers
Show sources

The biggest difference is:
Google combines AI with its existing search engine, while Perplexity is built mainly as an AI-first search platform.

Is Google AI Mode Always Correct?

No.

Sometimes AI Mode can:

Misunderstand questions
Give outdated information
Mix incorrect facts
Create "hallucinations" (fake information)

That is why Google still provides website links below the AI answer.

You should still verify important information, especially for:

Medical advice
Financial decisions
Legal topics
Technical accuracy

Final Thoughts

Google AI Mode is basically Google Search mixed with AI conversation.

Instead of only showing websites, it:

Understands your question
Searches the web
Reads multiple sources
Creates a summarized answer
Lets you continue asking questions

It is making search faster and more interactive.

But it is not replacing websites completely. It still depends heavily on information created by websites and content creators across the internet.

The SQL Mistake Everyone Makes: Writing vs Execution Order

Prashant Patil — Mon, 06 Apr 2026 18:25:40 +0000

When I first started learning SQL, my approach was very straightforward. I would begin with the SELECT statement, list the columns I wanted, add the FROM clause, and then shape the query based on the problem.

This worked well for simple queries. However, as problems became more complex, I repeatedly ran into the same issue: I had to rewrite queries from scratch because of small mistakes. This wasted time and slowed down my progress.

The Problem

The core issue was simple — I was writing SQL in the order it appears, not in the order it executes.

Because of this, I:

Applied filters at the wrong stage
Misused aggregate functions
Got incorrect results
Rewrote queries multiple times

The Turning Point

While watching a developer solve multiple SQL problems, I noticed a pattern:

They rarely rewrote queries
They followed a structured flow
They thought in terms of execution

That is when I realized:

SQL is not executed in the order we write it.

Understanding this changed everything.

SQL Execution Order

The actual execution order of SQL is:

FROM
WHERE
GROUP BY
HAVING
SELECT
DISTINCT
ORDER BY
LIMIT

Each step transforms the data before passing it to the next stage.

Clause Breakdown

FROM

Selects the base table and performs joins.

WHERE

Filters rows before grouping.

GROUP BY

Groups rows based on column values.

HAVING

Filters grouped data.

SELECT

Chooses columns and applies calculations.

DISTINCT

Removes duplicates.

ORDER BY

Sorts results.

LIMIT

Restricts number of rows returned.

Example

Table: orders

order_id	customer	amount	city
1	A	100	Pune
2	B	200	Mumbai
3	A	150	Pune
4	C	300	Delhi
5	B	250	Mumbai

Problem

Find total order amount per city where total > 200 and sort descending.

Query

SELECT city, SUM(amount) AS total_amount
FROM orders
WHERE amount > 100
GROUP BY city
HAVING SUM(amount) > 200
ORDER BY total_amount DESC;

Execution Walkthrough

Step 1: FROM

All rows are selected.

Step 2: WHERE

Filter amount > 100.

Remaining rows:

Mumbai: 200, 250
Pune: 150
Delhi: 300

Step 3: GROUP BY

Groups formed:

Mumbai
Pune
Delhi

Step 4: HAVING

Filter groups:

Mumbai (450) -> keep
Pune (150) -> remove
Delhi (300) -> keep

Step 5: SELECT

Result:
| city | total_amount |
|--------|-------------|
| Mumbai | 450 |
| Delhi | 300 |

Step 6: ORDER BY

Sorted descending:

Mumbai
Delhi

Key Takeaway

Do not think in terms of writing SQL.

Think in terms of execution.

This will:

Reduce errors
Improve speed
Help solve complex queries

Conclusion

Understanding SQL execution order is a fundamental skill. Once you start thinking in execution steps instead of syntax order, your ability to write efficient and correct queries improves significantly.

Why Deleting `node_modules` Takes Forever on Windows

Prashant Patil — Sat, 21 Mar 2026 16:56:18 +0000

A few days ago, I was deleting a project when something unexpectedly frustrating happened — it took way too long.

Not seconds. Not even a minute. It just kept going.

If you’ve worked with JavaScript projects, you already know the culprit: node_modules.

That moment got me thinking. Since I’ve been studying operating system fundamentals, I wanted to understand what’s actually happening behind the scenes. Why does a simple delete operation take so long?

So I went down the rabbit hole — digging through documentation, GitHub discussions, and system-level explanations. I even explored how Linux handles file deletion to compare behaviors.

Here’s what I found.

The Real Reason Isn’t Just “Too Many Files”

Yes, node_modules contains thousands of files — sometimes hundreds of thousands.

But that’s only part of the story.

The real reason deletion is slow on Windows comes down to how the operating system handles:

File system operations
Security checks
Path resolution
File locking

Let’s break it down.

1. Windows Deletes Files One by One

Unlike what many people assume, Windows does not delete folders in bulk.

Instead, it:

Traverses every directory
Deletes each file individually
Updates metadata for every operation

Now imagine doing that for 100,000+ files.

That alone creates noticeable delay.

2. File Locking Adds Extra Overhead

Windows uses a strict file locking mechanism.

Before deleting a file, it:

Checks whether the file is in use
Verifies parent directories
Temporarily locks parts of the directory structure

If anything is being accessed — even indirectly — the system slows down or retries the operation.

This adds friction, especially in deeply nested folders like node_modules.

3. Windows Defender Is the Biggest Bottleneck

This is where most of the time actually goes.

Windows Defender scans files not just when they’re created or opened — but also when they’re deleted.

That might sound unnecessary, but there’s a reason.

Malware can:

Create harmful files
Execute them
Delete them quickly to avoid detection

To prevent this, Windows scans files during deletion as well.

In many cases, 60–70% of the total deletion time is spent on Defender scans alone.

4. Long File Paths Make Things Worse

node_modules often contains deeply nested dependencies.

This leads to extremely long file paths.

Windows has historically had a path length limit (~260 characters). Even though modern systems support longer paths, many tools still struggle with them.

When paths exceed limits:

Operations can fail
Windows retries them silently
Additional time is wasted

5. NTFS File System Overhead

Windows uses the NTFS file system, which prioritizes reliability and consistency.

For every file deletion, NTFS:

Updates logs
Maintains metadata
Ensures file system integrity

Doing this for thousands of files significantly slows things down.

How Linux and macOS Handle It Differently

Unix-based systems take a much simpler and faster approach.

They:

Avoid heavy antivirus scanning during deletion
Use more efficient file unlinking mechanisms
Have fewer restrictions on file paths
Use a more flexible file locking model

The result is a noticeable difference in performance.

Quick Comparison

Aspect	Windows (NTFS)	Linux/macOS (ext4/APFS)
File Deletion	File-by-file with checks	Faster unlinking
Antivirus	Scans during deletion	Typically no scan
Path Limits	Historically restrictive	More flexible
File Locking	Strict	More relaxed
Performance on `node_modules`	Slow	Significantly faster

Why Windows Prioritizes Safety

At this point, it’s fair to ask: why does Windows do all this?

The answer is simple — security.

Without these checks:

Malware could create and delete files instantly
Those files might never be scanned
The system could be compromised silently

So while it feels inefficient, it’s a deliberate design decision.

Can You Speed It Up?

Yes — but every shortcut comes with trade-offs.

Some practical options:

Use tools like rimraf for faster deletion
Enable long path support in Windows
Use WSL (Windows Subsystem for Linux) for development workflows
Avoid reinstalling dependencies unnecessarily

You can also disable real-time antivirus scanning temporarily, but that introduces risk and isn’t advisable for regular use.

Final Thoughts

Deleting node_modules slowly on Windows isn’t a bug — it’s the result of intentional system design.

Windows favors safety and control.

Unix-based systems favor speed and simplicity.

Once you understand that trade-off, the behavior makes a lot more sense — even if it’s still frustrating.