Forem: Paritosh Parashar

My First Tiny Project: NanoNode 🛠️

Paritosh Parashar — Sat, 16 Aug 2025 13:23:43 +0000

When I started learning Node.js, I realized something: it’s not just about “how to code in Node”, but about understanding how things work under the hood.

To explore that curiosity, I built my very first tiny (assignment-level) project: NanoNode — a mini clone of the Node.js CLI.

You can run:

nanonode path_to_file.js

…and it will execute the file as if you had typed:

node path_to_file.js

👉 (Check it out on npm:)

It’s simple. It’s not “useful” for anyone. But it’s cool because it helped me connect theory and practice in a way that sticks.

🌱 The Spark: Why Do Modules Even Exist?

It all started with a question:
💭 Why is there even a need for a module system in the first place?

Without modules, everything lives in one giant file.
Sharing and reusing code becomes painful.
Modularity makes large systems maintainable.

That naturally led me to:
Why do we have both CommonJS and ES6 modules?

CommonJS was Node’s solution before JavaScript had one.
ES6 modules became JavaScript’s native standard.

Both coexist because tech evolves, but history doesn’t vanish overnight.

🔍 Chasing the Mystery of `module`

When I first saw module.exports, I was confused:

💭 Where does this module object even come from?

It wasn’t in my code. Who put it there?

After digging, I discovered:

-Node.js actually wraps every file in a function (the Module Wrapper).
-That’s why arguments like module, require, exports, __dirname magically exist.
-And that’s why top-level variables are local, not truly global.

Here’s a simplified skeleton of what happens every time you run a file in Node.js:

IIFE - Immediately Invoked Function Expression
(function (exports, require, module, __filename, __dirname) {

  // 👇 Your code goes here
  console.log("Hello World");

  // By default, module.exports = {}
})( // the argument values here);

This also explained why:

Every file can safely have its own module.exports.
require(path) works by
1. Locating the file
2. Wrapping it in this function
3. Executing it
4. Returning module.exports

At that point, I could mentally sketch out how require function also worked internally. Huge “aha!” moment.

🔧 What I Learned by Building NanoNode

To turn this curiosity into something real, I wrote pari.js, a script that mimics Node’s CLI. Along the way, I learned:

Shebang (#!/usr/bin/env node) → lets you run scripts directly, no node prefix needed.
Environment variables & PATH → how your system finds executables when you type a command.
Executable permissions → why chmod +x file matters.
npm publishing → how to make a package installable globally with npm install -g.

All from something that just… runs a file. 😅

Why This Tiny Project Matters

The project itself is tiny. But the learnings were massive:

I now understand how Node bootstraps code under the hood.
I practiced packaging and publishing an npm module.
I learned the difference between local vs truly global scope in Node. -And most importantly: theory became practical because I tied it to a goal.

As Sherlock would say, these learnings are now stored in my Mind Palace 🏰.

👀 What’s Next: A Useful CLI Tool

If NanoNode was my hello-world at the systems level, then my next project is something that actually solves a real problem:

⚡ Snapi: Fast, Lightweight CLI for Testing HTTP Requests

We all use tools like Postman or Insomnia for API testing. They’re powerful, but:

They’re heavy.
They take time to load.
They’re overkill if you just want to test a quick request.

So I thought: Why not build a fast, lightweight, terminal-based request tester?

Something like:

req-test GET https://api.example.com/users

And instantly see:

Response status
Headers
JSON body (pretty-printed)

🎯 Why It Should Exist

Because developers often just need something fast and minimal — no UI overhead, no extra clicks, just type a command and see results.

Lightweight compared to Postman.
Native to the terminal workflow.
Useful for debugging APIs on the fly.

This time, unlike NanoNode, it’s going to be actually useful. 😉

Stay tuned — that’s what my next blog post will be about!

✨ Closing Thought

Building NanoNode taught me that small projects can unlock big insights.

Sometimes you don’t need to build the next unicorn app. Even a tiny utility can push your understanding to the next level.

👉 NanoNode Link

And next time, I’ll share my journey of building Snapi — a CLI Request Tester. Trust me, you’ll actually want to use this one.

Finding the Way: My Backend Dev Journey Begins

Paritosh Parashar — Tue, 05 Aug 2025 17:00:20 +0000

👋 Hello. I’m Paritosh — a bachelor’s student in Computer Science at Universität des Saarlandes, Germany.
This post is both a personal milestone and a public declaration: I'm starting a journey to go deep into backend development and computer science, with full focus and full honesty.

But before I talk about where I’m going, I want to share a bit about where I come from.

🇮🇳 From India to Germany — and Into the Unknown

I moved to Germany from India to study Computer Science.
It wasn't an easy decision. Everything changed — the country, the language, the food, the people, and the education system.

Doing a CS degree in Germany, especially at UdS, is tough. The university has a strong theoretical foundation, and the courses are far from easy.

There were semesters where I questioned everything:

Am I good enough? Am I on the right path?
Everyone seemed to have it figured out. I felt stuck.

Despite that, a few subjects made me feel alive:

System Architecture
Build an 8-bit CPU
Compiler Design
Anything that touches the low-level workings of computers

I’ve attended deep seminars, struggled through tough assignments, and applied to thesis opportunities — because deep down, I know this is where I thrive.

But something was missing.

🤯 Too Much Advice, Not Enough Clarity

Like many of you reading this, I’ve spent hours consuming:

YouTube videos
Twitter threads
Reddit opinions
Blog posts about how to “succeed” in tech

Here’s what I kept hearing:

"Just do DSA."
"Build projects!"
"No, contribute to open source. Or maybe do CP. Or learn AI now!"

It became a mess — a sea of conflicting advice that left me frozen.

So I made a decision: Enough is enough.

🎯 What This Journey Is About

This is a public experiment. A journey I’m sharing openly, with no filters.

I’ve chosen to go deep into backend development, starting with Node.js. My focus is on building creative, meaningful projects — not just to learn, but to grow into a developer people can’t ignore.

Here’s what you can expect:

✅ My Approach:

Project-based learning aligned with a clear backend roadmap

Weekly or milestone-based blog updates

Honest sharing of everything I learn, struggle with, break, or build

A strong focus on:

Performance
Design
Clean Architecture
Debugging & Testing
Scalability

Later on, I also plan to dive into open source.

I’m doing all this while:

Managing my CS degree
Living alone in a foreign country
Searching for my bachelor’s thesis

I’m not doing this because it’s easy — I’m doing it because I know this is where my life turns around.

🤝 Why You Should Follow Along

If you’re someone who’s also:

Tired of shallow advice
Unsure where to focus
Craving depth and clarity

…then you’re not alone.
This blog is for people who want to build deep skills and do meaningful work.

This is not a tutorial blog.
It’s not a success story (yet).
It’s a real, in-progress journey.

Each post will be a snapshot of my:

Progress
Thinking
Failures
Small wins

As I go from confused to dangerously good — I hope you’ll be there too.

🔧 Let’s Go

This is Day 0.
I’m starting with Node.js Fundamentals.

In the next post, I’ll share:

The first project I’m building
What I’m learning
The questions shaping my backend thinking

Let’s see where this goes.
I’m all in.

📬 Stay Connected

Paritosh Parashar
Student|Builder|Backend Explorer

🔗 GitHub • LinkedIn • Dev.to