Forem: Md Mohosin Ali Shah

RepoLens Version 2 Ranked #7 on Product Hunt — Building AI for Code Change Intelligence

Md Mohosin Ali Shah — Sun, 29 Mar 2026 08:54:57 +0000

RepoLens Version 2 ranked #7 on Product Hunt this week.

That number was exciting, but what mattered more to me was what it represented.

It felt like a signal that this problem resonates with more people than just me.

Because RepoLens started from a frustration I kept running into again and again:

understanding a codebase takes too long.

When I opened a new repository, I would usually go through the same cycle:

open random folders
search for routes
trace imports manually
guess how modules fit together
try to understand the architecture from scattered files and tribal knowledge

That process was slow, repetitive, and mentally expensive.

So I built RepoLens Version 1 to solve that.

Version 1 was about helping developers understand a repository faster.

It could analyze repositories, detect stack and structure, map modules and dependencies, extract API endpoints, generate docs, support grounded repository chat, compare branches, and turn a codebase into something much more explorable.

That solved an important problem.

But while building it, I realized I had only solved the first half of the real pain.

Understanding a Repository Once Is Not Enough

A repository is not static.

It keeps moving.

Pull requests change behavior.

Endpoints shift.

Dependencies evolve.

Architecture drifts.

And teams are constantly trying to answer a harder question:

what changed, what was affected, and what actually matters?

That is where RepoLens Version 2 came from.

Version 2 is not just about repository understanding.

It is about change intelligence.

That shift changed how I thought about the product.

Instead of only helping someone understand a repository once, I wanted RepoLens to become useful inside the real engineering loop:

when a pull request opens
when a branch changes
when APIs move
when architecture starts drifting
when a team needs clarity before review or release

What Changed in Version 2

RepoLens Version 2 now focuses on helping teams understand change with more structure and more trust.

It can now:

analyze pull requests and generate engineering summaries
detect affected modules
detect changed endpoints
highlight likely review hotspots
support branch-aware and PR-aware repository chat
show exact code snippet references and confidence signals
run incremental analysis instead of full rebuilds every time
sync automatically from GitHub events
detect architecture drift
send alerts for important changes and failed analysis runs
track workspace usage and operational health

The product story became much clearer through this work:

Version 1: Know any repo fast
Version 2: Know what changed and what matters

That clarity was one of the biggest wins for me as a builder.

What I Learned Building It

One of the biggest lessons from building RepoLens is that generic AI output is not enough for engineering workflows.

It is easy to generate a summary.

It is much harder to generate something that engineers can actually trust.

That means the system has to do more than just “talk about code.”

It has to first build a structured understanding of the repository and its changes, then use AI on top of that structure to make the output more useful, grounded, and verifiable.

That has shaped almost every product decision in RepoLens so far.

I do not want RepoLens to be another tool that gives impressive-sounding answers without enough proof behind them.

I want it to help teams see:

where an answer came from
what changed
what was affected
what deserves attention

The Product Hunt Launch

Launching RepoLens Version 2 on Product Hunt and seeing it reach #7 was encouraging not just because of visibility, but because of the kinds of conversations it created.

The most interesting feedback was not about “AI” in the abstract.

It was about very practical engineering questions:

How do you handle overlapping PRs?
How reliable is changed endpoint detection?
Can this work beyond a single framework?
Which signals are actually useful in day-to-day development?

That is exactly the kind of feedback I hoped for.

It means the product is starting to move from “interesting demo” territory into “could this fit real engineering workflows?” territory.

That is the transition I care about most.

Where RepoLens Is Going

RepoLens started as a way to understand repositories faster.

Now it is becoming a way to understand change faster.

That feels like the more important problem.

Because teams do not just need help reading code.

They need help reasoning about evolving systems.

That is what I want RepoLens to keep getting better at.

RepoLens Version 2 - Know what changed and what matters

Md Mohosin Ali Shah — Wed, 25 Mar 2026 17:30:00 +0000

RepoLens Version 1 was about understanding a repository quickly.

It helped answer:
What is in this repository?
How is the codebase structured?
Where do I start?

But after building and using it more, I realized something important:

understanding a codebase once is not enough.

Repositories keep changing.
Pull requests introduce risk.
APIs evolve.
Architecture drifts.
And teams need better visibility into what changed, what was affected, and what actually matters.

So I built RepoLens Version 2.

RepoLens is no longer just a repository analysis dashboard.
It is becoming a change intelligence platform for engineering teams.

What RepoLens V2 Adds

RepoLens can now:

analyze pull requests and generate engineering summaries

show affected modules, changed endpoints, and likely review hotspots

run incremental analysis instead of reprocessing the whole repository every time

sync automatically from GitHub push, PR, and merge events

answer chat questions in repository, branch, PR, and branch-compare context

show exact code snippets, references, and confidence signals in chat answers

detect architecture drift and endpoint changes over time

send alerts for meaningful changes and failed analysis runs

track workspace usage, plan limits, and operational health

What This Changes

Version 1 helped understand a repository.

Version 2 helps understand change.

That means RepoLens starts becoming useful in everyday engineering workflows, not just onboarding.

For example:

reviewing pull requests

tracking architecture changes across runs

seeing what modules and endpoints were affected

understanding branch differences faster

getting grounded answers in the exact context you care about

receiving alerts instead of checking manually

Product Direction

The RepoLens product story is becoming clearer:

Version 1: Know any repo fast.
Version 2: Know what changed and what matters.

That shift is the part I’m most excited about.

RepoLens is moving from static repository understanding
to ongoing engineering intelligence.

Live Platform
https://repolensai.com

Open Source Repository

The open-source analysis engine is available here:

https://github.com/mohosin2126/repolens-community

Version 2 LinkedIn Post
https://www.linkedin.com/posts/mohosin2126_opensource-ai-github-activity-7442612868300234752-HWkc?utm_source=share&utm_medium=member_desktop&rcm=ACoAADpg8RMBJaipaeKrpBc7xSoC8S90bR4HWpk

Why I Built Version 2

I wanted RepoLens to be useful not only when someone first opens a repository,
but also when a team is actively changing it.

Especially when:

reviewing pull requests

tracking risky changes

watching API and architecture evolution

keeping teams aligned as systems grow

Open Core

RepoLens continues to follow an open-core model.

The reusable analysis engine remains open source, while the hosted platform builds on top of it with collaboration, change intelligence, notifications, workspace controls, and premium product features.

I Shipped v0.3.0 of My Open Source Project Scaffolding CLI

Md Mohosin Ali Shah — Wed, 18 Mar 2026 01:03:49 +0000

A few days ago, I published my open source npm package: starter-structure-cli.

It’s a Node.js CLI that scaffolds production-ready starter projects from simple stack tokens.

You can run something like:

npx starter-structure-cli my-app react vite ts tailwind express prisma postgres

and get a structured project generated for you instead of spending hours wiring everything manually.

Since publishing it, I’ve been improving it quickly, and today I shipped v0.3.0.

What made this update especially exciting for me is that the package also started getting real usage.

From March 3, 2026 to March 9, 2026, it got 480 downloads.
In the following week, it got 35 more downloads.
That brings it to 515 total downloads across the last two weeks.

It’s still early, but seeing people actually try something I built has been genuinely motivating.

What `starter-structure-cli` does

The goal is simple:

Start coding faster without repeating the same setup work again and again.

Instead of manually creating folder structures, wiring frontend and backend pieces together, setting up ORM config, styling, auth, and other repetitive boilerplate, the CLI gives you a working baseline from the stack you choose.

It currently supports technologies like:

React
Next.js
Vue
Vite
Tailwind CSS
shadcn/ui
Express
NestJS
Prisma
Mongoose
Sequelize
MongoDB
MySQL
PostgreSQL
JWT
NextAuth

And it organizes templates across these project types:

Single App
Frontend-only
Backend-only
Fullstack
Monorepo
Turbo Monorepo

With v0.3.0, the catalog now supports 36 production-ready starter templates.

What’s new in v0.3.0

This release focused on three things:

expanding the template catalog
cleaning up the CLI internally
strengthening release quality

New starters added

I added several new templates, including:

Fastify + Prisma + PostgreSQL backend starter
Next.js + TypeScript + shadcn/ui + Tailwind starter
React/Vite + Prisma + PostgreSQL fullstack starter
Vue/Vite + Prisma + PostgreSQL fullstack starter
additional backend, single-app, and fullstack combinations

That pushed the catalog to 36 starter templates.

A cleaner CLI internally

One of the biggest improvements in this release was refactoring the CLI into smaller, more maintainable modules.

I split the logic into separate parts for things like:

argument parsing
catalog discovery
template matching
prompts
scaffolding
constants and aliases

This made the codebase easier to understand and easier to extend as the number of templates keeps growing.

That cleanup mattered a lot, because once a scaffolding tool starts supporting many combinations, the matching and discovery flow can become messy very quickly.

I wanted to improve that before continuing to add more starters.

Stronger validation before release

I also improved the validation and release checks.

The project now verifies things like:

referenced bases and layers actually exist
built template outputs are valid
expected files are present
template integrity is preserved before publishing
release quality is more consistent

That gave me much more confidence when shipping updates to npm.

When a project becomes template-driven and composable, validation stops being optional very quickly.

Why I’m building this

I built this because I kept running into the same problem:

Every time I started a new project, I spent too much time on setup before I could start building the real thing.

Not just creating folders, but also:

organizing frontend and backend structure
connecting stack pieces together
configuring database tooling
choosing a maintainable baseline
reusing and cleaning up old boilerplate

I wanted a tool that could take simple stack words and give me a serious starting point.

Not a toy template.
Not an empty folder structure.
A real baseline that someone could actually continue building on.

Example usage

Interactive mode:

npx starter-structure-cli my-app

Natural stack-token mode:

npx starter-structure-cli my-app react vite ts tailwind express prisma postgres

List available templates:

npx starter-structure-cli --list

What I learned from shipping this

A few things became very clear while working on this release.

1. Template quality matters more than template count

Adding more starters is useful, but only if the generated output actually feels worth building on.

2. Validation becomes essential very quickly

As soon as templates become composable, release-time checks become necessary.

3. Internal cleanup is part of shipping

Adding features is exciting, but maintainability work is what keeps the project from collapsing under growth.

4. Real users change how you think

Once people start downloading a package, small details start to matter more:

naming
docs
consistency
output quality
error handling
discoverability

What’s next

I want to keep improving:

template coverage
matching quality
documentation
generated project quality
the contributor experience for adding new starters

I also want to make template authoring easier over time so the project can grow in a cleaner way.

Try it

npx starter-structure-cli my-app

GitHub: https://github.com/mohosin2126/starter-structure-cli
npm: https://www.npmjs.com/package/starter-structure-cli

If you try it, I’d genuinely love feedback on:

which stacks you want next
how useful the generated structure feels
what would make a tool like this part of your workflow

I Built a Tool That Turns GitHub Repositories Into Architecture Dashboards - RepoLens Version 01

Md Mohosin Ali Shah — Thu, 12 Mar 2026 15:32:08 +0000

RepoLens (Version 1) - Know any repo fast.

Understanding a new codebase is one of the hardest parts of software development.

You open a repository and immediately face questions like:

How are modules structured?
Which components depend on each other?
What APIs exist?
What does the architecture actually look like?

Developers often spend hours reading files just to understand the structure of a project.

So I built RepoLens.

RepoLens Version One analyzes GitHub repositories and turns them into a structured architecture dashboard.

Instead of manually exploring folders, you get:

module mapping
dependency graphs
API endpoint discovery
generated architecture documentation
repository chat grounded in code

Live Platform

https://repolensai.com

Open Source Repository

The open-source analysis engine is available here:

https://github.com/mohosin2126/repolens-community

What RepoLens V1 Does

RepoLens runs an analysis pipeline that:

Clones the repository
Scans project files
Detects languages and frameworks
Parses modules and dependencies
Extracts API routes
Generates architecture summaries
Generates project overview and onboarding docs
Persists structured analysis results for each run
Builds semantic chunks from repository content
Generates embeddings for retrieval and search
Grounds repo chat answers in indexed source files
Tracks branch-specific analysis history
Compares branches across key architecture signals
Exports reports and comparison results

Tech Stack

Node.js
Express
MySQL
Prisma
Redis
BullMQ
React
TypeScript
ts-morph
React Flow

Why I Built It

I wanted a tool that helps developers understand large repositories faster.

Especially when:

joining a new project
reviewing unfamiliar codebases
exploring open source projects
onboarding new developers

Open Core

RepoLens follows an open-core model.

The reusable repository analysis engine is open source, while the hosted platform builds on top of it with the full product experience.

I Built a CLI That Scaffolds 30+ Fullstack Projects From Natural Language

Md Mohosin Ali Shah — Sat, 07 Mar 2026 19:47:24 +0000

Ever typed something like this and wished it just worked?

npx starter-structure-cli my-app react vite ts tailwind express prisma mysql

Well, now it does. I built starter-structure-cli an open source Node.js CLI that generates production-ready starter projects from stack tokens you type in plain English.

The Problem

Every time I started a new project, I'd spend hours:

Setting up folder structure
Wiring up the frontend to the backend
Configuring ORMs, auth, styling
Copy-pasting boilerplate from old projects

I wanted one command that just gives me a working project with my exact stack.

What It Does

npx starter-structure-cli my-app

That's it. You get an interactive prompt that walks you through picking your stack. Or skip the prompts entirely:

npx starter-structure-cli my-app react vite ts tailwind express prisma mysql

It ships with 30+ templates across 6 categories:

Category	Example
Single App	`react-vite-ts-tailwind`
Frontend-only	`react-admin-dashboard`
Backend-only	`express-prisma-mysql-jwt`
Fullstack	`react-vite-ts-tailwind-express-prisma-mysql`
Monorepo (Client/Server)	`nextjs-express-prisma`
Monorepo (Turbo + pnpm)	`nextjs-api-nestjs-prisma`

Stacks covered: React, Next.js, Vue, Vite, Tailwind CSS, shadcn/ui, Express, NestJS, Prisma, Mongoose, Sequelize, MongoDB, MySQL, PostgreSQL, JWT, NextAuth — and growing.

The Cool Parts

1. Natural Language Matching

You don't need to memorize template names. Just throw stack words at it:

npx starter-structure-cli my-app reactjs tailwind css nodejs prisma mysql

The CLI normalizes aliases automatically:

reactjs → react
tailwindcss → tailwind
typescript → ts
next → nextjs

It even ignores filler words like with, project, app, and css.

2. Composable Template System

Templates aren't just static folders. They're built from composable layers:

template-sources/
  bases/       → shared project skeletons
  layers/      → stack-specific overlays
  presets/     → final template definitions (JSON)
  components/  → reusable snippets (package.json, README, styles)

A preset JSON file defines how layers compose:

{
  "output": "templates/fullstack/react-vite-ts-tailwind-express-prisma-mysql",
  "base": ["bases/fullstack/react-vite-ts-tailwind-express"],
  "layers": ["layers/backend-only/prisma-mysql"],
  "variables": { "DB": "mysql" }
}

This means adding a new database variant is just a new 5-line JSON preset — not a whole new template folder.

The system also supports {{ include: }} directives with cycle detection, so templates can reference shared snippets without infinite loops.

3. Interactive + Non-Interactive

Fully interactive with @clack/prompts:

npx starter-structure-cli my-app
# → Pick category → Pick stack options → Generate

Or fully automated for CI/scripts:

npx starter-structure-cli my-app \
  --category fullstack \
  --frontend react \
  --backend express \
  --orm prisma \
  --database mysql \
  -y

4. Smart Defaults

If both JS and TS variants exist, TypeScript is preferred unless you pass --language js
__APP_NAME__ placeholders are replaced in file names, folder names, and file contents
Auto-installs dependencies with --install (supports npm, pnpm, yarn)

Generated Project Structures

Fullstack:

my-app/
  client/    → React/Vue/Next.js frontend
  server/    → Express/NestJS backend

Monorepo (Turbo):

my-app/
  apps/
    web/     → frontend
    api/     → backend

Templates include starter structure for components, routes, hooks, services, controllers, and data modules — not just empty folders.

How I Built It

The entire CLI is built with:

Pure Node.js (ES Modules, zero build step)
@clack/prompts — beautiful terminal UI
picocolors — lightweight terminal colors
A custom template build pipeline that composes presets at publish time

The architecture is intentionally simple. No frameworks, no bundlers, no compilation. Just Node.js doing what it does best — file system operations and CLI parsing.

Try It

npx starter-structure-cli my-app

Or browse the templates:

npx starter-structure-cli --list

GitHub: github.com/mohosin2126/starter-structure-cli
npm: npmjs.com/package/starter-structure-cli

Star it if you find it useful ⭐ and feel free to open issues or contribute new templates!

What a monorepo needs (the real requirements)

Md Mohosin Ali Shah — Wed, 25 Feb 2026 15:35:57 +0000

A good monorepo package manager should handle:

Workspaces (multiple packages/apps)
Fast installs for big repos
Deterministic lockfile (same deps everywhere)
Good CI caching
Minimal “dependency weirdness” (phantom deps, hoisting surprises)
Good developer workflow (run scripts across packages, filtering, etc.)

pnpm in monorepos (why it’s usually best)

1) Speed (especially after first install)

pnpm keeps a global content-addressable store (one copy of each package version).
Each project uses hardlinks into node_modules. Result: repeated installs are very fast, and huge monorepos benefit a lot.

2) Disk usage (big win)

With npm, each workspace can duplicate the same packages across subprojects.
With pnpm, packages are reused from the store. Result: smaller repo footprint and faster docker/CI layers.

3) Strict dependency isolation (less “hidden bugs”)

pnpm is strict:
If package-a doesn’t declare lodash in its package.json, it can’t import it just because some other package installed it.

This prevents the classic monorepo bug:

“It worked on my machine because it was hoisted… but CI broke later.”

4) Workspace tooling feels made for monorepos

pnpm has very ergonomic workspace commands:

run scripts across all packages
filter to run on only affected packages
recursive installs/builds are clean

5) CI caching is usually better

Because pnpm’s store is reusable, caching is simpler and more effective.

In many CI pipelines, pnpm installs become consistently faster after the first cached run.

Best for:
New monorepos, medium/large repos, teams that care about correctness and speed, TurboRepo/Nx repos.

npm in monorepos (when it’s still a good choice)

1) Maximum compatibility / minimum friction

npm ships with Node by default.
Some older tools and scripts assume npm-style hoisting behavior. That makes npm “boring and safe” in some enterprise setups.

2) Simpler mental model for some teams

If the team already knows npm and the repo is small-ish, npm workspaces can be “good enough.”

3) Fewer edge cases with legacy tooling

pnpm’s strictness can expose issues in older packages that assumed hoisting.
That’s not pnpm’s fault—it’s correctness—but it can create migration work.

Best for:
Legacy repos, very strict “no new tooling” policy, or ecosystems with fragile dependencies.

Key Differences (quick but important)

Dependency layout

npm: often hoisted dependencies (deps can appear available even if not declared)
pnpm: uses a symlinked structure that enforces correctness

Bug prevention

pnpm catches missing dependencies earlier
npm may hide missing dependency problems until later

Performance

pnpm usually wins for bigger repos and repeated installs

Recommendation (simple decision guide)

Pick pnpm if you want:
fast installs
lower disk usage
fewer “phantom dependency” bugs
best monorepo ergonomics

Pick npm if you want:
maximum compatibility
simplest onboarding (no extra tool install)
legacy tooling expectations

My default in 2026: pnpm for almost every new monorepo.

Best-practice setup (works great)

If you choose pnpm, do this:

Keep one lockfile at repo root
Use pnpm workspaces
Add a pinned version for consistency across the team

Example idea (conceptual):

root package.json with "packageManager": "pnpm@X.Y.Z"
pnpm-workspace.yaml listing packages like:
- apps/*
- packages/*

365 Days, 2,010 Contributions: What I Learned from a Year of Zero Missed Days

Md Mohosin Ali Shah — Sun, 04 Jan 2026 05:30:21 +0000

In 2025, I made a silent promise to myself: Show up. No matter how I felt, no matter how busy the day was, I committed to pushing my craft forward every single day. Today, looking back at the green squares on my GitHub profile, the numbers tell one story, but the growth tells another.

The Stats

Days Commited: 365 / 365
Total Contributions: 2,010
Days Missed: 0
GitHub Handle: @mohosin2126

Beyond the Green Squares

While the GitHub contribution graph is a great motivator, it only scratches the surface. In the beginning, I was focused on the "streak." But as the months progressed, the focus shifted from quantity to quality.

I realized that 2,010 contributions aren't just lines of code; they are 2,010 moments of problem-solving, debugging, and architectural decision-making.

The Projects That Defined My Year

My year was largely defined by three major pillars:

@codethinker (Primary Focus): This has been my main driver. Building and scaling this project required me to move beyond basic implementation and think deeply about user experience and system reliability.
@orbillo & @perkoxofficial: Contributing to these organizations allowed me to collaborate and understand different codebases, which is essential for any developer looking to grow.

What I Learned When I Refused to Take a Day Off

1. Logic Over Syntax

When you code every day, syntax becomes second nature. This frees up your brain to focus on the truly hard parts: logic and architecture. I found myself spending more time planning my approach and less time looking up documentation for basic functions.

2. The Power of "Non-Zero" Days

There were days when I didn't feel like a "rockstar." There were days when I was tired or stuck. But I learned the value of the "Non-Zero Day." Even a small refactor or a documentation update keeps the momentum alive. Consistency beats intensity every single time.

3. Architecture is a Mindset

By maintaining a year-long streak, I was forced to live with my own code for 365 days straight. Nothing teaches you the importance of clean, maintainable architecture quite like having to fix a bug in code you wrote six months ago during a "daily streak" rush.

Looking Ahead

If 2025 was about discipline, 2026 will be about depth. I want to take the consistency I’ve built and apply it to even more complex architectural challenges and open-source contributions.

To anyone thinking about starting their own streak: Don't wait for the perfect moment. Just start. The growth happens in the struggle, not the success.

Let’s Connect!

GitHub: mohosin2126
Projects I'm working on: @codethinker, @orbillo, @perkoxofficial

How do you stay consistent in your coding journey? I’d love to hear your thoughts in the comments!

Primary Key vs Foreign Key: A Complete Guide for Developers

Md Mohosin Ali Shah — Mon, 29 Sep 2025 16:21:09 +0000

Relational databases power everything from small web apps to enterprise-grade systems. At the heart of relational database design are Primary Keys and Foreign Keys. These concepts define how data is uniquely identified and how different tables connect to each other. Whether you are designing your first database or optimizing a production system, understanding these keys is essential.

What is a Primary Key

A Primary Key is a column or a group of columns in a database table that uniquely identifies each record in that table.
It acts like a unique ID card for every row, ensuring there is no ambiguity when retrieving, updating, or deleting data.

Key Characteristics of a Primary Key

• Uniqueness Every row must have a unique primary key value.
• Non Null Primary keys cannot contain NULL values.
• Single Definition Each table can have only one primary key but it may consist of multiple columns which is known as a composite key.
• Immutable The value of a primary key should rarely change because it serves as the permanent identifier of the row.

Example of a Primary Key

Consider a Users table

user_id (Primary Key)	name	email
1	Alice	alice@email.com
2	Bob	bob@email.com
3	Carol	carol@email.com

Here user_id is the primary key. Even if two users share the same name or email domain their user_id remains unique.

What is a Foreign Key

A Foreign Key is a column or a group of columns in one table that references the primary key of another table.
Its purpose is to enforce referential integrity making sure that relationships between tables remain valid.

Key Characteristics of a Foreign Key

• Reference Points to the primary key of another parent table.
• Duplicates Allowed Multiple rows in the child table can reference the same parent record.
• Optional Relationship Can allow NULL values if the relationship is not mandatory.
• Multiple Allowed A table can have several foreign keys pointing to different parent tables.

Example of a Foreign Key

Consider an Orders table

order_id	user_id (Foreign Key)	product
101	1	Laptop
102	2	Keyboard
103	1	Mouse

Here the user_id column in the Orders table is a foreign key that references the user_id column in the Users table.
This ensures that every order is linked to a valid user. If you try to insert an order with a user_id that does not exist in the Users table the database will reject it.

Primary Key vs Foreign Key Side by Side Comparison

Feature	Primary Key	Foreign Key
Purpose	Uniquely identifies each record in a table	Creates a relationship between two tables
Uniqueness	Must be unique across all rows	Can have duplicate values
Nullability	Cannot contain `NULL` values	Can contain `NULL` values if the relationship is optional
Number per Table	Only one primary key is allowed	A table can have multiple foreign keys
Reference	Exists within its own table	References the primary key of another table
Integrity Role	Guarantees uniqueness within the table itself	Ensures valid links between child and parent tables

This comparison shows that while both keys are used to maintain order and integrity their roles are different.
The primary key focuses on identifying rows within a single table while the foreign key focuses on linking one table to another.

Real World Analogy

Think of a Primary Key as a passport number. Each passport number is unique to one person and cannot be duplicated.
A Foreign Key is like a visa stamp inside the passport. It connects your identity to another country’s system.
A visa is only valid if the passport exists just as a foreign key is only valid if the corresponding primary key exists.

Best Practices

To build strong and scalable databases keep these best practices in mind

• Use Simple and Stable Keys Choose primary keys that are simple and unlikely to change such as an auto incrementing integer.
• Avoid Changing Primary Key Values Because other tables may rely on them changing a primary key can cause cascading issues.
• Index Foreign Keys Adding indexes on foreign key columns can significantly improve join performance.
• Enforce Referential Integrity Use database constraints ON DELETE and ON UPDATE to control how changes in the parent table affect child tables.
• Avoid Using Business Data as Keys Columns like email or phone numbers can change and should not be primary keys.

Why These Keys Matter

Without a primary key it would be impossible to uniquely identify records making operations like updates or deletions unreliable.
Without a foreign key relationships between tables would be fragile allowing invalid or orphaned records to exist.
Together primary and foreign keys create a structured dependable and maintainable database design.

Conclusion

Primary keys and foreign keys are not just database jargon. They are fundamental to creating relational databases that are efficient scalable and consistent.
The primary key ensures that each row in a table is unique while the foreign key maintains valid connections between tables.
Mastering these concepts will help you design systems that handle growth gracefully and maintain data integrity in the real world.

GitHub on Windows: The Complete Guide to SSH, GitHub Desktop, and No Keygen Commits

Md Mohosin Ali Shah — Wed, 13 Aug 2025 18:08:16 +0000

Working with GitHub on Windows can be painless and secure if you set it up the right way.
In this article, you will learn three complete workflows

SSH from Command Prompt or PowerShell for passwordless, secure pushes and pulls
GitHub Desktop the GUI option no SSH setup required
No keygen methods working over HTTPS using a Personal Access Token or the GitHub web editor

Why SSH vs HTTPS on Windows

SSH uses a key pair stored on your machine. No password or token prompts once configured.
HTTPS uses your GitHub login or Personal Access Token PAT. Works out of the box with GitHub Desktop.
Web editor lets you make commits right in your browser with no local setup needed.

SSH from Windows CMD or PowerShell

Step 1 Check for existing SSH keys

dir %USERPROFILE%\.ssh

Look for
id_ed25519 private
id_ed25519.pub public

If they exist and you want to reuse them, skip to Step 4.

Step 2 Create a new SSH key

ssh-keygen -t ed25519 -C "you@example.com"

Press Enter to accept default path
%USERPROFILE%\.ssh\id_ed25519
Optionally set a passphrase.

If ed25519 is not supported

ssh-keygen -t rsa -b 4096 -C "you@example.com"

Step 3 Start the SSH agent and load your key

Get-Service ssh-agent | Set-Service -StartupType Automatic
Start-Service ssh-agent
ssh-add $env:USERPROFILE\.ssh\id_ed25519

Step 4 Copy your public key

Get-Content $env:USERPROFILE\.ssh\id_ed25519.pub | Set-Clipboard

Step 5 Add the key to GitHub

Go to Settings then SSH and GPG keys then New SSH key
Title it for example Windows Laptop
Paste your key
Save

Step 6 Test your connection

ssh -T git@github.com

If successful you will see

Hi <username> You have successfully authenticated...

Step 7 Use SSH in Git

Clone

git clone git@github.com:OWNER/REPO.git

Switch existing repo from HTTPS to SSH

git remote set-url origin git@github.com:OWNER/REPO.git

Step 8 Commit and push

git add .
git commit -m "feat: first SSH commit from Windows"
git push origin main

GitHub Desktop The GUI Method No SSH Needed

GitHub Desktop uses HTTPS by default and stores credentials securely. Perfect if you want to skip SSH.

Step 1 Install and sign in

Download from desktop.github.com
Sign in with your GitHub account.

Step 2 Add a repository

Clone from GitHub File → Clone Repository
Add existing project File → Add Local Repository

Step 3 Ensure HTTPS remote

Repository → Repository Settings
Ensure URL is https://github.com/...

Step 4 Commit changes

Edit files in your project folder.
In Desktop, select changed files, write a commit message, click Commit to branch.

Step 5 Push to GitHub

Click Push origin.
To create a PR, click Create Pull Request.

No Keygen Options

Option 1 HTTPS with Personal Access Token

Create a fine grained PAT in GitHub Settings → Developer settings → Personal Access Tokens
Switch remote to HTTPS

git remote set-url origin https://github.com/OWNER/REPO.git
git push origin main

Use your GitHub username and PAT when prompted.

Option 2 GitHub Web Commits

Open repo on github.com
Add file → Create new file or edit existing
Write changes and commit directly to main or via new branch and PR

Troubleshooting on Windows

Permission denied publickey
Check if your key is loaded

ssh-add -l

If none re-add

ssh-add $env:USERPROFILE\.ssh\id_ed25519

Verify your public key is in GitHub settings.

GitHub Desktop cannot push
Switch to HTTPS in Repository Settings.

Quick SSH Cheat Sheet Windows

ssh-keygen -t ed25519 -C "you@example.com"
Get-Service ssh-agent | Set-Service -StartupType Automatic
Start-Service ssh-agent
ssh-add $env:USERPROFILE\.ssh\id_ed25519
Get-Content $env:USERPROFILE\.ssh\id_ed25519.pub | Set-Clipboard
ssh -T git@github.com
git add .
git commit -m "message"
git push origin main

Conclusion

SSH is best for developers who want secure passwordless Git operations.
GitHub Desktop is ideal for a quick GUI based workflow.
HTTPS with PAT or Web Commits let you skip SSH entirely.

Choose the method that fits your workflow and you will never dread pushing to GitHub on Windows again.

Build High-Performance Websites with React.js, Next.js, Vue.js and Tailwind CSS

Md Mohosin Ali Shah — Sat, 19 Jul 2025 18:10:50 +0000

Hello Dev Community,

I'm Md Mohosin Ali, a Full Stack Developer based in Bangladesh, specializing in React.js, Next.js, Vue.js, and Tailwind CSS. With over two years of professional experience, I help startups, designers, and businesses transform their design files (Figma, PSD, Adobe XD) into fully responsive, high-performance websites and web applications.

Services I Provide

I offer complete frontend and backend development services, with a focus on performance, scalability, and pixel-perfect precision.

Design to Code Conversion

Transform Figma, PSD, or XD designs into dynamic web applications using modern frameworks:

Semantic HTML5
Optimized performance with Next.js and Vue.js
Tailwind CSS for responsive, mobile-first design
SEO best practices included

Gig Link:

Convert Figma, PSD, or XD to React/Next.js

Custom Landing Page Development

Develop clean and modern landing pages optimized for conversions. Built with:

Next.js / React.js / Vue.js
Tailwind CSS
Responsive structure and reusable components

Gig Link:

Design a Custom React/Next.js Landing Page

Full Website Development

Get scalable websites or MVPs tailored for your startup or business:

Multi-page websites or SPAs
Clean, modular code
API integration and state management
Production-ready deployment setup

Gig Link:

Build Responsive Websites with React/Next.js

API Integration & Backend Logic

Connect your frontend to a secure, scalable backend with RESTful or GraphQL APIs:

Node.js + Express.js with MongoDB
JWT or OAuth2 authentication
Secure data handling, efficient queries, and well-documented endpoints

Gig Link:

Integrate REST API or GraphQL into Your Web App

Tech Stack

Frontend: React.js, Next.js, Vue.js, Tailwind CSS, Material UI, Shadcn UI
Backend: Node.js, Express.js, MongoDB, Prisma ORM, Firebase
State Management: Redux, Context API, TanStack Query
API: REST, GraphQL, Axios, Apollo Client
Dev Tools: Git, Vercel, Postman, JWT, Role-Based Access

Recent Projects

Career Props – Job Portal

A scalable HR platform with real-time updates, advanced search, and user roles.

Live: https://career-props.vercel.app

Other notable projects:

Addition (E-Commerce for Influencers)
Truthful Taxes (Financial Services)
HireMaster (Job Portal)
NestEgg (Financial Property Dashboard)

Why Work With Me?

Professional and scalable codebase
Responsive, mobile-friendly design
SEO optimization and fast loading times
Clean and maintainable architecture
Unlimited revisions on standard and premium packages
Clear documentation and post-delivery support

Get in Touch

If you're looking for a developer who values quality, speed, and clean code, I invite you to explore my Fiverr profile and contact me for collaboration.

My Fiverr Profile:

https://www.fiverr.com/mohosin2126

Let’s build something exceptional—custom-coded and performance-optimized.

DBMS vs. RDBMS: Concepts, Differences, and Real-World Applications

Md Mohosin Ali Shah — Tue, 20 May 2025 16:51:28 +0000

In today’s data-driven world, effective data management is essential for everything from lightweight applications to complex enterprise systems. Two foundational technologies used for managing data are:

DBMS (Database Management System)
RDBMS (Relational Database Management System)

While these terms are often used interchangeably, they refer to distinct systems with different capabilities. This article explores what DBMS and RDBMS are, highlights their key differences, and provides real-world examples to help you understand when to use each.

What is a DBMS?

A Database Management System (DBMS) is software that enables users to create, retrieve, update, and manage data in a structured format. Typically, data is stored in files on disk, and the DBMS provides the tools to interact with that data efficiently.

Key Characteristics of DBMS:

Stores data in flat files, hierarchical, or network models
Designed for small-scale applications and single-user environments
Does not support relationships between data entities
Provides basic security and limited transaction management
Offers minimal support for complex queries
Suitable for standalone desktop applications

Real-World Example: Microsoft Access

Consider a small business using Microsoft Access to maintain a customer contact list and order records. The data is stored in isolated files, and any relationship between them must be handled manually. For example, finding out which customers placed which orders would require cross-referencing files manually, as the system lacks relational enforcement.

DBMS Data Structure Example:

Customer File:
CustomerID | Name   | Email
-----------|--------|---------------------
1          | Alice  | alice@example.com
2          | Bob    | bob@example.com

Order File:
OrderID | CustomerID | Item
--------|------------|--------
101     | 1          | Laptop
102     | 2          | Phone

Here, there’s no enforced relationship between CustomerID in the two files. The system does not validate the integrity of that link.

What is an RDBMS?

A Relational Database Management System (RDBMS) stores data in tables (relations) and allows for relationships between tables using keys. Based on E.F. Codd’s relational model, RDBMSs use Structured Query Language (SQL) for database operations and provide robust support for data integrity, multi-user access, and complex queries.

Key Characteristics of RDBMS:

Organizes data in tables with rows and columns
Supports relationships using primary keys and foreign keys
Enforces data integrity constraints (e.g., NOT NULL, UNIQUE, FOREIGN KEY)
Allows for complex querying and reporting
Supports concurrent access and ACID-compliant transactions
Offers advanced security and high scalability

Real-World Example: MySQL

A typical e-commerce platform might use MySQL, an open-source RDBMS, to manage:

User information
Product listings
Orders
Payment histories

These entities are stored in separate but relationally linked tables, enabling efficient and reliable operations.

RDBMS Data Structure Example:

-- Customers Table
CustomerID | Name   | Email
-----------|--------|---------------------
1          | Alice  | alice@example.com
2          | Bob    | bob@example.com

-- Orders Table (CustomerID is a foreign key)
OrderID | CustomerID | Item
--------|------------|--------
101     | 1          | Laptop
102     | 2          | Phone

Here, CustomerID in the Orders table is a foreign key referencing the Customers table. The RDBMS enforces referential integrity, ensuring that every order is associated with a valid customer.

You can execute a SQL query like:

SELECT Customers.Name, Orders.Item
FROM Customers
JOIN Orders ON Customers.CustomerID = Orders.CustomerID;

Result:

Name   | Item
--------|-------
Alice  | Laptop
Bob    | Phone

DBMS vs. RDBMS: Feature Comparison

Feature	DBMS	RDBMS
Data Storage	Files (flat, hierarchical, network)	Tabular format (tables/relations)
Data Relationships	Not supported	Fully supported using keys
Data Integrity	Manual enforcement	Enforced via constraints
Multi-user Access	Limited or absent	Fully supported
Query Language	Proprietary or minimal	SQL (Structured Query Language)
Transaction Support	Limited	Full ACID compliance
Security	Basic	Advanced (roles, privileges, encryption)
Scalability	Low (for small systems)	High (suitable for enterprise-level apps)
Examples	MS Access, dBase, FoxPro	MySQL, PostgreSQL, Oracle, SQL Server

When to Use DBMS or RDBMS

✅ Use DBMS when:

Developing simple or personal applications
Handling small datasets without complex relationships
Building standalone systems without multi-user requirements
Minimal security or transaction handling is acceptable

✅ Use RDBMS when:

Building complex applications that require data relationships
Managing large volumes of data with high integrity
Supporting multiple concurrent users
Requiring complex querying, reporting, and security
Needing scalable and robust data systems

Conclusion

While both DBMS and RDBMS are tools for managing data, RDBMS offers greater power, flexibility, and scalability, making it the preferred choice for modern, multi-user, data-intensive applications. DBMS still has relevance for lightweight, localized applications where relational features and advanced functionalities are not necessary.

Understanding the distinctions between DBMS and RDBMS enables you to select the most appropriate solution for your project, ensuring performance, reliability, and maintainability.

Vue.js Composition API: My Learning Journey as a Beginner

Md Mohosin Ali Shah — Mon, 21 Apr 2025 16:41:26 +0000

As someone new to Vue.js, I've been on an exciting journey learning the Composition API. In this article, I want to share what I've discovered so far to help fellow beginners who are also interested in mastering this powerful frontend framework. Everything I'm sharing comes from my own learning process and notes.

Why I Chose to Learn Vue's Composition API

When I started exploring Vue.js, I discovered there are two ways to build components: the Options API (the traditional approach) and the Composition API (introduced in Vue 3). As a beginner, I decided to focus on the Composition API because:

It lets me organize code by logical concerns rather than option types
It makes reusing logic between components much easier
It provides better TypeScript support (which I plan to learn later)
It's the future direction of Vue

Key Concepts I've Mastered So Far

Reactive State Management

The foundation of Vue is its reactivity system. I learned there are two primary ways to create reactive state:

import { ref, reactive } from 'vue'

// Using ref for primitive values
const count = ref(0)      // Access/modify with .value
const message = ref('')   // Access/modify with .value

// Using reactive for objects
const user = reactive({
  name: 'John',
  age: 30,
  preferences: {
    theme: 'dark'
  }
})  // Access/modify directly (user.name, user.preferences.theme)

The important difference I discovered is that with ref, you need to use .value to access or change the value in JavaScript code, but not in templates where Vue automatically "unwraps" refs. With reactive, you access properties directly.

Conditional Rendering

Vue makes showing and hiding content based on conditions remarkably straightforward:

v-if / v-else-if / v-else

This completely adds or removes elements from the DOM:

<div v-if="status === 'active'">Active Status</div>
<div v-else-if="status === 'inactive'">Inactive Status</div>
<div v-else>Unknown Status</div>

v-show

This toggled visibility using CSS display property (element remains in DOM):

<div v-show="isVisible">This content toggles visibility</div>

I found that v-if is better when the condition changes infrequently since removing/adding DOM elements is more expensive than toggling visibility with v-show.

Component Lifecycle Hooks

Understanding when things happen in my components was crucial. The Composition API provides these hooks as functions:

import {
  onBeforeMount,
  onMounted,
  onBeforeUpdate,
  onUpdated,
  onBeforeUnmount,
  onUnmounted
} from 'vue'

// Setup happens when component initializes (like "created" in Options API)
console.log('Setup is running first')

onBeforeMount(() => {
  // Right before DOM rendering
  console.log('About to mount - DOM not ready yet')
})

onMounted(() => {
  console.log('Component mounted - DOM is ready')

  // Perfect place for:
  // - API calls
  // - DOM manipulation
  // - Setting up timers/intervals

  const timer = setInterval(() => {
    count.value++
  }, 1000)

  // Clean up when component is destroyed
  onBeforeUnmount(() => {
    clearInterval(timer)
  })
})

onBeforeUpdate(() => {
  // Called when data changes, before DOM updates
  console.log('Data changed, DOM update pending')
})

onUpdated(() => {
  // After the DOM has updated
  console.log('DOM has been re-rendered')
})

onUnmounted(() => {
  // Component is completely destroyed
  console.log('Component is gone from DOM')
})

Learning about these hooks helped me understand the perfect timing for different operations in my components.

Working with Computed Properties and Watchers

As I progressed, I realized the power of derived state and reactions:

Computed Properties

import { ref, computed } from 'vue'

const firstName = ref('John')
const lastName = ref('Doe')

// Automatically updates when dependencies change
const fullName = computed(() => {
  return `${firstName.value} ${lastName.value}`
})

// Usage:
console.log(fullName.value) // "John Doe"

// If we update firstName...
firstName.value = 'Jane'
// ...fullName automatically becomes "Jane Doe"

Watchers

import { ref, watch, watchEffect } from 'vue'

const searchQuery = ref('')
const results = ref([])

// Watch specific value with callback
watch(searchQuery, async (newValue, oldValue) => {
  if (newValue.trim()) {
    results.value = await fetchSearchResults(newValue)
  } else {
    results.value = []
  }
})

// watchEffect runs immediately and tracks dependencies automatically
watchEffect(() => {
  console.log(`Current query: ${searchQuery.value}`)
  // This runs immediately and again whenever searchQuery changes
})

Data Fetching Patterns

A common task I needed to learn was fetching data from an API:

import { ref, onMounted } from 'vue'

const posts = ref([])
const loading = ref(false)
const error = ref(null)

onMounted(async () => {
  loading.value = true
  try {
    const response = await fetch('https://api.example.com/posts')
    posts.value = await response.json()
  } catch (e) {
    error.value = e
  } finally {
    loading.value = false
  }
})

I discovered that this pattern could be extracted into a reusable function:

// useFetch.js
import { ref, isRef, unref, watchEffect } from 'vue'

export function useFetch(url) {
  const data = ref(null)
  const error = ref(null)
  const loading = ref(false)

  function fetchData() {
    data.value = null
    error.value = null
    loading.value = true

    fetch(unref(url))
      .then(res => res.json())
      .then(json => {
        data.value = json
        loading.value = false
      })
      .catch(err => {
        error.value = err
        loading.value = false
      })
  }

  if (isRef(url)) {
    // Re-fetch when URL changes if it's reactive
    watchEffect(fetchData)
  } else {
    // Otherwise, just fetch once
    fetchData()
  }

  return { data, error, loading }
}

// Usage in component:
const apiUrl = ref('https://api.example.com/posts')
const { data: posts, loading, error } = useFetch(apiUrl)

This pattern of creating "composables" (reusable functions with reactive state) is one of my favorite aspects of the Composition API.

Form Handling

Working with forms is a common task in web development. Here's how I learned to implement a basic form with validation:

import { ref } from 'vue'

const formData = ref({
  name: '',
  email: '',
  message: ''
})

const errors = ref({})
const submitted = ref(false)

const validateForm = () => {
  errors.value = {}

  if (!formData.value.name) {
    errors.value.name = 'Name is required'
  }

  if (!formData.value.email) {
    errors.value.email = 'Email is required'
  } else if (!/^\S+@\S+\.\S+$/.test(formData.value.email)) {
    errors.value.email = 'Email is invalid'
  }

  return Object.keys(errors.value).length === 0
}

const submitForm = async () => {
  if (validateForm()) {
    // Submit form data...
    submitted.value = true
  }
}

In the template:

<form @submit.prevent="submitForm">
  <div>
    <label for="name">Name</label>
    <input id="name" v-model="formData.name">
    <p v-if="errors.name">{{ errors.name }}</p>
  </div>

  <div>
    <label for="email">Email</label>
    <input id="email" type="email" v-model="formData.email">
    <p v-if="errors.email">{{ errors.email }}</p>
  </div>

  <div>
    <label for="message">Message</label>
    <textarea id="message" v-model="formData.message"></textarea>
  </div>

  <button type="submit">Submit</button>
</form>

My Learning Experience

As a beginner, I found certain aspects of Vue challenging at first:

Remembering when to use .value with refs (in JS code, but not in templates)
Understanding the difference between reactive and ref
Determining when to create a composable vs. just using local functions

What helped me most was building small practice components before attempting more complex features. I started with a simple counter, then added more reactivity, and gradually incorporated lifecycle hooks and data fetching.

Common Vue Directives I Use Daily

Here's a quick reference to the Vue directives I use most often:

Directive	Purpose	Example
`v-model`	Two-way binding for forms	`<input v-model="name">`
`v-on` or `@`	Event handling	`<button @click="increment">+</button>`
`v-bind` or `:`	Bind attributes	`<img :src="imgUrl">`
`v-if/v-else`	Conditional rendering	`<p v-if="isLoggedIn">Welcome</p>`
`v-for`	List rendering	`<li v-for="item in items" :key="item.id">{{ item }}</li>`
`v-show`	Toggle visibility	`<div v-show="isVisible">Toggle me</div>`

What's Next on My Learning Path

Now that I've grasped the fundamentals, I'm excited to learn more about:

State management with Pinia (Vue's recommended state management solution)
Vue Router for building multi-page applications
Advanced component patterns and communication
Unit testing Vue components
Performance optimization techniques

Resources for Fellow Beginners

If you're also learning Vue.js, I've documented my journey with more detailed examples in my GitHub repository: https://github.com/mohosin2126/vuejs-learning.git. Feel free to check it out for more comprehensive examples and notes.

Conclusion

Learning Vue.js and its Composition API has been an exciting journey so far. As a beginner, I appreciate how Vue balances power and simplicity. The Composition API might seem a bit more complex at first compared to the Options API, but the flexibility and reusability it offers are well worth the initial learning curve.

Are you also learning Vue.js? What parts have you found most challenging or interesting? I'd love to hear about your experience in the comments!

Happy coding!

Forem: Md Mohosin Ali Shah

RepoLens Version 2 Ranked #7 on Product Hunt — Building AI for Code Change Intelligence

Understanding a Repository Once Is Not Enough

What Changed in Version 2

What I Learned Building It

The Product Hunt Launch

Where RepoLens Is Going

Links

RepoLens Version 2 - Know what changed and what matters

I Shipped v0.3.0 of My Open Source Project Scaffolding CLI

What starter-structure-cli does

What’s new in v0.3.0

New starters added

A cleaner CLI internally

Stronger validation before release

Why I’m building this

Example usage

What I learned from shipping this

1. Template quality matters more than template count

2. Validation becomes essential very quickly

3. Internal cleanup is part of shipping

4. Real users change how you think

What’s next

Try it

I Built a Tool That Turns GitHub Repositories Into Architecture Dashboards - RepoLens Version 01

RepoLens (Version 1) - Know any repo fast.

Live Platform

Open Source Repository

What RepoLens V1 Does

Tech Stack

Why I Built It

Open Core

I Built a CLI That Scaffolds 30+ Fullstack Projects From Natural Language

The Problem

What It Does

The Cool Parts

1. Natural Language Matching

2. Composable Template System

3. Interactive + Non-Interactive

4. Smart Defaults

Generated Project Structures

How I Built It

Try It

What a monorepo needs (the real requirements)

pnpm in monorepos (why it’s usually best)

1) Speed (especially after first install)

2) Disk usage (big win)

3) Strict dependency isolation (less “hidden bugs”)

4) Workspace tooling feels made for monorepos

5) CI caching is usually better

npm in monorepos (when it’s still a good choice)

1) Maximum compatibility / minimum friction

2) Simpler mental model for some teams

3) Fewer edge cases with legacy tooling

Key Differences (quick but important)

Dependency layout

Bug prevention

Performance

Recommendation (simple decision guide)

Best-practice setup (works great)

365 Days, 2,010 Contributions: What I Learned from a Year of Zero Missed Days

The Stats

Beyond the Green Squares

The Projects That Defined My Year

What I Learned When I Refused to Take a Day Off

1. Logic Over Syntax

2. The Power of "Non-Zero" Days

3. Architecture is a Mindset

Looking Ahead

Primary Key vs Foreign Key: A Complete Guide for Developers

What is a Primary Key

Key Characteristics of a Primary Key

Example of a Primary Key

What is a Foreign Key

Key Characteristics of a Foreign Key

Example of a Foreign Key

Primary Key vs Foreign Key Side by Side Comparison

Real World Analogy

Best Practices

Why These Keys Matter

What `starter-structure-cli` does