DEV Community: Arka Chakraborty

My side project's deployment pipeline is 8 lines of JSON.

Arka Chakraborty — Mon, 21 Sep 2026 09:52:32 +0000

My side project's deployment pipeline is 8 lines of JSON.

No CI config. No build scripts. No YAML.

Full screen recording

#github #vercel #cicd #deployment | Arka Chakraborty

My side project's deployment pipeline is 8 lines of JSON. No CI config. No build scripts. No YAML. I connected the GitHub repo to Vercel, added one vercel.json, and now pushing to git is the deploy. ━━━━━━━━━━━━━━━━━━━━ Some things to keep in mind: ➤ You only get 100 deployments a day ➤ Each deployment gets it's own URL ➤ The PROD URL is an alias that points to the URL of the latest PROD deployment. ➤ Easy rollback. A rollback doesn't rebuild or redeploy anything. It just repoints the domain to a previous deployment at the routing layer. Takes seconds. ➤ Vercel offers 2 envs for deployment: Preview & Production ━━━━━━━━━━━━━━━━━━━━ How to deploy? CLI version: ➤ vercel (deploys to preview env) ➤ vercel --prod (do I need to explain?) ━━━━━━━━━━━━━━━━━━━━ Git push version: ➤ git push to master or main → deploys to Vercel Production env ➤ git push to any feature branch → deploys to Vercel Preview env ━━━━━━━━━━━━━━━━━━━━ But since both count towards your daily 100 deployment quota, I have personally disabled deploying to preview env via git push to feature branch, ➤ I deploy to preview branch via "vercel" cli command OR ➤ deploy to Production using "git push origin main" or "vercel --prod" To do that include a small 【vercel.json】script that disables deployment for git push to feature branch, If you need the script, comment or DM me ! #github #vercel #cicd #deployment

linkedin.com

I connected the GitHub repo to Vercel, added one vercel.json, and now pushing to git is the deploy.

Some things to keep in mind

➤ You only get 100 deployments a day

➤ Each deployment gets its own URL

➤ The PROD URL is an alias that points to the URL of the latest PROD deployment.

➤ Easy rollback. A rollback doesn't rebuild or redeploy anything. It just repoints the domain to the URL of the previous deployment at the routing layer. Takes seconds.

➤ Vercel offers 2 envs for deployment:

Preview
Production

How to deploy?

CLI version

vercel

Deploys to the Preview env.

vercel --prod

Do I need to explain?

Git push version

git push to master or main
        ↓
Vercel Production env

git push to any feature branch
        ↓
Vercel Preview env

But since both count towards your daily 100 deployment quota...

I have personally disabled deploying to the Preview env via git push to feature branch.

Instead:

➤ I deploy to Preview via the vercel CLI command.

vercel

➤ Deploy to Production using:

git push origin main

or:

vercel --prod

How?

Include a small vercel.json configuration that disables deployment for git push to feature branch.

If you need the vercel.json configuration, comment or DM me!

Production broke due to un-synced secrets

Arka Chakraborty — Sun, 20 Sep 2026 13:03:58 +0000

I run a Next.js side project deployed on Vercel, with all secrets managed in Doppler and synced to Vercel through the native Doppler↔Vercel integration. No .env files anywhere: secrets get injected at runtime locally, and synced as Sensitive env vars in Vercel for preview and production.

This week the production sync silently broke. Here's the whole thing, from discovery to fix, because the root cause is a quirk almost nobody documents.

The setup

Two syncs configured in the Doppler dashboard (Integrations → Vercel), each with import option Prefer Doppler:

Vercel scope	Doppler config
Preview	`stg`
Production	`prd`

Locally, scripts run through doppler run so secrets are injected without a file:

npm run dev    # doppler run -- next dev
npm run build  # doppler run -- next build

Vercel's build command is plain next build: no CLI, no DOPPLER_TOKEN. The integration owns the env vars.

How I noticed

I rotated a secret in Doppler, redeployed production, and the app was still running on the old value. Classic "did I actually deploy?" moment.

Checked the Vercel dashboard: the variable still had the old value. Checked Doppler: the new value was there. The sync between them had failed, and the failure mode was the interesting part. The integration couldn't write to the variables that already existed in Vercel.

Root cause: Vercel Sensitive env vars are write-once via the API

Once an env var exists in Vercel, especially a Sensitive one, the API can't:

update its value
convert a non-sensitive var to Sensitive
read it back to compare (that's the point of Sensitive: Vercel won't return the value, even to integrations)

So the integration can't reconcile existing vars. It doesn't patch around it; the sync just fails for those keys.

Why did my vars already exist? Because when I first set the project up, I created a few env vars by hand in the Vercel dashboard before wiring up the Doppler sync. They were in the wrong state (some non-sensitive, some sensitive) and the integration had been quietly unable to touch them ever since.

The fix

Low-tech, slightly nerve-wracking, but clean:

1. Delete the conflicting variables from Vercel.

Via the Vercel CLI, or in the dashboard under Settings → Environment Variables:

vercel link                      # if not already linked to the project
vercel env ls production         # see what's there
vercel env rm SECRET_NAME production
# repeat for each conflicting var

Note: vercel env ls shows sensitive vars exist but can't show their values. Consistent with the whole write-once model.

2. Re-sync from Doppler.

Dashboard → Integrations → Vercel → your sync → hit sync again. I went one step further and deleted the whole integration, then re-created it as a full reset. That works, but it means redoing the config→scope mapping. Deleting just the vars and re-syncing is the lighter path; the integration recreates them itself as Sensitive.

3. Redeploy.

Env var changes don't apply retroactively: existing deployments keep the values they were built with.

git push          # or: vercel --prod

4. Verify.

App healthy, new secret values live, and the vars in the Vercel dashboard now show as Sensitive, created and owned by the integration this time.

Screen recording of the full cleanup + re-sync

Why I'll never pre-create env vars again

The whole failure traces back to one decision: creating vars in the Vercel dashboard "temporarily" before setting up the integration. Once they existed, the sync could never reconcile them, and the failure was silent enough that I only noticed when a rotated secret didn't take effect.

The rule going forward: let the integration own your env vars from day one. If a secrets sync is going to manage a variable, never create it manually, not even temporarily. If you inherit a project where vars already exist, delete them first and let the sync recreate them cleanly.

And operationally: know which secrets your deploys actually depend on before deleting anything. Deleting production env vars by hand is fine, as long as you can recreate them from your source of truth. That's the entire point of having one.

If you've hit this same wall with Doppler↔Vercel, would love to hear how you handled it.

Production crashed after adding a view !

Arka Chakraborty — Mon, 22 Jun 2026 04:29:47 +0000

Problem

There was an existing CronJob (data refresh + dump) :

drop a table
create table
dump new data in table (Insert)

The code was already there in a deployed application.

The issue: recently I had to create a view which depended on this table.

Hence I now got an error:

some additional context: I am using PostgreSQL

ERROR : <file name> : [functionname] ERROR dumping into table <table name>
[time stamp] ERROR : <file name> : cannot drop table <table name> because other objects depend on it
DETAIL:  view <view name> depends on table <table name>
HINT:  Use DROP ... CASCADE to drop the dependent objects too.
Traceback (most recent call last):
<stack trace>

Possible solutions

I had a few routes I could explore to resolve this, keep in mind, race conditions were to be avoided in this refactor + critical issue affecting data refresh.

Solutions possible:

DROP TABLE ... CASCADE - Drops view, breaks other pods
DROP TABLE without CASCADE - Original failing approach (DependentObjectsStillExist)
DELETE FROM - Slower, preserves structure
TRUNCATE TABLE - Current implementation (fast, transaction-based)
Temporary table + atomic swap - View sees old data until swap

Solution implemented

Transaction based Truncate + Insert

Why?

Preserves view dependencies

No CASCADE needed
view stays intact
Other pods unaffected (service deployed in k8s, multiple pods)

Performance

Much faster than DELETE (deallocates pages vs logging each row)
Handles 100k+ rows efficiently

Transaction safety

TRUNCATE + INSERT in single transaction
View never sees empty data (MVCC isolation)
Atomic operation (all-or-nothing)

Simplicity

No temp tables needed
No complex swap logic
Minimal code changes
Easy to maintain

Best balance

Solves the original problem (no DependentObjectsStillExist error)
Fast enough for data refresh
Safe for concurrent access
Simple implementation

def dump_data_to_table(data: pd.DataFrame, table_name: str):
    """
    Updated approach: TRUNCATE + INSERT in transaction
    Preserves view dependencies and ensures data consistency
    """
    conn = psycopg2.connect(...)
    cur = conn.cursor()

    # TRUNCATE preserves table structure & views (no DROP needed)
    cur.execute(f"TRUNCATE TABLE {table_name}")

    # Insert new data
    cols = ', '.join([f'"{col}"' for col in data.columns])
    placeholders = ', '.join(['%s'] * len(data.columns))
    insert_sql = f"INSERT INTO {table_name} ({cols}) VALUES ({placeholders})"

    values = [tuple(row) for row in data.values]
    execute_batch(cur, insert_sql, values, page_size=5000)

    # Single transaction commit (atomic operation)
    conn.commit()

Conclusion

Always implement transaction based, atomic operations from get go. Consider possible future edge cases such as dependent views/objects. Handle data dump accordingly.

In typescript...if a function returns nothing, is the return type of function signature "void" or "undefined"? Well both are correct, confused...? The answer lies in understanding compile time vs runtime!!!

Arka Chakraborty — Wed, 17 Sep 2025 06:58:30 +0000

Arka Chakraborty

Sep 16 '25

Void vs Undefined in TypeScript: Runtime vs Compile-Time Explained

#react #webdev #javascript #typescript

2 min read

Void vs Undefined in TypeScript: Runtime vs Compile-Time Explained

Arka Chakraborty — Tue, 16 Sep 2025 10:15:17 +0000

🔥 Intro

When a TypeScript function doesn’t return anything, does it return voidor undefined?
At runtime, JavaScript always gives you undefined.
At compile-time, TypeScript shows void.
Let’s unpack this apparent contradiction.

🕹 Runtime (JavaScript) Perspective

JavaScript doesn’t have void. Every function call evaluates to something.
If you don’t return explicitly, it evaluates to undefined.

function greet(name: string) {
  console.log(`Hello, ${name}!`);
}

console.log(greet("Arka")); 
// Output:
// Hello, Arka!
// undefined

👉 At runtime, the actual return value is always undefined.

🛠 Compile-Time (TypeScript) Perspective

TypeScript isn’t executing your code. It’s describing intent at compile-time.
When you don’t return anything, TypeScript marks the return type as void.

function greet(name: string): void {
  console.log(`Hello, ${name}!`);
}

const result = greet("Arka"); 
// result has type void (not undefined)

👉 At compile-time, void means:
“Don’t rely on or use the return value.”

❌ Why Not Just undefined?

Let’s try making the return type undefined:

function greet(name: string): undefined {
  console.log(`Hello, ${name}!`);
}

⚡ Compile-time error:

Function lacks ending return statement and return type does not include 'undefined'

Because if you use undefinedas a type, TypeScript expects you to explicitly return undefined:

function doNothing(): undefined {
  return undefined; // ✅ valid
}

So:

Runtime value: undefined
Compile-time type: void(unless you explicitly force undefined)

🚩 Async Functions

The same rule applies for async functions:

async function greetAsync(name: string): Promise<void> {
  console.log(`Hello, ${name}!`);
}

At runtime: returns Promise.resolve(undefined)
At compile-time: return type is Promise<void>

Arrow version:

const greetAsync = async (name: string): Promise<void> => {
  console.log(`Hello, ${name}!`);
};

🏗 Real-Life Example

function logger(message: string): void {
  console.log(`[LOG]: ${message}`);
}

async function saveData(data: string): Promise<void> {
  await new Promise(res => setTimeout(res, 1000));
  logger(`Saved: ${data}`);
}

Runtime: logger returns undefined, saveData resolves to undefined.
Compile-time: TypeScript shows voidand Promise<void>.

💡 Key Takeaways

Runtime (JavaScript): No-return functions → always return undefined.
Compile-time (TypeScript): Uses void(or Promise<void>) to signal “don’t use the return value.”
undefinedas a type: Too strict; requires explicit return undefined;.
Rule of Thumb: Use voidfor functions with no meaningful return.
So, next time you see voidin TypeScript, remember: it’s a compile-time abstraction, while undefinedis the actual runtime value.

What’s the Return Type of a Function That Returns Nothing in TypeScript?

Arka Chakraborty — Tue, 16 Sep 2025 10:08:09 +0000

📌Intro

If a function doesn’t return anything, what’s its return type in TypeScript? Many developers guess undefinedbut the real answer is a bit more nuanced. Let’s break it down with examples.

🚩 Case 1: Normal Functions (No Return)

When you don’t return anything from a normal function, TypeScript infers its return type as void.

function logMessage(message: string): void {
  console.log(message);
}

Even if you don’t annotate it, TypeScript will automatically infer it:

function logMessage(message: string) {
  console.log(message);
}
// inferred as: (message: string) => void

At runtime, this function technically returns undefined, but TypeScript uses voidto say “ignore the return value.”

🚩 Case 2: Async Functions (No Return)

For asyncfunctions, it’s just Promise<void>.

async function logMessage(message: string): Promise<void> {
  console.log(message);
}

Or with arrow functions:

const logMessage = async (message: string): Promise<void> => {
  console.log(message);
};

Even if you don’t write the annotation, TypeScript infers Promise<void>.

🤔 Why Not undefined?

It’s tempting to write:

function logMessage(message: string): undefined {
  console.log(message);
}

But this will error:

Function lacks ending return statement and return type does not include 'undefined'

That’s because undefinedmeans the function must explicitly return undefined.

Example of correct undefinedreturn:

function doNothing(): undefined {
  return undefined; // ✅ works
}

But in most cases, what you want is void, not undefined.

🏗 Real-Life Example

A logger utility:

function logger(message: string): void {
  console.log(`[LOG]: ${message}`);
}

async function saveAndLog(data: string): Promise<void> {
  // simulate saving
  await new Promise(res => setTimeout(res, 1000));
  logger(`Saved data: ${data}`);
}

Here:

logger returns nothing → void
saveAndLog is async → Promise<void>

💡 Extras

void= “I don’t care about the return value.”
undefined= “This function must return undefined explicitly.”

👉 Always prefer voidunless you specifically want to enforce return undefined;.

Async Arrow Functions in TypeScript (With React Examples)

Arka Chakraborty — Tue, 16 Sep 2025 09:58:30 +0000

📌Intro

In modern TypeScript (and React), arrow functions are everywhere. The good news: async works perfectly with them.

🧠Context

Arrow functions are used in event handlers, array methods, and inline logic. Knowing asyncwith arrows is essential.

Examples:

// Async arrow
const fetchData = async (): Promise<string> => {
  const res = await fetch("/api/message");
  const data = await res.json();
  return data.message;
};

// React handler
const handleSubmit = async (event: React.FormEvent) => {
  event.preventDefault();
  const msg = await fetchData();
  console.log("Message:", msg);
};

// With map + Promise.all
const urls = ["/a", "/b", "/c"];

const fetchAll = async () => {
  const results = await Promise.all(
    urls.map(async url => {
      const res = await fetch(url);
      return res.json();
    })
  );

  console.log(results);
};

📝Real life examples

Form submission in React (onSubmit).
Loading multiple APIs in parallel.

⚠️ forEach(async...) doesn’t work as you expect. Always use map+ Promise.all.

Async vs Await, isn’t This Just Synchronous?

Arka Chakraborty — Tue, 16 Sep 2025 09:13:36 +0000

📌Intro

If awaitpauses execution… doesn’t that make it synchronous again? This is the #1 async misconception.

🧠Context

awaitlooks synchronous but isn’t.
It pauses only the current async function, without blocking the event loop.

Examples:

async function main() {
  console.log("Before");
  await new Promise(res => setTimeout(res, 1000));
  console.log("After");
}

main();
console.log("Outside");

// Output:
// Before
// Outside
// After

Arrow version:

const main = async () => {
  console.log("Start");
  await new Promise(res => setTimeout(res, 1000));
  console.log("Done");
};

main();

💡Real-Life Example:

Your UI doesn’t freeze while waiting for a network call.
E.g., while checking login, users can still scroll, click, or type.

JavaScript is single-threaded, but async/await lets you write non-blocking code that looks clean.

Real life examples of async function signatures in React + Typescript

Arka Chakraborty — Tue, 16 Sep 2025 09:07:35 +0000

Async Function Returning a Boolean — A Practical Example

💡Intro

Theory is boring. Let’s check something real: is a user logged in? That’s a simple Boolean but in modern apps, it’s often async.

🧠Context

Sync version works if the info is instantly available.
But in practice, you check from a server or token → async.

Examples

// Synchronous
function isUserLoggedIn(): boolean {
  return true;
}

// Async
async function isUserLoggedIn(): Promise<boolean> {
  const response = await fetch("/api/check-login");
  const data = await response.json();
  return data.loggedIn;
}

// Arrow version
const isUserLoggedIn = async (): Promise<boolean> => {
  const response = await fetch("/api/check-login");
  const data = await response.json();
  return data.loggedIn;
};

💡Real-Life Example:

Even if you currently return true, keeping the function async future-proofs your code when you switch to an API.

Why Async Functions in TypeScript Always Return a Promise

Arka Chakraborty — Tue, 16 Sep 2025 07:08:10 +0000

📌Intro

You write a simple asyncfunction, return 42, and suddenly TypeScript yells:
“Type 'number' is not assignable to type 'Promise'.”
Why can’t an async function just return a value? Let’s break it down.

🧠Context & Why:

The asynckeyword in TypeScript (and JavaScript) changes how the function behaves:

Every asyncfunction always returns aPromise<T>.
Even if you return a raw value, it’s wrapped in Promise.resolve(value).

Examples:

// Normal function
function getFavoriteNumber(): number {
  return 26;
}

// Async function
async function getFavoriteNumber(): Promise<number> {
  return 26; // Actually Promise.resolve(26)
}

// Arrow version
const getFavoriteNumber = async (): Promise<number> => {
  return 26;
};

If you try:

async function getFavoriteNumber(): number {
  return 26;
}

TypeScript error:

Type 'number' is not assignable to type 'Promise<number>'.

Real-Life Example:

You might start with a hardcoded value, but later fetch it from an API. Making it async upfront saves refactoring:

const getFavoriteNumber = async (): Promise<number> => {
  const res = await fetch("/api/fav-number");
  const data = await res.json();
  return data.number;
};

💡Think of asyncas a “Promise factory.” Whatever you return gets gift-wrapped in a Promise.

React + TypeScript: async functions

Arka Chakraborty — Tue, 16 Sep 2025 06:54:20 +0000

When working with TypeScript, one of the most common confusions is around asyncfunctions and their return types. Let’s clear this up with a practical example.

📝A Practical Example: Checking If a User Is Logged In

Imagine you’re building an app where you need to check if a user is logged in.

Synchronous version

function isUserLoggedIn(): boolean {
  return true;
}

This works fine if the answer is always available instantly.

Asynchronous version

But in real-world apps, login status often comes from a server or database:

async function isUserLoggedIn(): Promise<boolean> {
  const response = await fetch("/api/check-login");

  if (!response.ok) {
    return false;
  }

  const data = await response.json();
  return data.loggedIn; // true or false
}

Notice:

The return type is Promise<boolean> (not boolean).
Even though we return trueor false, the value is wrapped in a Promise.

❓Why Promise and not boolean?

Every asyncfunction in TypeScript always returns a Promise.

So this:

return true;

is really:

return Promise.resolve(true);

That’s why the return type must be Promise<boolean>.

If you mistakenly annotate it as just boolean:

async function isUserLoggedIn(): boolean {
  return true;
}

You’ll get a compile error:

Type 'boolean' is not assignable to type 'Promise<boolean>'.

📝Using the Async Function

// With await
const loggedIn = await isUserLoggedIn();
console.log(loggedIn); // true or false

// Or with .then()
isUserLoggedIn().then(status => console.log(status));

⚠️Misconception: Isn’t This Synchronous Because of await?

A common doubt: “If we’re awaiting, aren’t we back to synchronous execution?”

Answer: No.

awaitpauses execution only in the current function until the Promiseresolves.
But it does not block the event loop. Other tasks can keep running.

So:

Asyncfunctions are still asynchronous under the hood.
awaitjust gives you synchronous-looking syntax for cleaner code.

Example:

async function main() {
  console.log("Before");
  await isUserLoggedIn(); // pauses *this* function only
  console.log("After");
}

main();
console.log("Outside");

Output order:

Before
Outside
After

Notice how "Outside" runs while we were “waiting.” That’s the power of async/await.

📌Async Arrow Functions

asyncworks seamlessly with arrow functions. This is very common in modern TypeScript and React projects.

Example with arrow function

const isUserLoggedIn = async (): Promise<boolean> => {
  const response = await fetch("/api/check-login");
  const data = await response.json();
  return data.loggedIn;
};

In a React handler

const handleSubmit = async (event: React.FormEvent) => {
  event.preventDefault();

  const success = await isUserLoggedIn();
  console.log("Login status:", success);
};

With array methods

Arrow functions and asyncoften pair with array operations:

const urls = ["/a", "/b", "/c"];

const fetchAll = async () => {
  const results = await Promise.all(
    urls.map(async url => {
      const res = await fetch(url);
      return res.json();
    })
  );

  console.log(results);
};

💡Key Takeaways

asyncfunctions always return Promise<T>, never just T.
Returning a raw value auto-wraps it in Promise.resolve(value).
awaitpauses locally but doesn’t block the event loop.
Async arrow functions are common in callbacks, handlers, and array methods.
Use asyncwhen dealing with APIs, databases, or any future async work — it future-proofs your function signatures.

Discriminated Unions in TypeScript: How They Differ from Plain Type Unions

Arka Chakraborty — Mon, 15 Sep 2025 08:35:36 +0000

Type Union vs Discriminated Unions

All unions are not equal, some are smart enough to know what fields exist in each branch.

🧠Context

React components often handle multiple states: forms (loading, success, error), modals (open, closed), or API responses (data vs error).
A common confusion is the difference between plain type unions and discriminated unions. Understanding this distinction helps you write safer, more maintainable React components.

📌Plain Type Unions

A plain union is a type that can hold multiple literal values or types, but TypeScript does not associate additional fields with each value.

type Status = "loading" | "success" | "error";

function render(status: Status) {
  if (status === "success") {
    // ❌ Can't attach extra info like "data"
    return "Form submitted!";
  }
  return "Not submitted";
}

⚠️Limitations of plain unions:

No structured data per state
No automatic type narrowing for properties
Good only for simple flags

📌Discriminated Unions

A discriminated union is a union of objects where each object has:
A discriminant property (usually a literal string like "status" or "type")
Optional additional fields unique to that branch

📝How TypeScript narrows types

type FormState =
  | { status: "loading" }
  | { status: "success"; data: string }
  | { status: "error"; message: string };

function renderForm(state: FormState) {
  if (state.status === "loading") return <p>Loading...</p>;
  if (state.status === "success") return <p>Submitted: {state.data}</p>;
  if (state.status === "error") return <p>Error: {state.message}</p>;
}

TS automatically narrows the type of state based on the discriminant (status)
Each branch has access only to its relevant fields (data, message)

📌With vs Without Discriminated Unions

//Without discriminated unions

type FormState = "loading" | "success" | "error";

function renderForm(state: FormState) {
  if (state === "success") {
    // ❌ Can't attach extra info like data
    return "Form submitted!";
  }
}

//With discriminated unions

type FormState =
  | { status: "loading" }
  | { status: "success"; data: string }
  | { status: "error"; message: string };

function renderForm(state: FormState) {
  if (state.status === "success") {
    // ✅ TS knows 'data' exists
    return `Form submitted with: ${state.data}`;
  }
}

💡Real-Life React Use Cases

Form State Example

type FormState =
  | { status: "idle" }
  | { status: "submitting" }
  | { status: "success"; result: string }
  | { status: "error"; message: string };

function Form({ state }: { state: FormState }) {
  switch (state.status) {
    case "idle": return <button>Submit</button>;
    case "submitting": return <p>Submitting...</p>;
    case "success": return <p>{state.result}</p>;
    case "error": return <p>{state.message}</p>;
  }
}

Modal Example

type ModalState =
  | { open: true; content: string }
  | { open: false };

function Modal({ state }: { state: ModalState }) {
  if (!state.open) return null;
  return <div>{state.content}</div>;
}

📌Key Takeaways

Plain unions are fine for flags, but they cannot carry per-case data.
Discriminated unions let TypeScript know exactly which fields exist per case, making components safer.
For React apps, always prefer discriminated unions for component states, API responses, and mutually exclusive props.