That's the most accurate title I could come up with. Here's the summary:

In the last year or so, I have built 4 web apps, 3 open-source tools, wrote one book, onboarded 250+ users overall, and made 25 dollars overall.

Read that sentence a few times. Eight projects and 250+ users went in, and 25 dollars came out. That isn't a monthly number or a per-project number. It's the total.

I'm not writing this to ask for sympathy, or to pretend it was all a learning experience. Some of it was. Mostly, I want the numbers written down in one place, because the gap between building something and getting someone to pay for it is easy to ignore when you only look at one project at a time.

The web apps

These are the ones where revenue was supposed to happen.

1. Bailoutt.com - Fake AI calls and call reminders - live ~200 users, 2 paid

   This is the closest thing I have to a success. About 200 people signed up, which is more than everything else combined. Two of them paid. Most of the 25 dollars came from these two people.

2. https://chunkybabies.com - Baby health tracker - 2 users, didn’t take off. Offline now

   Not much to say. Two users, no traction, and I shut it down. It's the only project on this list that no longer exists.

3. Kitaaben - Book tracker, journal and AI reviews. - 60+ users - 1 active subscriber

   Sixty-odd people use it to track what they read, and one person pays for it. That one subscriber is the reason it's still running, and I'm grateful to them.

4. WO Buddy - Build your exercise plan, with illustrated guide - 10 users - none paid

   Ten users, none paid.

Put those side by side, and you get a funnel that starts wide at "built" and ends at a few coins at "paid."

The open source tools

I never expected these to make money. They're free, they solved my own problems, and a couple of them might solve yours.

1. GWDAP - Automate verification and adding aliases for multiple domains.

   Adding domain aliases in Google Workspace means verifying and adding each domain by hand. That's fine for one domain. It gets tedious and error-prone once you have several. GWDAP automates it.

2. COPE agent - A multi-model content repurposing tool that turns any provided source into a canonical brief, which in turn converts it into multi-format content, i.e. long form like LinkedIn, short form like Twitter, etc., carousel, both image and and pdf

   You give it a source, like a messy text file. It distils the source into one brief and turns that brief into posts for different formats. This post started that way.

3. DoCk - A browser extension that routes your Google Workspace links to their respective PWAs rather than opening a new tab for each link.

   I built it because I was tired of a Docs link opening yet another browser tab when I already had the installed app. It's small and narrow, and it does exactly that.

The book

1. Dad, Debriefed - Journaled my experience as a father and turned it into a book that works as a guide to new fathers.

   This one is different from the rest. I didn't start with a market in mind. I started with a journal. The journal grew into a book, and the book became something I wish I'd had when I started.

So where does that leave things?

Here's the scoreboard: 8 projects, 250+ users, $25.

You can read that a few ways. Turns out I'm good at shipping. Getting anyone to pay is a separate skill, and the list shows I haven't learned it yet. Every one of these went live. Most of them found at least a handful of people. Almost none of them found people with a reason to pay.

A few things I'm taking from the year:

1. Shipping is not the bottleneck. I can build things. That clearly isn't what's holding me back.

2. Users are not customers. Bailoutt has about 200 users and 2 paying ones. That ratio says a lot about what I've actually validated.

3. One paying subscriber counts. Kitaaben's single subscriber tells me more than its 60+ free users do.

4. Killing a project is fine. Chunkybabies is offline, and nothing broke.

5. Not everything has to make money. The open source tools and the book were worth doing anyway. I just shouldn't confuse them with a business.

So it's a list of failures, by the only number that pays rent. By the count of things that exist now and didn't a year ago, the year went better than that number suggests. Both readings are true. I'm just not going to pretend the second one cancels out the first.

I have three Google Workspaces: personal Gmail, my own Workspace, and my company's. That means three separate PWAs for Mail, three for Meet, three for Calendar, and so on down the line.

Here's the thing: every time a Meet link landed in my chat, it opened a brand new window. Not focused an existing one — opened a new one. Multiply that by three accounts and a normal day of meetings, and you end up with a wall of Meet windows and duplicate Gmail tabs you can't tell apart. It got really hard to manage.

What I built

So I built Dock. If you click a link and there's already a matching PWA open, Dock redirects you to that window instead of spawning a new one. Gmail, Meet, Calendar, Drive, Docs, Sheets, Slides, or Chat — same idea for all of them. Holding Shift bypasses it for that one click, for the times you actually want a fresh window.

Dock also helps me manage all my open tabs. Say I've got six Meet windows open across accounts — I can close any of them, for any account, from any screen. It keeps everything decluttered, the mental load is reduced. You don't need five mailboxes open just to check personal email once. One mailbox for personal, one for work, one for the side Workspace — or whatever your split looks like.

And I gave it a cute mascot: Meet Doc-k

Getting the account right

The tricky part isn't catching the link. It's knowing which account's window to send you to. Dock routes to the window for the account the link actually names — via authuser=, /u/N/, or a stored mapping — and it keeps a window's identity correct even after you switch accounts from inside the PWA itself. It reuses the already-open window for that account instead of spawning a duplicate.

The switcher

Press Ctrl/Cmd+Shift+Space and you get a fuzzy-searchable popup listing every app window, grouped by account. Live calls are surfaced first. One-click close, per window or per whole account.

A few other things it does:

• Each login gets an automatically assigned, editable colour tag, shown on the toolbar icon and in the switcher.

• You can add your own custom rules for apps Dock doesn't know about — Figma, Notion, whatever — with a match pattern, target behaviour, and account strategy.

• Built-in Google Workspace rules can be disabled but not deleted.

• Rules import/export as JSON.

No network requests

It makes no network requests — nothing it does ever leaves your device. All the routing logic runs locally against windows Chrome already knows about.

Try it

I haven't put it in the Chrome Store yet. Not sure I will. So clone the repo, build it yourself, and load it as an unpacked extension: github.com/sirius93/dock.

That's the whole idea, and so far it's worked wonders for me. If it works for you too, star the repo or leave feedback — and if enough people find it worth the hassle, I'll look at making it live.

So here's the thing I've been building. It's called COPE — Create Once Post Everywhere — and it's exactly what it sounds like: write your thought down once, let an agent turn it into content for every platform.

What it actually is

COPE is an agent that runs on Claude or Codex. You give it a rough text note — voice-to-text ramble, half-formed idea, whatever — or even a URL, like one of your own blog posts, and it repurposes that into a full set of platform-ready outputs: a LinkedIn post, an X thread, a blog version, images, and a carousel PDF.

It also generates threaded tweets or posts, so if you've got something meaty to say, it can spread it across multiple posts instead of cramming it into one.

How you use it

There's no hosted app or dashboard here. You download the repo from GitHub and run it inside Claude or Codex directly. From there you feed it your note or a URL for context, and it does the repurposing.

Where the outputs go

Once COPE generates everything, here's the flow:

• Carousel images → post to Instagram

• Carousel PDF → post to LinkedIn

• Short-form content → post to Threads or X

The current limitation

Automatic posting is not supported yet. That's a real limitation right now — you still have to manually post everything COPE generates. It handles the repurposing, not the publishing.

Best part

Best part about it, it is open source. It's hosted on my GitHub at github.com/sirius93/cope, so anyone can pull it down, poke at it, or extend it.

Try it

If you've got a rough note sitting in a text file or a blog post you want to squeeze more mileage out of, download the repo from github.com/sirius93/cope and run it inside Claude or Codex. See what it turns your mess into.

For every domain, an administrator has to prove ownership, publish a DNS record, wait for propagation, return to Google Workspace, add the domain, configure mail routing, and verify the result. None of those steps is especially difficult. The problem is repetition — and repetition is where small mistakes become outages.

I recently needed a better workflow for attaching a collection of brand domains to one Google Workspace account. The domains used GoDaddy DNS, and the intended behavior was simple: every existing Workspace user should receive the same username on every brand domain.

That made the domains good candidates for Google Workspace user alias domains. It also made the process a good candidate for automation. The result is a CSV-driven Python CLI with three commands — plan, apply, verify — that connects the Google Workspace Admin SDK, the Site Verification API, and the GoDaddy DNS API, authenticates with OAuth instead of a service-account key, and treats every write as something to check for before doing. Code's open source at github.com/sirius93/google-workspace-domain-alias-provisioner, link at the bottom too.

The problem with doing it manually

The manual workflow usually looks like this:

1. Open the Google Admin console.

2. Add a domain alias.

3. Copy Google's verification token.

4. Open the DNS provider.

5. Create the TXT record.

6. Wait for DNS propagation.

7. Ask Google to verify the domain.

8. Configure MX records.

9. Repeat for the next domain. Do this once and it feels harmless. Do it twenty times and several risks appear:

• A domain is skipped.

• A TXT value is copied incorrectly.

• The wrong parent domain is selected.

• Existing MX records are replaced accidentally.

• The spreadsheet and the real configuration drift apart.

• Nobody has a reliable record of what succeeded. The goal was not merely to make the process faster. The goal was to make it repeatable, inspectable, and safe to rerun.

Domain alias or secondary domain?

Before automating anything, it is important to choose the correct Google Workspace domain model.

A user alias domain gives existing users and groups equivalent addresses on another domain. If brand.example is an alias of company.example, then:

alex@company.example  -> alex@brand.example
sales@company.example -> sales@brand.example

Both addresses point to the existing account or group. Users continue signing in with their primary address, and there is no separate mailbox.

A secondary domain is different. It is intended for a separate collection of users whose primary accounts live on that domain. Secondary-domain users normally require their own Workspace licences.

The automation described here is specifically for user alias domains. That keeps the mapping predictable: one parent Workspace domain, many brand domains, and matching usernames across all of them.

Google documents the distinction and current domain limits in its multiple-domain guidance.

Turning the domain list into a source of truth

The first useful improvement is surprisingly mundane: put the desired state in a CSV file.

domain,type,parent_domain,dns_provider
brand-one.example,domain_alias,company.example,godaddy
brand-two.example,domain_alias,company.example,godaddy
brand-three.example,domain_alias,company.example,godaddy

This file becomes the input to every operation. It is easy to review, version, split into pilot batches, and compare with the actual environment.

The script validates that:

• Every domain is unique.

• Every row has a parent domain.

• The requested type is domain_alias.

• The DNS provider is supported. That validation catches boring mistakes before an API call turns them into an operational problem.

The automation flow

The workflow connects three APIs:

• Google Site Verification API generates a DNS verification token and confirms ownership.

• GoDaddy Domains API v3 reads the zone and creates missing TXT or MX records.

• Google Workspace Admin SDK Directory API creates and inspects domain aliases. For each CSV row, the tool performs this sequence:

1. Check whether the domain is already verified.

2. Check whether the Workspace alias already exists.

3. Read the current GoDaddy DNS records.

4. Request a Google verification token when needed.

5. Add the token as an apex TXT record if it is missing.

6. Poll public DNS until the token is visible.

7. Ask Google to verify ownership.

8. Create the Workspace domain alias under the configured parent.

9. Optionally add Google MX when — and only when — the domain has no MX records. The read-before-write behavior is essential. A rerun should continue an incomplete job, not create duplicates.

Why the CLI has plan, apply, and verify

Infrastructure tools are much easier to trust when inspection and mutation are separate operations.

The CLI exposes three commands:

python workspace_domain_aliases.py plan domains.csv
python workspace_domain_aliases.py apply domains.csv
python workspace_domain_aliases.py verify domains.csv

plan

plan is read-only. It checks Google and GoDaddy, then prints a compact summary:

DOMAIN                           DNS      VERIFIED  WORKSPACE  MX
brand-one.example                ok       no        missing    0
brand-two.example                ok       yes       missing    5
brand-three.example              ok       no        present    1

This answers the questions that matter before a change: Can the tool access the DNS zone? Does Google already recognize the owner? Does the Workspace alias already exist? Is mail already configured?

apply

apply creates missing ownership records, verifies domains, and creates missing Workspace aliases.

python workspace_domain_aliases.py apply domains.csv

DNS propagation is asynchronous, so the tool polls for the verification TXT record. If the record does not become visible before the timeout, the run reports the domain as pending. Nothing needs to be rolled back: wait, then rerun the same command.

verify

verify reconciles the CSV with the live state, checking ownership, alias presence, parent-domain association, and whether the domain has at least one MX record. A non-zero exit code makes it usable in a shell script or a future CI workflow.

Authentication without service-account keys

My first instinct was to use a service account with domain-wide delegation. That is a common design for unattended Workspace administration, but the organization enforced this policy:

iam.managed.disableServiceAccountKeyCreation

That was not a problem to work around. It was a useful security boundary.

Long-lived service-account JSON keys are portable credentials. If one leaks into a repository, backup, support ticket, or developer machine, it can be abused until revoked. Google recommends avoiding service-account keys when a safer authentication method fits the workload.

For a locally operated administrative tool, interactive OAuth is a good match. The application uses an OAuth 2.0 Desktop app client and asks the administrator to authorize two scopes:

https://www.googleapis.com/auth/admin.directory.domain
https://www.googleapis.com/auth/siteverification

The Python flow is conceptually simple:

from google_auth_oauthlib.flow import InstalledAppFlow
 
scopes = [
    "https://www.googleapis.com/auth/admin.directory.domain",
    "https://www.googleapis.com/auth/siteverification",
]
 
flow = InstalledAppFlow.from_client_secrets_file(
    "oauth-client.json",
    scopes,
)
credentials = flow.run_local_server(port=0)

The first run opens a browser. The administrator signs in and approves access. The resulting refresh token is stored locally and reused on later runs.

That token must still be treated like a password. It should never be committed, pasted into an issue, or stored beside public example files.

Connecting to Google Workspace

Once OAuth credentials are available, the Python client can construct both Google services:

from googleapiclient.discovery import build
 
directory = build(
    "admin",
    "directory_v1",
    credentials=credentials,
    cache_discovery=False,
)
 
verification = build(
    "siteVerification",
    "v1",
    credentials=credentials,
    cache_discovery=False,
)

Creating a domain alias uses the Directory API:

directory.domainAliases().insert(
    customer="my_customer",
    body={
        "domainAliasName": "brand.example",
        "parentDomainName": "company.example",
    },
).execute()

Before inserting, the tool lists existing aliases and compares the live parent domain with the CSV. If an alias already exists under a different parent, the script stops instead of guessing how to repair it.

Automating domain verification

Google ownership verification has two distinct operations: obtain a token and verify the resource.

The request describes an internet domain and asks for DNS verification:

result = verification.webResource().getToken(
    body={
        "site": {
            "identifier": "brand.example",
            "type": "INET_DOMAIN",
        },
        "verificationMethod": "DNS",
    }
).execute()
 
token = result["token"]

The token is published as an apex TXT record. Once it is visible in public DNS, the tool asks Google to verify the resource:

verification.webResource().insert(
    verificationMethod="DNS",
    body={
        "site": {
            "identifier": "brand.example",
            "type": "INET_DOMAIN",
        }
    },
).execute()

Keeping these steps separate makes DNS propagation explicit. A successful API response from the DNS provider does not mean every resolver can see the record immediately.

Adding records through GoDaddy safely

GoDaddy's v3 DNS API supports individual record creation:

POST /v3/domains/zones/{zone}/dns-records

A verification record looks like this:

{
  "type": "TXT",
  "name": "@",
  "data": "google-site-verification=...",
  "ttl": 600
}

The safe pattern is:

1. List existing records of the relevant type.

2. Normalize record names and values.

3. Create the record only when an exact match is absent.

4. Never replace the entire DNS zone. This matters because DNS APIs differ. Some "set records" methods replace every record with a matching name and type. Others can replace the whole zone. A provisioning tool should use the narrowest operation available.

GoDaddy also warns that record creation is not inherently idempotent: blindly replaying a failed POST can create duplicates. Reading the zone before each write significantly reduces that risk.

Why MX changes are opt-in

Verification TXT records are additive and relatively low-risk. MX records are different: they control where inbound email is delivered.

The tool therefore does not touch MX during the default apply operation. Mail configuration requires an explicit flag:

python workspace_domain_aliases.py apply domains.csv --add-google-mx

Even with the flag, the tool adds smtp.google.com only when the domain has zero MX records. If any MX record already exists, it prints a warning and leaves the configuration untouched.

That conservative decision handles several real-world cases: the domain already uses Google's older five-record MX configuration, the domain uses Google's newer single-record configuration, another mail provider is still active, or the domain has intentional routing or migration records.

Automation should not interpret "different from my preferred configuration" as "safe to overwrite."

SPF, DKIM, and DMARC are also intentionally outside the first version. Each requires knowledge of the organization's complete mail-sending environment. For example, adding a second SPF record can make SPF invalid rather than more secure.

Making reruns safe

Bulk administrative work rarely completes in one flawless pass. DNS might be slow, one domain might belong to another account, an API can rate-limit a request, or an administrator might pause the rollout.

The tool is designed so that rerunning apply is normal:

• Existing TXT token: skip creation.

• Already verified domain: skip verification.

• Existing Workspace alias with correct parent: skip insertion.

• Existing MX records: leave unchanged.

• Pending DNS: retry later. This is the practical meaning of idempotency for the workflow. The entire run may involve APIs whose individual POST operations are not idempotent, but the program checks the current state before deciding whether a write is necessary.

A rollout strategy that minimizes surprises

For a real environment, I would use the following sequence:

1. Export or back up every DNS zone.

2. Put one non-critical domain in a pilot CSV.

3. Run plan.

4. Inspect any existing MX records.

5. Run apply without the MX flag.

6. Confirm the alias in the Google Admin console.

7. Test receiving mail after the approved MX change.

8. Confirm outbound authentication separately.

9. Expand to small batches.

10. Run verify and keep the output with the change record. The pilot is not ceremony. It confirms that the OAuth project, administrator privileges, Workspace tenant, GoDaddy account, authoritative nameservers, and API behavior all match the assumptions in the code.

What I would add next

The first release solves one narrow problem well. Natural next steps include:

• DNS-provider adapters for Cloudflare, Route 53, TransIP, and others

• Secondary-domain support

• JSON output for CI and audit systems

• Unit tests with mocked API responses

• Explicit DNS backup and rollback workflows

• SPF, DKIM, and DMARC validation without automatic enforcement

• A keyless workload-identity design for approved unattended execution Any future provider should preserve the same safety contract: read before write, create only what is missing, never replace a zone implicitly, and require explicit intent for destructive actions.

Lessons learned

Three ideas mattered more than the API calls themselves.

First, model the desired state before writing code. The CSV is small, but it turns an informal checklist into something reviewable and repeatable.

Second, treat security controls as design input. A blocked service-account key did not require disabling an organization policy. It led to an authentication flow better suited to a human-operated CLI.

Third, make dangerous behavior inconvenient. The tool can automate MX creation, but only through an explicit flag, and it refuses to modify existing mail routing. A little friction is valuable when a command can affect production email.

That's usually the sweet spot for internal automation. I've open sourced it — if you're wiring up your own multi-brand Workspace setup, the CLI and the client wrappers are there to fork.

Resources

• Source code: github.com/sirius93/ggwdap — plan/apply/verify CLI, CSV schema, and the Google + GoDaddy client wrappers described above.

• Google Workspace Admin SDK Directory API

• Google Site Verification API

• Google Directory API Python quickstart

• Google Workspace multiple-domain guidance

• GoDaddy DNS API guide

• Google Cloud authentication guidance

This project is not affiliated with or endorsed by Google or GoDaddy. DNS and mail-routing changes can disrupt production services; test with a non-critical domain and keep current DNS backups.

I wanted GitHub to be the source of truth. Real commit history. Real pull requests. A deploy pipeline I could reason about without a proprietary UI sitting in the middle. The service was already live on Cloud Run, so the plan was simple: point it at the GitHub repo and be done by lunch.

It took the whole afternoon. Just not the afternoon I expected.

The plan that should have worked

Cloud Run has a built-in feature for exactly this — Continuously deploy from a repository. Connect a GitHub repo, pick a branch, and it auto-generates a Cloud Build trigger that builds and deploys on every push. No YAML. Click, connect, push.

Snag 1. The very first build failed, but for a boring reason. My repo had two lockfiles — package-lock.json and a stray pnpm-lock.yaml that got committed by accident at some point. Google's Buildpacks saw the pnpm lockfile and built with pnpm. And recent pnpm versions block dependency install scripts by default as a supply-chain protection. So esbuild's postinstall script (the one that downloads its platform binary) never ran, and the build died before it even reached my code.

Fix: delete the stray lockfile. The project was never pnpm-based anyway. Quick, forgettable, not the story.

The error that refused to explain itself

Next push got further — all the way to the deploy step — and then this:

ERROR: (gcloud.run.services.update)
spec.template.metadata.annotations[run.googleapis.com/sources]:
Source annotation has sources that are not referenced by a container.

Read that sentence a few times. Nothing in it tells you what to do. No stack trace, no file, no line number. Just a Cloud Run validator rejecting a deploy against its own service definition.

Wrong theory #1: strip the annotation

The obvious read — some stale annotation is sitting on the live service, left over from however AI Studio originally provisioned it. So just remove it:

$ gcloud run services update kitaaben --region us-west1 \
    --remove-annotations=run.googleapis.com/sources
 
ERROR: unrecognized arguments: --remove-annotations=run.googleapis.com/sources
(did you mean '--remove-env-vars'?)

Turns out gcloud run services update has no generic "edit any annotation" flag. Most of Cloud Run's raw Knative-style metadata isn't meant to be hand-edited through convenience flags — precisely to stop people from doing what I was about to do.

Wrong theory #2: ditch Buildpacks entirely

New theory. The run.googleapis.com/sources annotation is part of Cloud Run's source-deploy tracking — it maps source paths to containers so the console can show "this revision was built from commit X." A plain prebuilt Docker image needs none of that. So: write a Dockerfile, sidestep Buildpacks and its source-tracking machinery completely.

I wrote a multi-stage Dockerfile. Built it locally, ran it, confirmed it booted and served traffic. Pushed.

And this is where it got genuinely confusing. The build went green. The live site didn't change.

The build log explained why. Adding a Dockerfile made Cloud Build quietly switch strategies. Instead of the four-step Buildpacks template it had been using (build → pull → push → deploy), it fell back to Google's generic "there's a Dockerfile here, build and push an image" default, which has no deploy step at all. Green build. No deploy. Nobody tells you.

Fix for this part: a handwritten cloudbuild.yaml with three explicit steps. docker build, docker push, gcloud run deploy --image. Three commands, in order, in the repo. No more guessing what the pipeline does.

Same error, completely different deploy method

With a real deploy step finally in place, I pushed again — and got the exact same annotation error. This time from a plain gcloud run deploy --image call that had nothing to do with source builds or Buildpacks at all.

That was the moment the real shape of the problem clicked. It was never about how I was deploying. Buildpacks, Dockerfile, source-based, image-based — didn't matter. Something was wrong with the live service's own persisted state, and every deploy method was stepping on the same landmine.

Exporting the body

Time to look at what the service actually thought it was running:

$ gcloud run services describe kitaaben --region us-west1 \
    --format export > service.yaml

Buried in that YAML: the container's image field wasn't a real image reference. It was the literal string scratch — Cloud Run's internal placeholder for services that resolve their actual container indirectly, through that same sources annotation I'd been fighting all afternoon.

The service was born this way. AI Studio provisioned it through its own source-deploy pipeline on day one, and it had been carrying that placeholder ever since. A ghost container, quietly broken since birth, and it only mattered the day I tried to deploy any other way.

So every attempt was failing one of two ways: either the deploy tried to update the sources annotation and Cloud Run rejected the mismatch, or the leftover scratch placeholder had nothing left to resolve against.

The actual fix

Fix both in one edit, apply atomically:

# in service.yaml:
#   1. delete the run.googleapis.com/sources annotation line
#   2. change image: scratch to the real image path
 
$ gcloud run services replace service.yaml
Applying new configuration to Cloud Run service [kitaaben]...
Deploying... done.

That was it. Not a flag. Not a build strategy. Not a YAML rewrite of the pipeline. A genuinely stuck field in the service's own state that no amount of retrying — from any deploy method — was ever going to clear.

If you're doing this migration

• If AI Studio (or any source-deploy tool) originally provisioned your Cloud Run service, don't assume a clean deploy method inherits a clean service. describe --format export and read the spec before you spend a day guessing.

• run.googleapis.com/sources and image: scratch travel together. See one, check for the other.

• Cloud Build silently changes strategy based on what's in your repo. Dockerfile present vs absent produces different pipelines. If a build goes green but nothing deploys, check whether the deploy step still exists.

• Not every Cloud Run field has a convenience flag. When --remove-X doesn't exist, the fallback is always: export the spec, hand-edit, services replace. Haven't touched the pipeline since. It's a Cloud Build trigger watching main, building a Docker image, deploying it. No mystery annotations.

GitHub is the source of truth now. AI Studio is where Kitaaben was born, not where it lives.

That’s all, folks! I hope you found this helpful. If you enjoyed this, check out more articles on my Blog, https://blog.nandan.dev/

Feel free to comment, email me at connect@nandan.dev, or connect with me on Twitter, Instagram, or GitHub. Don’t forget to subscribe to my newsletter for regular updates on JavaScript topics!

Twitter | Instagram | Github | Website

For years, Goodreads was that place. Then Amazon bought it in 2013 and... nothing happened. No meaningful update. No design refresh. No new features worth talking about. Just a bloated, slow, social-feed-first app that cared more about what your friends were reading than what you actually wanted from a reading tracker.

So I stopped waiting and built my own. It's called Kitaaben.

What Even Is Kitaaben?

Kitaaben is a private bookshelf tracker. That's it, honestly.

You sign in with Google, add your books, and start tracking. No followers, no public profile, no algorithm telling you what to read next. Just your books, organized the way you want them.

I built it as a React SPA, backed by Firestore for real-time sync and Google OAuth for auth. It works as a PWA too, so you can install it directly on your phone or desktop and it behaves like a native app. Even logs notes offline and syncs when you're back online.

The stack is deliberately simple. I didn't want to over-engineer a reading tracker.

The Features That Actually Matter

Reading Progress Tracking

You can log how many pages you've read, mark a book as "Reading", "To Read", or "Completed", and watch your progress bar move. Small thing, weirdly satisfying.

Yearly Reading Goals

Set a target at the start of the year. Kitaaben shows you a clean gauge of where you stand. No gamification, no streaks, no push notifications guilt-tripping you into reading. Just the number.

The AI Review Assistant

This one is my favourite. You know how you finish a book, you have all these raw thoughts, and then you sit down to write a review, and your mind goes blank?

Kitaaben fixes that. You log rough chapter notes as you read. When you're done, one click and the AI turns your messy notes into a proper, readable review. It uses Gemini under the hood, server-side, so nothing weird is happening with your data.

Beautiful Bookshelf UI

You can pick colour palettes for your book spines, attach local photos, or link directly to publisher dust jackets. Your shelf actually looks good. Goodreads shelf looks like it was designed in 2009 because it was.

Cloud Sync + Offline PWA

Everything syncs in real-time to Firestore. Works across your phone, tablet, and desktop. Add notes on a flight, they'll sync when you land.

Your Data Is Yours

No corporate sponsors. No ads. No one is analysing your reading habits to sell you something. The free tier is genuinely free, forever. If you want AI reviews and premium themes, there's an Elite plan, but the core is completely free.

Kitaaben vs Goodreads — Let's Be Honest

Goodreads isn't bad because it was badly built. It's bad because it stopped being built. Amazon has no incentive to fix it. It already has 150 million users who have nowhere to go.

Kitaaben is built for readers who are tired of that and just want something that works, looks good, and doesn't treat your reading life as a data point.

Who Is It For?

Honestly? People like me.

If you read regularly and want a clean private place to track it, Kitaaben will feel like a breath of fresh air. If you rely on Goodreads mainly for its social features — seeing what friends are reading, community reviews, that sort of thing — Kitaaben isn't trying to replace that. It's not a social network. It never will be.

It's a personal reading sanctuary. That's the whole point.

Try It

kitaaben.com — Sign in with Google, takes about 60 seconds to set up.

If you have feedback, brutal or otherwise, reach me at namastay@kitaaben.com or find me on Twitter. I'm building this in the open and I actually read every message.

Thanks, Nandan

It looks simple at first. But the interviewer is actually checking whether you understand recursion, objects, and how JavaScript treats arrays.

So basically, you are given a nested object, and you are expected to simplify it by removing the nesting and printing it in a non-nested format.

Here is a simple input and output :

const input = {
  a: 1,
  b: {
    c: 2,
    d: {
      e: 3
    }
  }
};

Output:

 {  a: 1, 
    b_c: 2, 
    b_d_e: 3, 
 }

Now look at the solution :

function flatten(obj, prefix = "", res = {}) {
    // Loop through every key in the object
    for (let key in obj) {

        // Skip properties coming from prototype chain
        if (!obj.hasOwnProperty(key)) return;

        // If prefix exists, append current key using _
        // Otherwise just use the key itself
        let objKey = prefix ? `\({prefix}_\){key}` : key;

        let value = obj[key];

        // If value is an object and not null,
        // recursively flatten it
        if (typeof value === 'object' && value !== null) {
            flatten(value, objKey, res);
        } else {
            // If it's a primitive value, assign it directly
            res[objKey] = value;
        }
    }

    // Return the accumulated result
    return res;
}

Let us test it.

const input = {
  a: 1,
  b: {
    c: 2,
    d: {
      e: [1, 2]
    }
  }
};

console.log(flatten(input));

//  {a: 1, b_c: 2, b_d_e_0: 1, b_d_e_1: 2 }

Now observe something interesting.

It flattens the nested object correctly.

But it also destructures the array and adds indexes as keys.

Why do you think that happened?

So when we check:

typeof value === 'object'

Arrays also satisfy that condition.

That means our recursive call is going inside arrays as well, and treating indexes (0, 1) like object keys.

That is why we are getting:

b_d_e_0: 1
b_d_e_1: 2

So, how do we fix it?

Simple.

We add one more condition to ignore Arrays.

function flatten(obj, prefix = "", res = {}) {
    for (let key in obj) {

        // Ensure we are working only with object's own properties
        if (!obj.hasOwnProperty(key)) return;

        let objKey = prefix ? `\({prefix}_\){key}` : key;
        let value = obj[key];

        // Only recurse if:
        // 1. value is an object
        // 2. value is not null
        // 3. value is NOT an array
        if (
            typeof value === 'object' &&
            value !== null &&
            !Array.isArray(value)
        ) {
            flatten(value, objKey, res);
        } else {
            // Directly assign primitives and arrays
            res[objKey] = value;
        }
    }

    return res;
}

Testing Both Cases

const input1 = {
  a: 1,
  b: {
    c: 2,
    d: {
      e: [1, 2]
    }
  }
};

const input2 = {
  a: 1,
  b: {
    c: 2,
    d: {
      e: 3
    }
  }
};

console.log(flatten(input1));
console.log(flatten(input2));

// { a: 1, b_c: 2, b_d_e: [ 1, 2 ] }
// { a: 1, b_c: 2, b_d_e: 3 }

That is it.

A simple recursion problem. But it tests whether you truly understand:

• How objects work

• How arrays behave internally

• How recursion accumulates results

• And how small edge cases can break your logic

This is why interviewers love this question.

That’s all, folks! I hope you found this helpful. If you enjoyed this, check out more articles on my Blog, https://blog.nandan.dev/

Feel free to comment, email me at connect@nandan.dev, or connect with me on Twitter, Instagram, or GitHub. Don’t forget to subscribe to my newsletter for regular updates on JavaScript topics!

Twitter | Instagram | Github | Website

HTML is deceptively simple. You open a tag, you close a tag, and something appears on screen. But beneath that simplicity lurk gotchas that can silently break your layout, wreck your SEO, or make your site look unprofessional when shared on social media.

In this world of frameworks and libraries, it’s easy to miss some of the basic stuff that needs to be taken care of in your webpage, because your framework’s boilerplate code adds up most of the stuff and takes care of the basics. But it’s always good to know some of them that are important or aren’t added by your framework by default.

Here are the critical HTML pitfalls to avoid and how to fix them immediately.

1. Forgetting the DOCTYPE Declaration

Skipping the doctype triggers something called as the quirks mode, where browsers start behaving like it's 1999. This results in inconsistent CSS rendering and unpredictable JavaScript behaviour across browsers.

Always declare it at the very top of your HTML file:

<!DOCTYPE html>

2. Missing the Character Encoding Meta Tag

Without proper character encoding, special characters turn into garbled symbols i.e. (�). This breaks accented letters, smart quotes, and emojis, and it makes your webpage content look broken and unprofessional.

Place this inside the <head> tag:

<meta charset="UTF-8">

3. Forgetting the Viewport Meta Tag

Has it ever happened to you? Your page zooms awkwardly when users double-tap on mobile; That’s because you're missing the viewport meta tag. Without it, your site isn't truly responsive, regardless of your CSS.

Add this to your <head> section:

<meta name="viewport" content="width=device-width, initial-scale=1.0">

4. Skipping Open Graph Meta Tags

Ever shared your blog on LinkedIn, Twitter, or Facebook only to see a bare URL with no preview card? That's because Open Graph tags are missing. These tags control how your content appears when shared on social media.

Add these OG tags for rich sharing previews:

<meta property="og:title" content="My Blog Title">
<meta property="og:description" content="A quick guide to avoiding HTML gotchas.">
<meta property="og:image" content="https://example.com/preview.png">
<meta property="og:url" content="https://example.com/blog">

Pro tip: Also consider adding Twitter Card tags for optimal Twitter/X previews.

5. Ignoring Content Security Policy

Content Security Policy (CSP) helps prevent cross-site scripting (XSS) attacks and other code injection vulnerabilities. It tells browsers which scripts, styles, and resources are allowed to run on your page.

Start with a basic CSP meta tag:

<meta http-equiv="Content-Security-Policy" 
      content="default-src 'self'; script-src 'self' 'unsafe-inline';">

Note: This is a starting point. Adjust the policy based on your specific needs and third-party resources.

6. Improper Nesting of Elements

Browsers are forgiving, but invalid HTML nesting leads to unpredictable rendering and can break JavaScript that relies on the DOM structure.

Common nesting mistakes:

<!-- Inline elements shouldn't contain block elements -->
<span><div>Wrong!</div></span>

<!-- Paragraphs can't contain divs -->
<p><div>Also wrong!</div></p>

Follow these nesting rules:

• Inline elements (<span>, <a>, <strong>) should never contain block-level elements (<div>, <section>, <p>)

• <p> Tags should only wrap inline content, never block-level elements

• When in doubt, check the HTML specification for content models

Conclusion

These six HTML gotchas might seem minor, but they're the difference between a professional website and one that breaks in subtle, embarrassing ways. Take five minutes to audit your HTML templates—your future self (and your users) will thank you.

Quick checklist for your next project:

• DOCTYPE declaration at the top

• UTF-8 character encoding

• Viewport meta tag for mobile

• Open Graph tags for social sharing

• Basic Content Security Policy

• Valid HTML nesting

Remember: browsers are forgiving, but that doesn't mean we should be sloppy. Clean HTML is the foundation of a reliable web experience.

That’s all, folks! I hope you found this helpful. If you enjoyed this, check out more articles on my Blog, https://blog.nandan.dev/

Feel free to comment, email me at connect@nandan.dev, or connect with me on Twitter, Instagram, or GitHub. Don’t forget to subscribe to my newsletter for regular updates on JavaScript topics!

Twitter | Instagram | Github | Website

It should not be mandated by the government, but rather it should be taken as the responsibility of every developer to make their websites accessible to all users.

Making a website accessible will not just help you avoid government penalties, it will also give you a wider user base. Accessibility is all about making your website accessible to everyone.

On that note, let’s get this blog started -

What is Accessibility

Accessibility is ensuring that your web application is usable by people with disabilities, including people with

• Visual impairment (Blindness, Colour Blindness) -

• Hearing loss

• Motor Impairment ( Difficulty using the mouse)

• Cognitive limitation (Dyslexia, Attention Disorder)

Accessibility Core Principle (POUR)

How can people with disabilities use the applications

Accessibility Standards

Web Content Accessibility Guidelines (WCAG)

Defines Accessibility levels as A, AA & AAA

Read More: https://www.w3.org/WAI/standards-guidelines/wcag/

Accessible Rich Internet Applications (ARIA)

Adds accessibility support to non-semantic elements.

Read More: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/

Americans with Disabilities Act (ADA)

Legal mandate in the US for accessible digital content

Read More: https://www.ada.gov/

AA is the most commonly required level of compliance.

How to make a web application Accessible

Use Semantic Tags

• Use tags like <button> , <nav>, <header>, <section> etc.

• Avoid using div and span all over your application

Support Keyboard Accessibility

• Actions should be usable via. keyboard, including opening modals, dropdowns, and toasts.

• Use tabindex to align focus correctly.

• Use focus, keydown event listeners correctly

Use Aria Roles when needed

• Use aria-label, aria-hidden, role="dialog", etc., when native semantics are not sufficient

• https://w3c.github.io/aria/

Focus Management

• Trap focus in modals

• Restore focus when modals close

• Visibly indicate focus using focus-visible or outline

Maintain Colour Contrast

• 4.5: 1 for normal text in AA Standard

• 7:2 for AAA

• Check contrast: https://webaim.org/resources/contrastchecker/

Using Images and Other Media

• Use alt text for images

• Add transcripts/captions for videos/audio

• Avoid autoplaying media files. i.e. Video

Tools for Accessibility Testing

The tools listed below are some of the most common tools for testing accessibility in a web application.

WCAG AAA is harder to implement, and most website are expected to maintain AA compliant.

I hope by the end of this post, you have a good idea of why accessibility is important and how you can add accessibility support to your application.

That’s all, folks! I hope you found this helpful. If you enjoyed this, check out more articles on my Blog, https://blog.nandan.dev/

Feel free to comment, email me at connect@nandan.dev, or connect with me on Twitter, Instagram, or GitHub. Don’t forget to subscribe to my newsletter for regular updates on JavaScript topics!

Twitter | Instagram | Github | Website

Hence, there is no correct answer, but a correct Framework. Understanding and approaching system design with the RADIO RADIO framework (Requirements, Architecture, Design, Implementation, Optimisation) helps you streamline your answer.

Additionally, you can treat this blog as a framework for everything that requires building a feed, i.e. Twitter, Facebook, or Orkut, for that matter.

But everything beyond that is dependent on your knowledge and understanding of the system.

Designing a platform like Instagram might sound overwhelming at first, but breaking it down using the RADIO framework (Requirements, Architecture, Design, Implementation, Optimisation) makes it manageable and actually kinda fun. I recently took a shot at this, and here's what I came up with, plus a few tweaks and lessons learned along the way.

Requirements

🔧 Functional Requirements:

• News Feed that shows text, images, and videos

• User info (photo, username) on each post

• Like, comment, and share buttons

• Pagination or infinite scroll

• Lazy loading for media

🚫 Non-Functional Requirements:

• Fully responsive (mobile + desktop)

• Accessibility compliant

• Optimised for performance

• Supports A/B testing for features

• Localisation and translation support

Bonus points if it supports offline mode and has a fallback UI.

Architecture

Start by defining your core building blocks:

📂 Components:

PostCard
├── TextContent
├── ImageGallery / VideoPlayer
├── UserHeader (avatar + name)
├── PostActions (like/comment/share)

Feed
└── PostCard[]

CommentSection
LikeButton
ShareButton

Each of these is reusable and maintainable — the key to scalable front-end architecture.

Design

Keep your data models clean and normalised. Here's what worked well:

type Post = {
  id: string;
  text?: string;
  images?: string[];
  video?: string;
  userId: string;
  comments: Comment[];
  likes: Like[];
  createdAt: string;
};

type User = {
  id: string;
  name: string;
  username: string;
  avatar: string;
  postIds: string[];
};

type Like = {
  userId: string;
  postId: string;
};

type Comment = {
  id: string;
  userId: string;
  postId: string;
  text: string;
  createdAt: string;
};

• Avoid embedding full User objects inside posts

• Use IDs to reference everything

• Support multiple images per post (carousel style)

Implementation

Here's how the main flow looks:

• Feed Page: loads posts using a custom hook (useFetchPosts)

• Loop through PostCard components to render UI

• Use libraries like React Query or SWR for cache + fetch

• Defer comment loading until user clicks "View all comments"

Suggested folder structure:

/components
  /Post
    PostCard.tsx
    PostMedia.tsx
    PostFooter.tsx
  /User
  /Comment
/hooks
  useFetchPosts.ts
/pages
  index.tsx // News Feed

Optimization

Performance matters more than ever. Here's what to prioritise:

• 📸 Lazy load images and videos

• 🔄 Use IntersectionObserver for infinite scroll

• 🏔️ PWA support (with service workers)

• 📑 Bundle splitting + code-splitting

• 🚀 Skeleton loaders while fetching

• 🌍 Localised text using react-i18next

• 📉 Memoise unchanging components with React.memo

TL;DR

Designing Instagram from the front-end isn’t about copying their UI; it's about building a thoughtful system that can scale, perform, and feel native on any device. Use the RADIO framework to break down the chaos into manageable parts, and you'll be surprised how fast it comes together.

Want to understand what polyfills are? I have covered them in my blog Polyfills for Call, Apply & Bind.

Why? Because it's fun. Because it's educational. And because the next time someone throws a technical interview curveball at you, like "Can you write your own reduce" and you’ll casually say, "Sure, do you want it with comments or without?"

Today, we’re building polyfills for:

• flat()

• map()

• filter()

• reduce()

Let’s roll.

flat() — A Pancake Stack for Arrays

if(!Array.prototype.myFlat){
    Array.prototype.myFlat = function(depth){
        if(depth < 0) return this;

        const flatten = function(arr, depth){
            return arr.reduce((acc,ele)=>{
                if(Array.isArray(ele) && depth > 0){
                    acc = acc.concat(flatten(ele,depth -1));
                }else{
                    acc.push(ele);
                }
                return acc;
            },[])
        }

        return flatten(this,depth);
    }
}

const nestedArray = [1, [2, [3, [4, 5]]], 6];

console.log(nestedArray.myFlat()); // Default depth = 1 => [1, 2, [3, [4, 5]], 6]
console.log(nestedArray.myFlat(2)); // Depth = 2 => [1, 2, 3, [4, 5], 6]
console.log(nestedArray.myFlat(3)); // Depth = 3 => [1, 2, 3, 4, 5, 6]
console.log(nestedArray.myFlat(0)); // Depth = 0 => [1, [2, [3, [4, 5]]], 6]

Just a basic flattening function. Will it replace your backend job? No. But will it make you feel cool? Absolutely.

map() — Because Sometimes Arrays Need a Makeover

if(!Array.prototype.myMap){
    Array.prototype.myMap = function(fn, thisArg){
       if(this == null)  { return new Error("Not an array")};

       if(typeof(fn) != 'function') {return new Error("Not an array")}

       let result = [];

       for(let i=0; i< this.length; i++){
           if(i in this){
               result.push(fn.call(thisArg,this[i], i, this));
           }
       }
       return result;
    }
}

a = [1,2,3,4,5].myMap(function (mem) {
    return mem*mem;
})

console.log(a); // [ 1, 4, 9, 16, 25 ]

Simple and clean. No magical spells involved.

filter() — Only the Worthy Shall Pass

if(!Array.prototype.myFilter){
    Array.prototype.myFilter = function(fn, thisArg){
       if(this == null)  { return new Error("Not an array")};

       if(typeof(fn) != 'function') {return new Error("Not an array")}

       let result = [];

       for(let i=0; i< this.length; i++){
           if(i in this && fn.call(thisArg,this[i], i, this)){
               result.push(this[i]);
           }
       }
       return result;
    }
}

b = [1,2,3,4,5].myFilter(function (mem) {
    return mem > 1;
})

console.log(b) //[ 2, 3, 4, 5 ]

Give it a test run with your own weird conditions. Even filter out people who don't like coffee; your call.

reduce() — The Boss Level

if(!Array.prototype.myReduce){
    Array.prototype.myReduce = function(callback,initialValue){
        if(this == null) {return new Error("Not an Array");}

        if(typeof(callback) != 'function') {
            return new Error("Not a function");
        }

        let arr = this;
        let len = arr.length;

        let hasInitial = arguments.length > 1;
        let accumulator = hasInitial ? initialValue : arr[0];
        let startIndex = hasInitial ? 0 : 1;

        if (len === 0 && !hasInitial) {
          throw new Error("Reduce of empty array with no initial value");
        }


        for (let i = startIndex; i < len; i++) {
          if (i in arr) {
            accumulator = callback(accumulator, arr[i], i, arr);
          }
        }

        return accumulator;
    }
}

let a = [1, 2, 3].myReduce((acc, val) => acc + val, 0);
console.log(a);

Reduce is like that friend who seems intimidating at first, but once you get to know them, they carry the whole squad.

Why Do This?

You may never need to use these in a production app. But knowing how they work helps you:

• Understand JavaScript fundamentals better.

• Appreciate the built-in methods more.

• Have something cool to say in interviews or while pretending to debug in coffee shops.

So go ahead, mess around with these, add your own flavour, and maybe even extend a couple more methods just for fun.

That’s all, folks! I hope you found this helpful. If you enjoyed this, check out more articles on my Blog, https://blog.nandan.dev/

Feel free to comment, email me at connect@nandan.dev, or connect with me on Twitter, Instagram, or GitHub. Don’t forget to subscribe to my newsletter for regular updates on JavaScript topics!

Twitter | Instagram | Github | Website

Okay, so if you have ever deep-dived into JavaScript interviews or just casually scrolled through dev Twitter (yes, that’s a thing), you would have stumbled upon someone throwing around the words polyfill like they were born building web browsers.

And if you’re like me, you probably nodded along, opened a tab to Google it later, and… procrastinated.

But no worries. You’re here now, and we are going to figure this out together.

First things first — What the heck is a polyfill?

A polyfill is just a piece of code (usually JavaScript) that adds functionality to older browsers that do not natively support a certain feature.

Think of it like you bringing a power bank to an event where there are no charging points. Your phone is old? No problem. You got the backup.

Now… Why Call, Apply, and Bind?

Because they’re like the Avengers of function manipulation in JavaScript.

And also because they confuse almost everyone at first.

• call lets you call a function with a given this value and arguments.

• apply is like call, but arguments are passed as an array.

• bind doesn’t immediately invoke the function. It returns a new function with a given this.

Here is a detailed write-up on call, apply & bind.

Simple enough, right? Now let’s make our versions

Polyfill for call

Here’s how we can build a polyfill for call:

Function.prototype.myCall = function(context,...args){ 
    context = context || globalThis;
    let Symbolfn = Symbol("fn"); // Unique key
    context[Symbolfn] = this; // Assign 'this' function to the context
    let result = context[Symbolfn](...args); // Call the function
    delete context[Symbolfn];  // Clean up
    return result;
}

// Usage
function sayHello(greeting) {
  console.log(`${greeting}, ${this.name}`);
}

const user = { name: "Nandan" };
sayHello.myCall(user, "Hello");

Cool, right? Not rocket science.

Polyfill for apply

Now, let’s tweak it a bit for apply:

Function.prototype.myApply = function(context,args){
    context = context || globalThis;
    let Symbolfn = Symbol("fn");
    context[Symbolfn] = this;
    let result = args ? context[Symbolfn](...args) : context[Symbolfn]();
    delete context[Symbolfn];
    return result;
}

// Usage
sayHello.myApply(user, ["Hi"]);

Polyfill for bind

Now comes the big boss bind.

Function.prototype.myBind = function(context,...initialArgs){
    let fn = this;
    return function(...functArgs){
        return fn.apply(context, [...initialArgs,...functArgs])
    }
}

// Usage
const boundSayHello = sayHello.myBind(user, "Hey");
boundSayHello(); // Outputs: Hey, Nandan

• bind doesn’t call the function right away.

• It returns a new function that you can call later.

• We merge the arguments provided at bind-time and call-time.

That’s it — You just built call, apply, and bind polyfills!

Honestly, when I first read about polyfills, I thought it was some deep internal browser magic. Turns out, it’s just about creatively manipulating JavaScript’s behavior.

If you take one thing from this post, let it be this:

“The cowards never started and the weak died along the way. That leaves us, ladies and gentlemen. Us.”

(Yeah, that’s a quote from Shoe Dog. Still fits perfectly here, doesn’t it?)

Here’s one if you want to read a review of the book Shoe Dog, written by me.

That’s all, folks! I hope you found this short note on Polyfills of Call, Apply & Bind helpful. If you enjoyed this, check out more articles on my Blog, https://blog.nandan.dev/

Feel free to comment, email me at connect@nandan.dev, or connect with me on Twitter, Instagram, or GitHub. Don’t forget to subscribe to my newsletter for regular updates on JavaScript topics!

Twitter | Instagram | Github | Website

If you may be following me on socials, I just started a newsletter for book reviews & suggestions. Check https://kitaaben.com. That got me thinking: What if I built a small book recommendation application that can help users get book recommendations based on their interests?

I started building it on Firebase studio. Started with a simple prompt to build an AI-based book recommendation application that shows a good variety of genres by default and an interest field for additional context. The Number of books you want to be recommended is either 1/3/6 or 12.

The initial version came with these fields. But after some iterations, I decided to add the email field and email integration to help users get the recommendation directly to their email.

The tech stack looks something like this:

• Nextjs + Reactjs ( For the application)

• Gemini API (For AI)

• Firebase (For Hosting)

• Resend (For Email - Free Tier)

The final version looked like this:

After some testing and a lot of dopamine, I went ahead and made it public. Mapped it to a subdomain and made it public. Here is the URL if you want to give it a try: https://bookwise.kitaaben.com

I shared it in my friend’s WhatsApp group, Instagram, Twitter( now X), Linkedin almost everywhere I could.

But seems like someone didn’t like the spamming and decided to do something about it. By launching a DDOS attack on my website.Targeting my email functionality, trying to exhaust my email limit and increasing my cloud hosting + AI usage cost.

See the sudden spike in the requests?

Panic set in; I didn’t know what to do. Should I bring down the site and end this or something else? I decided not to give up and just think and act quickly

I did and quickly signed up for Cloudflare, added the Cloudflare protection layer to my app and observed the behaviour for some time. By this time, my email limit of 200 emails by resend had already been exhausted, so I waited for the next day and added a caching layer to store the emails and rate limit the emails to 3 emails per hour.

Things seem to be stable for now. The traffic has dropped as well. However, I would not mind some humans trying the app, benefiting from it and providing some real feedback.

If you are a human reading this, give the app a try. Tell me what you like/dislike. I am always just an email away at connect@nandan.dev

That’s all, folks! I hope you enjoyed this. Check out more articles on my website, https://nandan.dev/

Feel free to comment, email me at connect@nandan.dev, or connect with me on Twitter, Instagram, or GitHub. Don’t forget to subscribe to my newsletter for regular updates on JavaScript topics!

Twitter | Instagram | Github | Website

Okay, Hear me out..!!

Hundreds of blogs and tutorials explain call, bind, and apply. Heck, even ChatGPT and Copilot can simplify them for you!

So why another post? Well, this one’s not for you—it’s my self-note as I revisit JavaScript fundamentals.

Even after 8 years in front-end development, I sometimes mix up these methods. Turns out, the confusion often stems from how they’re grouped in interview questions. Let me break it down for you—this time, in a way that sticks.

Can we skip to the good part.

Why is it always call, bind, and apply in interviews? Functionally, call and apply are closer—they invoke the function immediately—while bind returns a new function. That’s why I’ve grouped them this way in the title.

Let's look at their usage to understand it better.

What is common among Call, Bind & Apply?

call, bind, and apply are methods available on functions that allow you to explicitly set the value of this and pass arguments to the function.

What is the difference between Call, Bind & Apply?

While Call and Apply Immediately invoke the function, the Bind method does not immediately invoke the function. instead, it returns a new function with this set to a specified value, and this returned function can be invoked/executed later.

What is the difference between Call and Apply then?

While both Call and Apply immediately invoke the function with the custom this, it’s how they take the additional argument that differentiates them.

While Call takes the individual arguments, Apply takes an array of arguments.

Examples

Let’s look at the below example to understand the use of call, apply and bind.

function Greetings(greeting,punctuation){
    return `${greeting} ${this.name} ${punctuation}`
}

var person = {
    name : "Nandan"
}

// Call: Immediately invokes the function with individual arguments
console.log(Greetings.call(person,"Hello","!")); // Output : Hello Nandan !

// Apply: Immediately invokes the function, but takes arguments as an array
console.log(Greetings.apply(person,["Hello","!"])); // Output : Hello Nandan !

// Bind: Returns a new function with `this` bound to the specified value
let greet = Greetings.bind(person,"Hello","!");
console.log(greet()); // Output : Hello Nandan !

//Note:
console.log(Greetings.bind(person,"Hello","!")); // Output : It will return a function

Some Additional Examples

• Using call: Borrowing methods from another object:

let person1 = { name: "Nandan" };
let person2 = { name: "Kumar" };

function introduce() {
    console.log(`Hi, my name is ${this.name}`);
}

introduce.call(person1); // Hi, my name is Nandan
introduce.call(person2); // Hi, my name is Kumar

• Using apply: Finding the max value in an array:

let numbers = [1, 2, 3, 4, 5];
console.log(Math.max.apply(null, numbers)); // 5

• Using bind: Event handling with custom this:

let button = document.getElementById("myButton");
let user = {
    name: "Nandan",
    greet() {
        console.log(`Hello, ${this.name}`);
    }
};

button.addEventListener("click", user.greet.bind(user));

Additionally, I hope this table will help you understand it better.

That’s all, folks! I hope you found this short note on Call, Apply & Bind helpful. If you enjoyed this, check out more articles on my website, https://nandan.dev/

Feel free to comment, email me at connect@nandan.dev, or connect with me on Twitter, Instagram, or GitHub. Don’t forget to subscribe to my newsletter for regular updates on JavaScript topics!

Twitter | Instagram | Github | Website

When are closures created?

Closures are created when a function (inner function) is defined inside another function (outer function). The inner function has access to the outer function's lexical scope (variables) even after the outer function is executed.

Lexical Scope in Javascript

Lexical scope means a function’s scope is determined by where it is written in the code, not where it is executed. This allows inner functions to access variables from their outer functions even if the outer function has already finished executing.

Usage

Closures are used for creating Private variables and persistent States (Cache, Memoisation etc.).

Closures with Examples

A Simple counter

function Outer() {
    let count = 0; // count is a private variable
    return function inner() {
        count++; // count is updated every time inner is called
        return count; // the updated value of count is returned
    };
}

let Counter = Outer(); 
Counter(); // 1 (count starts at 0, incremented to 1)
Counter(); // 2 (incremented again)
Counter(); // 3

Building a cache leveraging closure

function ObjectCache() {
    let Obj = {}; // Obj acts as a private cache
    return function ObjectUpdate(key, value) {
        if (!Obj[key]) {
            Obj[key] = value; // Add key-value to cache if not already present
            return Obj; // Return updated cache
        } else {
            return new Error("Duplicate Key"); // Prevent overwriting
        }
    };
}

let cache = ObjectCache();
cache("a", "b"); // {a: 'b'}
cache("a", "c"); // Error: Duplicate Key
cache("alpha", "romeo"); // {a: 'b', alpha: 'romeo'}

Real World Examples

Event Listeners - Click Counter

function attachListener(element) {
    let count = 0;
    element.addEventListener('click', () => {
        count++;
        console.log(`Clicked ${count} times`);
    });
}

A Better Counter

const CounterModule = (() => {
    let count = 0;
    return {
        increment: () => ++count,
        reset: () => (count = 0),
        decrement: () => --count
    };
})();

CounterModule.increment(); // 1
CounterModule.increment(); // 2
CounterModule.decrement(); // 1
CounterModule.reset(); // 0

That’s all, folks! I hope you found this short blog on closures helpful. If you enjoyed this, check out more articles on my website, https://nandan.dev/

Feel free to comment, email me at connect@nandan.dev, or connect with me on Twitter, Instagram, or GitHub. Don’t forget to subscribe to my newsletter for regular updates on JavaScript topics!

Twitter | Instagram | Github | Website

High-level differences

Here are some high-level differences between SQL and NoSQL:

Storage

SQL stores data in tables where each row represents an entity, and each column represents a data point related to that entity.

NoSQL databases utilize various data storage models, including key-value, graph, and document-oriented approaches.

Schema

In SQL, each record follows a fixed schema, which means that the columns must be determined and chosen before data entry, and each row must contain data for each column. The schema can be modified later, but this involves modifying the database using migrations.

NoSQL schemas are dynamic. Fields can be added on the fly, and each record doesn’t have to contain data for each field.

Querying

SQL databases use Structured Query Language (SQL) to define and manipulate data, which is highly powerful.

In a NoSQL database, queries focus on a collection of documents, with different databases having different syntax for querying.

Scalability

In most cases, SQL databases can be scaled vertically, which can become very costly. While it's feasible to scale a relational database across multiple servers, it's a difficult and time-consuming process.

NoSQL databases are horizontally scalable, which means it's easy to add more servers to handle large traffic. They can be hosted on inexpensive hardware or cloud instances, making them cost-effective compared to vertical scaling. Many NoSQL technologies also distribute data across servers automatically.

Reliability

The majority of relational databases are ACID compliant. Therefore, SQL databases are still the best choice for data reliability and transaction safety.

Many NoSQL solutions prioritize performance and scalability over ACID compliance.

Reasons

As always we should always pick the technology that fits the requirements better. So, let’s look at some reasons for picking SQL or NoSQL based database:

For SQL

• Structured data with strict schema

• Relational data

• Need for complex joins

• Transactions

• Lookups by index are very fast

For NoSQL

• Dynamic or flexible schema

• Non-relational data

• No need for complex joins

• Very data-intensive workload

• Very high throughput for IOPS

That's all folks.

Feel free to comment on how you like my blog on the system design series or shoot me an email at connect@nandan.dev If you have any queries I will try to answer them.

You can also visit my website to read some of the articles at https://nandan.dev/

Stay tuned & connect with me on my social media channels. Subscribe to my newsletter to get regular updates on my upcoming posts.

If you're interested in learning about system design, you can join Design Guru's course on System Design Fundamentals.

Twitter | Instagram | Github | Website

A database is a structured collection of information or data that is typically stored electronically in a computer system. The management of the database is usually done by a Database Management System (DBMS). The combination of the data and the DBMS, along with the related applications, is commonly referred to as a database system, which is often shortened to just database.

What is DBMS?

A database is a collection of data that requires a comprehensive database software program, known as a Database Management System (DBMS), to function. Essentially, a DBMS serves as an interface between the database and its end-users or programs, allowing users to retrieve, update, and manage how the information is organized and optimized. Additionally, a DBMS enables oversight and control of databases, enabling a variety of administrative operations such as performance monitoring, tuning, backup, and recovery.

Components

Here are some commonly found components that are present in different databases:

Schema

A schema is responsible for defining the structure of a data storage system and specifying the types of data that can be stored in it. Schemas can be strictly enforced throughout the entire database, enforced loosely in some areas, or not enforced at all.

Table

Each table can have anywhere from two to over a hundred columns, depending on the type of information it contains, similar to a spreadsheet.

Column

A database column contains a single data value of a particular type for each row. The data value can be text, number, enum, timestamp, etc.

Row

Data in a table is recorded in rows. There can be thousands or millions of rows in a table having any particular information.

Types

Below are different types of databases:

• SQL

• NoSQL

  • Document

  • Key-value

  • Graph

  • Timeseries

  • Wide column

  • Multi-model

Challenges

Here's a revised version of the text to make it clearer and free of spelling, grammar, and punctuation errors:

Running databases at scale can pose some common challenges that need to be addressed.

• Absorbing significant increases in data volume: The explosion of data from sensors, connected machines, and other sources is increasing rapidly.

• Ensuring data security: Data breaches are becoming increasingly common, making it more important than ever to prioritize both data security and user accessibility.

• Keeping up with demand: For timely decision-making and seizing new opportunities, companies require real-time access to their data.

• Managing and maintaining the database and infrastructure: As data volumes increase and databases become more complex, companies face the expense of hiring additional talent to manage them.

• Removing scalability limits: A business needs to grow to survive, and its data management must grow with it. However, predicting the required capacity of on-premises databases can be challenging.

• Ensuring data residency, data sovereignty, or latency requirements: Some organizations have use cases that are better suited to run on-premises. In those cases, engineered systems that are pre-configured and pre-optimized for running the database are ideal..

SQL databases

A SQL or relational database is a collection of items that are related to each other and organized into tables consisting of columns and rows. These tables hold the information about the objects to be represented in the database. Each column in a table holds a specific type of data, and each field stores the actual value of an attribute. The rows in the table represent a collection of related values of one object or entity.

Each row in a table can be identified uniquely with a primary key, and the rows among multiple tables can be related to each other using foreign keys. This data can be accessed in many different ways without the need to reorganize the database tables themselves. SQL databases usually follow the ACID consistency model.

Materialized views

A materialized view is a pre-computed dataset that is derived from a query specification and stored for later use. The data is pre-computed, which makes querying a materialized view faster than executing a query against the base table of the view. This performance difference is significant when a query is run frequently or is complex.

Materialized views enable data subsetting, which improves the performance of complex queries that run on large datasets and reduces network loads. Though there are other uses of materialized views, they are primarily used for performance and replication purposes.

N+1 query problem

The N+1 query problem occurs when the data access layer executes additional SQL statements (N) to retrieve the same data that could have been obtained when executing the primary SQL query. The greater the value of N, the more queries will be executed, leading to a performance impact.

This problem is commonly observed in GraphQL and ORM (Object-Relational Mapping) tools. It can be solved by optimizing the SQL query or by using a dataloader that batches consecutive requests and makes a single data request under the hood.

Advantages

Let’s look at some advantages of using relational databases:

• Simple and accurate

• Accessibility

• Data consistency

• Flexibility

Disadvantages

Below are the disadvantages of relational databases:

• Expensive to maintain

• Difficult schema evolution

• Performance hits (join, denormalization, etc.)

• Difficult to scale due to poor horizontal scalability

Examples

Here are some commonly used relational databases:

• PostgreSQL

• MySQL

• MariaDB

• Amazon Aurora

NoSQL databases

NoSQL refers to a category of databases that do not primarily use SQL as their data access language. These databases are also known as non-relational databases. Unlike relational databases, NoSQL databases do not require data to follow a predefined schema. NoSQL databases follow BASE consistency model.

Below are different types of NoSQL databases:

Document

A document database, also known as a document-oriented database or a document store, is a versatile database that stores information in the form of documents. These databases can be used for transactional and analytical applications.

Advantages

• Intuitive and flexible

• Easy horizontal scaling

• Schemaless

Disadvantages

• Schemaless

• Non-relational

Examples

• MongoDB

• Amazon DocumentDB

• CouchDB

Key-value

One of the simplest types of NoSQL databases, key-value databases save data as a group of key-value pairs made up of two data items each. They’re also sometimes referred to as a key-value store.

Advantages

• Simple and performant

• Highly scalable for high volumes of traffic

• Session management

• Optimized lookups

Disadvantages

• Basic CRUD

• Values can’t be filtered

• Lacks indexing and scanning capabilities

• Not optimized for complex queries

Examples

• Redis

• Memcached

• Amazon DynamoDB

• Aerospike

Graph

A graph database is a type of NoSQL database that uses graph structures to store and represent data. Instead of tables or documents, it uses nodes, edges, and properties to create relationships between data items.

The nodes represent the data items, while the edges represent the relationships between them. The relationships allow data in the store to be linked together directly and can be retrieved with a single operation in many cases.

Advantages

• Query speed

• Agile and flexible

• Explicit data representation

Disadvantages

• Complex

• No standardized query language

Use cases

• Fraud detection

• Recommendation engines

• Social networks

• Network mapping

Examples

• Neo4j

• ArangoDB

• Amazon Neptune

• JanusGraph

Time series

A time-series database is a database optimized for time-stamped, or time series, data.

Advantages

• Fast insertion and retrieval

• Efficient data storage

Use cases

• IoT data

• Metrics analysis

• Application monitoring

• Understand financial trends

Examples

• InfluxDB

• Apache Druid

Wide column

Wide column databases, also known as wide column stores, are schema-agnostic. Data is stored in column families, rather than in rows and columns.

Advantages

• Highly scalable, can handle petabytes of data

• Ideal for real-time big data applications

Disadvantages

• Expensive

• Increased write time

Use cases

• Business analytics

• Attribute-based data storage

Examples

• BigTable

• Apache Cassandra

• ScyllaDB

Multi-model

Multi-model databases combine different database models (i.e. relational, graph, key-value, document, etc.) into a single, integrated backend. This means they can accommodate various data types, indexes, queries, and store data in more than one model.

Advantages

• Flexibility

• Suitable for complex projects

• Data consistent

Disadvantages

• Complex

• Less mature

Examples

• ArangoDB

• Azure Cosmos DB

• Couchbase

That's all folks.

In the next blog, I will try to cover more about SQL V/s NoSQL Databases.

Feel free to comment on how you like my blog on the system design series or shoot me an email at connect@nandan.dev If you have any queries I will try to answer them.

You can also visit my website to read some of the articles at https://nandan.dev/

Stay tuned & connect with me on my social media channels. Subscribe to my newsletter to get regular updates on my upcoming posts.

If you're interested in learning about system design, you can join Design Guru's course on System Design Fundamentals.

Twitter | Instagram | Github | Website

Availability refers to the duration for which a system performs its intended function within a given timeframe. It measures the percentage of time a system or machine remains operational under normal circumstances, serving as a simple metric of operational continuity.

The Nine’s of availability

The "Nine's of availability" is a way to measure the reliability and uptime of a system. It is expressed as a percentage or number of nines, where each "nine" represents an additional decimal place of uptime.

$$Availability = \frac{Uptime}{(Uptime + Downtime)}$$

If availability is 99.00% available, it is said to have “2 nines” of availability, and if it is 99.9%, it is called “3 nines”, and so on.

Availability in Sequence vs Parallel

If a service consists of multiple components prone to failure, the service’s overall availability depends on whether the components are in sequence or in parallel.

Sequence

Overall availability decreases when two components are in sequence.

$$Availability \space (Total) = Availability \space (Foo) * Availability \space (Bar)$$

For example, if both Foo and Bar each had 99.9% availability, their total availability in sequence would be 99.8%.

Parallel

Overall availability increases when two components are in parallel.

$$Availability \space (Total) = 1 - (1 - Availability \space (Foo)) * (1 - Availability \space (Bar))$$

For example, if both Foo and Bar each had 99.9% availability, their total availability in parallel would be 99.9999%.

Availability vs Reliability

If a system is reliable, it means it is available. However, if a system is available, it does not necessarily mean it is reliable. This means that a system with high reliability will also have high availability, but a system can still achieve high availability without being reliable.

High Availability vs Fault Tolerance

Both high availability and fault tolerance are methods for achieving high uptime levels, but they work differently.

A fault-tolerant system ensures that there is no service interruption, but it comes at a higher cost. On the other hand, a highly available system minimizes service interruption. To achieve fault tolerance, hardware redundancy is essential. In case the main system fails, another system takes over without any loss in uptime.

Scalability

Scalability is the measure of how well a system responds to changes by adding or removing resources to meet demands.

Let’s discuss different types of scaling:

Vertical scaling

Vertical scaling (also known as scaling up) expands a system’s scalability by adding more power to an existing machine. In other words, vertical scaling refers to improving an application’s capability via increasing hardware capacity.

Advantages

• Simple to implement

• Easier to manage

• Data consistent

Disadvantages

• Risk of high downtime

• Harder to upgrade

• Can be a single point of failure

Horizontal scaling

Horizontal scaling (also known as scaling out) expands a system’s scale by adding more machines. It improves the performance of the server by adding more instances to the existing pool of servers, allowing the load to be distributed more evenly.

Advantages

• Increased redundancy

• Better fault tolerance

• Flexible and efficient

• Easier to upgrade

Disadvantages

• Increased complexity

• Data inconsistency

• Increased load on downstream services

Storage

Storage is a mechanism that enables a system to retain data, either temporarily or permanently. This topic is mostly skipped over in the context of system design, however, it is important to have a basic understanding of some common types of storage techniques that can help us fine-tune our storage components. Let’s discuss some important storage concepts:

RAID

RAID (Redundant Array of Independent Disks) is a way of storing the same data on multiple hard disks or solid-state drives (SSDs) to protect data in the case of a drive failure.

There are different RAID levels, however, and not all have the goal of providing redundancy. Let’s discuss some commonly used RAID levels:

• RAID 0: Also known as striping, data is split evenly across all the drives in the array.

• RAID 1: Also known as mirroring, at least two drives contains the exact copy of a set of data. If a drive fails, others will still work.

• RAID 5: Striping with parity. Requires the use of at least 3 drives, striping the data across multiple drives like RAID 0, but also has a parity distributed across the drives.

• RAID 6: Striping with double parity. RAID 6 is like RAID 5, but the parity data are written to two drives.

• RAID 10: Combines striping plus mirroring from RAID 0 and RAID 1. It provides security by mirroring all data on secondary drives while using striping across each set of drives to speed up data transfers.

Comparison

Let’s compare all the features of different RAID levels:

Volumes

"Volume" refers to a fixed amount of storage space on a disk or tape. Although the term "volume" is often used interchangeably with "storage," it is important to note that a single disk can contain multiple volumes, or a volume can span across multiple disks.

File storage

File storage is a method used to store data in a hierarchical directory structure and present it to users. It is a user-friendly solution that provides easy storage and retrieval of files. In order to locate a file in file storage, one must know the complete path of the file. It is an economical and well-structured method that is commonly used on hard drives. This means that files appear exactly the same for the user and on the hard drive.

Example: Amazon EFS, Azure files, Google Cloud Filestore, etc.

Block storage

Block storage is a method of storing data by dividing it into blocks or chunks, which are then stored as separate entities. Each block is given a unique identifier, which enables the system to store the smaller pieces of data wherever it is most convenient.

Block storage separates data from user environments, making it possible for data to be spread across multiple environments. This creates multiple paths to the data and enables users to retrieve it quickly. When a user or application requests data from the block storage system, the system reassembles the data blocks and presents the data to the user or application.

Example: Amazon EBS.

Object Storage

Object storage, also known as object-based storage, divides data files into smaller units called objects. These objects are then stored in a single repository that can be distributed across multiple networked systems.

Example: Amazon S3, Azure Blob Storage, Google Cloud Storage, etc.

NAS

A Network Attached Storage (NAS) is a device that is connected to a network and allows authorized users to store and retrieve data from a central location. The NAS device is flexible, which means that we can easily add more storage capacity as needed. It is faster and less expensive than using a public cloud service, and it provides all the benefits of cloud storage while giving us complete control over our data.

HDFS

The Hadoop Distributed File System (HDFS) is a file system that can be distributed across multiple machines in a cluster. It's designed to run on inexpensive hardware and is highly fault-tolerant. HDFS offers high-throughput access to large datasets, making it ideal for applications that require handling of massive data.

HDFS uses a block-based approach for storing files. Each file is divided into a sequence of blocks, with all blocks in a file (except the last one) being of the same size. For reliability, the blocks of a file are replicated across different machines in the cluster.

That's all folks.

In the next blog, I will try to cover more about Databases.

Feel free to comment on how you like my blog on the system design series or shoot me a mail at connect@nandan.dev If you have any queries I will try to answer.

You can also visit my website to read some of the articles at https://nandan.dev/

Stay tuned & connect with me on my social media channels. Subscribe to my newsletter to get regular updates on my upcoming posts.

If you're interested in learning about system design, you can join Design Guru's course on System Design Fundamentals.

Twitter | Instagram | Github | Website

The Basics of Prompts

To understand the magic behind ChatGPT, let's start with the basics. A prompt is essentially a piece of text or code that you provide to the AI model to initiate a conversation or request a specific task. It's like giving instructions to an intelligent assistant, and ChatGPT responds based on the input you provide.

For example, if you want to ask ChatGPT to generate a creative story about a space adventure, your prompt might look like this:

"Once upon a time, in a galaxy far, far away, there was a brave astronaut named Buzz Lightyear. Write a story about Buzz's thrilling journey through the cosmos."

The prompt instructs ChatGPT to generate a story about an astronaut named Buzz Lightyear in a space adventure setting. What makes this fascinating is that prompts can be as simple or as complex as you need them to be.

Creative Writing

Prompts have opened up exciting possibilities for writers and content creators. ChatGPT can assist with brainstorming ideas, generating story outlines, and even producing entire articles or pieces of fiction. By providing a well-crafted prompt, you can tap into the AI's creative abilities to jumpstart your writing process.

For instance, you could use ChatGPT to:

• Generate creative story plots or twists.

• Compose catchy headlines for blog posts or articles.

• Draft engaging dialogue for characters in a novel.

• Create captivating product descriptions for e-commerce websites.

The flexibility of prompts makes ChatGPT an invaluable tool for writers seeking inspiration or assistance with their projects.

Problem Solving and Information Retrieval

Prompts are not limited to creative writing; they are equally adept at solving problems and retrieving information. ChatGPT can be your virtual assistant for tasks such as:

• Answering questions on a wide range of topics.

• Providing code snippets for programming challenges.

• Translating text from one language to another.

• Summarizing lengthy documents or articles.

• Assisting with research by generating ideas and insights.

By crafting precise prompts, you can harness the AI's knowledge and problem-solving abilities to tackle a variety of tasks efficiently.

Conversation and Chatbots

ChatGPT is also well-suited for creating chatbots and simulating human-like conversations. You can use prompts to initiate dialogue with the AI model and build chat-based applications. Whether it's for customer support, virtual assistants, or interactive storytelling, ChatGPT's conversation capabilities are impressive and adaptable.

Tips for Crafting Effective Prompts

While prompts are incredibly versatile, there are a few tips to keep in mind when crafting them:

1. Be Clear and Specific: Clearly define your request or question in the prompt to get the desired response.

2. Experiment: Don't be afraid to experiment with different prompts to see what works best for your needs.

3. Use Context: You can provide context in your prompts, reference previous messages in a conversation, or set the persona of the AI to guide the responses.

4. Review Output: Always review and edit the output generated by ChatGPT to ensure accuracy and coherence.

Conclusion

Prompts are the gateway to unlocking the potential of ChatGPT. Whether you're a writer seeking creative inspiration, a developer building applications, or someone looking for quick answers and solutions, ChatGPT's capabilities are at your fingertips. With a well-crafted prompt, you can harness the power of artificial intelligence to enhance your productivity and creativity.

As technology continues to advance, the possibilities for ChatGPT prompts are only limited by our imagination. So, go ahead, experiment, and see how ChatGPT can assist you in achieving your goals and bringing your ideas to life. The future of AI-powered interactions is here, and it all starts with a prompt.

Feel free to comment on how you like my blog or shoot me an mail at connect@nandan.dev If you have any queries and I will try to answer.

You can also visit my website to read some of the articles at nandan.dev

Stay tuned & connect with me on my social media channels. Make sure to subscribe to my newsletter to get regular updates on my upcoming posts.

Twitter | Instagram | Github | Website

This helps prevent variable and function name clashes, improves code maintainability, and promotes the concept of separation of concerns.

Here's an example of how you can implement the Module Design Pattern in JavaScript:

// Module using the Module Design Pattern
var Module = (function() {
  // Private variable
  var privateVariable = "I am a private variable";

  // Private function
  var privateFunction = function privateFunction() {
    console.log("This is a private function");
  }

  // Public function
  var publicFunction = function() {
      console.log("This is a public function");
  }
  // Public interface
  return {
    publicFunction:publicFunction,
    // Public variable accessing private variable
    publicVariable: privateVariable
  };
})();

// Usage of the module
console.log(Module.publicVariable); // Output: "I am a private variable"
Module.publicFunction(); // Output: "This is a public function"

// Trying to access private members directly (will result in an error)
console.log(Module.privateVariable); // Output: undefined
Module.privateFunction(); // Output: Uncaught TypeError: MyModule.privateFunction is not a function

In the above example, we've created a module called Module using an Immediately Invoked Function Expression (IIFE). Inside the IIFE, we define private variables and functions that are not accessible from outside the module. We then return an object containing the public members (functions and variables) that we want to expose.

Benefits of the Module Design Pattern:

1. Encapsulation: Private members are not accessible from outside the module, which helps prevent unintended modifications or conflicts with other parts of the codebase.

2. Organization: Code is organized into logical modules, making it easier to manage and understand.

3. Namespacing: The module acts as a namespace, reducing the chances of naming collisions in a global scope.

4. Reusability: Modules can be easily reused in different parts of your application or different projects.

5. Maintenance: Separation of concerns and encapsulation make it easier to maintain and refactor code.

That's a concise explanation of the module design pattern in Javascript.

Feel free to comment on how you like my blog or shoot me a mail at connect@nandan.dev If you have any queries and I will try to answer.

You can also visit my website to read some of the articles at nandan.dev

Stay tuned & connect with me on my social media channels. Make sure to subscribe to my newsletter to get regular updates on my upcoming posts.

Twitter | Instagram | Github | Website