DEV Community: Nandan Kumar

Bulk-Adding Google Workspace Domain Aliases Without Service-Account Keys

Nandan Kumar — Sun, 16 Aug 2026 06:35:00 +0000

Managing one domain in Google Workspace is straightforward. Managing ten, twenty, or more domains across several brands is where the process starts to hurt.

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:

Open the Google Admin console.
Add a domain alias.
Copy Google's verification token.
Open the DNS provider.
Create the TXT record.
Wait for DNS propagation.
Ask Google to verify the domain.
Configure MX records.
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:

Check whether the domain is already verified.
Check whether the Workspace alias already exists.
Read the current GoDaddy DNS records.
Request a Google verification token when needed.
Add the token as an apex TXT record if it is missing.
Poll public DNS until the token is visible.
Ask Google to verify ownership.
Create the Workspace domain alias under the configured parent.
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:

List existing records of the relevant type.
Normalize record names and values.
Create the record only when an exact match is absent.
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:

Export or back up every DNS zone.
Put one non-critical domain in a pilot CSV.
Run plan.
Inspect any existing MX records.
Run apply without the MX flag.
Confirm the alias in the Google Admin console.
Test receiving mail after the approved MX change.
Confirm outbound authentication separately.
Expand to small batches.
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.

How I Moved My Google AI Studio App to GitHub CI

Nandan Kumar — Sun, 12 Jul 2026 05:59:58 +0000

Kitaaben started life in Google AI Studio. No shame in that — it's genuinely the fastest way I know to get a full-stack app with Firebase wired up and live. But "fast to start" and "where your code should live forever" are two different things.

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

Give it a read.

Nandan Kumar — Thu, 25 Jun 2026 05:13:21 +0000

Nandan Kumar

Jun 25

I Got Tired of Goodreads. So I Built Kitaaben.com

#books #bookreview #bookstagram

3 min read

I Got Tired of Goodreads. So I Built Kitaaben.com

Nandan Kumar — Wed, 24 Jun 2026 15:57:55 +0000

I read a lot. Not as much as I'd like to, but enough that I needed a place to keep track of it all.

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	Kitaaben
Last major update	Years ago	Actively built
Social feed	Yes, and you can't remove it	No. Just your books.
Ads	Yes	Never
Data privacy	Amazon owns everything	Private, encrypted, yours
AI reviews	No	Yes
Offline support	No	Yes (PWA)
Design	Dated	Clean, warm, actually nice
Free tier	Yes	Yes

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

How to Convert Nested Objects to Flat Objects in JavaScript.

Nandan Kumar — Wed, 04 Mar 2026 00:59:34 +0000

I am sure you have been asked this question in one of the interviews.

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?

💡

As you know, everything in JavaScript is an object. Even Arrays.

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

Built something over last weekend, thought I will share with my dev community. https://bailoutt.com

Nandan Kumar — Tue, 23 Sep 2025 16:11:02 +0000

BailOutt | Escape Awkward Situations | AI Fake Call Service | Social Anxiety Solution

Never get trapped in awkward situations again. Get real, believable phone calls from real numbers when you need them most. BailOutt’s AI-powered fake call service helps you escape bad dates, long meetings, and social anxiety with ease.

bailoutt.com

HTML Pitfalls and Gotchas Every Developer Should Avoid

Nandan Kumar — Fri, 05 Sep 2025 04:23:19 +0000

HTML is easy, said every developer ever.

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, its easy to miss some of the basic stuff that needs to be taken care of in your webpage, because your frameworks boilerplate code adds up most of the stuff and takes care of the basics. But its always good to know some of them that are important or arent 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; Thats 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 templatesyour 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.

Thats 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. Dont forget to subscribe to my newsletter for regular updates on JavaScript topics!

Twitter | Instagram | Github | Website

Accessibility in Front End Development

Nandan Kumar — Sat, 09 Aug 2025 16:57:50 +0000

Let me start with this: Accessibility is not a buzzword; its a crucial feature that every web application should have.

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, lets 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)

Principle	Description
Perceivable	Content must be perceivable by all (e.g., alt text, captions)
Operable	All functionality must work via keyboard or assistive devices
Understandable	Content should be readable and predictable
Robust	Must work with various assistive technologies

How can people with disabilities use the applications

Accessibility Need	Requirement / Support
Visual Impairment	Should be usable with screen readers, VoiceOver, and font scaling support
Hearing Loss	Closed captions for video and audio
Motor Impairment	Keyboard accessibility support
Cognitive Limitation	Simple language

Accessibility Standards

Web Content Accessibility Guidelines (WCAG)

Defines Accessibility levels as A , AA & AAA

Accessible Rich Internet Applications (ARIA)

Adds accessibility support to non-semantic elements.

Americans with Disabilities Act (ADA)

Legal mandate in the US for accessible digital content

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.

Tool	Use Case
axe DevTools	Chrome extension to audit a11y
Lighthouse	Built-in browser audits
NVDA / VoiceOver	Screen reader testing
Tab key	Test keyboard navigation

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.

Thats 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. Dont forget to subscribe to my newsletter for regular updates on JavaScript topics!

Twitter | Instagram | Github | Website

Instagram Front-End System Design

Nandan Kumar — Fri, 01 Aug 2025 05:19:41 +0000

Let me start by putting one thing forward: System design is not about writing a memorised answer on paper. Its more about thinking, planning and strategising.

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 isnt 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.

Polyfills of JS Array Methods - Flat, Map, Filter & Reduce

Nandan Kumar — Tue, 13 May 2025 14:03:11 +0000

Alright, confession time, Ive been writing JavaScript for a while now, but theres something oddly satisfying about going back to the basics. You know, like trying to bake your bread from scratch even though you live next to a bakery. Thats exactly what this post is about: baking our versions of some classic array methods.

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 youll casually say, "Sure, do you want it with comments or without?"

Today, were building polyfills for:

flat()
map()
filter()
reduce()

Lets 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.

Thats 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. Dont forget to subscribe to my newsletter for regular updates on JavaScript topics!

Twitter | Instagram | Github | Website

Polyfills for Call, Apply, and Bind — Let’s Build Them From Scratch

Nandan Kumar — Mon, 28 Apr 2025 16:51:28 +0000

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

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

But no worries. Youre 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 theyre 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 doesnt 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 lets make our versions

Polyfill for call

Heres 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, lets 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 doesnt 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.

Thats 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, its just about creatively manipulating JavaScripts 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, thats a quote from Shoe Dog. Still fits perfectly here, doesnt it?)

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

Thats 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. Dont forget to subscribe to my newsletter for regular updates on JavaScript topics!

Twitter | Instagram | Github | Website

I Vibe Coded an AI Book Recommendation App and was DDOS-ed for it.

Nandan Kumar — Tue, 15 Apr 2025 10:37:13 +0000

Last week, Google introduced its AI copilot Firebase Studio, and I decided to give it a try. It got me thinking about what I want to do next.

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 friends WhatsApp group, Instagram, Twitter( now X), Linkedin almost everywhere I could.

But seems like someone didnt 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 didnt 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

Thats 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. Dont forget to subscribe to my newsletter for regular updates on JavaScript topics!

Twitter | Instagram | Github | Website