Forem: rashidpbi

The Hidden Complexity of Web Authentication: Why Every Developer Should Build Their Own (At Least Once)

rashidpbi — Thu, 28 Aug 2025 02:07:08 +0000

Picture this: You're building your next web application, and authentication is on your todo list. Your first instinct? Reach for Clerk, Auth0, or NextAuth.js. They're battle-tested, secure, and save you weeks of development time. But here's the thing—by always taking the easy route, you might be missing out on understanding one of the most critical aspects of web security.

After implementing my own OAuth 2.0 authentication system from scratch, I discovered that what seems like straightforward user management is actually a minefield of edge cases, security considerations, and subtle gotchas that can break your application in production.

The Authentication Trinity: More Than Just Login Forms

Most developers think of authentication as simply verifying usernames and passwords. But in reality, modern web authentication involves three interconnected concepts that work together:

Authentication is about identity verification—proving who the user claims to be. This happens when someone enters their credentials or connects through OAuth providers like Google or GitHub.

Authorization determines what that authenticated user can actually do within your application. Just because someone can log in doesn't mean they should access admin panels or sensitive data.

Redirection ties everything together by controlling the user's journey through your application. It ensures logged-in users don't see login pages and unauthenticated users can't access protected content.

The magic happens in how these three work together. When a user logs in through Google OAuth, they're redirected to Google's servers for authentication, then back to your app with an authorization code, which you exchange for tokens that determine what they can access. Miss any step in this dance, and your security falls apart.

The Token Juggling Act: Where Things Get Complicated

OAuth 2.0 introduces a layer of complexity that catches many developers off guard. Unlike simple session-based authentication, OAuth involves managing two types of tokens with different lifespans and purposes.

Access tokens are your golden tickets—they prove the user is authenticated and authorized to access resources. But they're intentionally short-lived, typically expiring after just one hour. This creates a user experience problem: nobody wants to log in every hour.

Refresh tokens solve this by lasting much longer (usually about a week) and can generate new access tokens behind the scenes. But here's where it gets tricky—these refresh tokens are only provided during the initial authorization flow. If something goes wrong and you lose them, the user has to start over.

This is where understanding beats blindly using libraries. When you know why tokens work this way, you can design your application flow to preserve them properly.

Battle-Tested Lessons from the Trenches

When I built my own authentication system, I encountered scenarios that no tutorial prepared me for. These real-world edge cases taught me more about web security than any documentation could.

The Refresh Token Trap

Google's OAuth 2.0 has a gotcha that bit me hard: refresh tokens are only provided during the first authorization. If a logged-in user accidentally visits your login page and goes through OAuth again, Google won't provide a new refresh token. Your application loses the ability to refresh access tokens, effectively logging the user out after an hour.

The solution? Implement smart redirection logic that prevents authenticated users from accessing the login flow. This isn't just about user experience—it's about maintaining authentication state.

Storage Security: The XSS Vulnerability

Where you store tokens matters more than you might think. Local storage seems convenient, but it's vulnerable to XSS attacks. Any malicious script can read and steal tokens, compromising user accounts.

Server-side storage or secure HTTP-only cookies are the way to go. The tokens never touch client-side JavaScript, making them much harder for attackers to steal.

The Graceful Degradation Challenge

What happens when refresh tokens expire? Many developers handle this poorly, showing confusing error messages or breaking the user experience. The elegant solution is to detect token expiry in your API layer and automatically redirect users back to login with a helpful message.

This requires understanding the token lifecycle well enough to implement proper error handling throughout your application.

Why Libraries Can't Teach You Everything

Don't get me wrong—authentication libraries are fantastic. They handle the heavy lifting of security best practices, token management, and provider integrations. But they also abstract away the underlying mechanics that you need to understand when things go wrong.

When your production application starts throwing authentication errors at 2 AM, you need to understand whether it's a token expiry issue, a storage problem, or a redirection loop. Libraries can't debug themselves—you need to understand what's happening under the hood.

Building your own authentication system once gives you this x-ray vision into how modern web authentication actually works. You'll understand why certain design decisions were made, what trade-offs exist between security and user experience, and how to extend or customize library behavior when needed.

The Learning Investment That Pays Dividends

I'm not suggesting you reinvent the wheel for every project. Use trusted libraries for production applications. But invest time in building your own authentication flow at least once, perhaps as a side project or learning exercise.

You'll gain intuition about:

How OAuth flows actually work beyond the surface level
Why certain security practices exist and when to apply them
How to debug authentication issues in production
When and how to customize library behavior safely

This knowledge transforms you from a developer who implements authentication to one who understands it. And in a world where security breaches make headlines daily, that understanding is invaluable.

The Bottom Line

The next time you reach for an authentication library, you'll do so with confidence, knowing not just how to use it, but why it works the way it does. That's the difference between writing code and engineering secure applications.

Ready to dive deeper into web authentication? Start with implementing a simple OAuth 2.0 flow with Google's APIs. The documentation is excellent, and the lessons you'll learn will serve you throughout your career.

Building a Google Calendar Event Handler (and the Chaos Along the Way)

rashidpbi — Thu, 14 Aug 2025 18:01:42 +0000

This is an update on the Google Calendar event handler I'm building. If you've got a few minutes to spare, come along for the ride — fair warning: some of what follows might be slightly exaggerated for dramatic effect. 😏

I actually regret not documenting the superhuman thought processes, weird developer choices, and decision-making detours I went through while building this "simple" event handler.

The Core Idea

The original goal was simple: test the integrability of Google Calendar with Wraft, the product we’re building at my company.
The setup and core functionality are already ✅ done.

But then I thought… why not polish it further? Add a simple UI, refine the logic, and let it live on as a neat little side project alongside the main product.
Now I'm focusing on design refinements and performance improvements — plus exploring a few custom tweaks to the app's overall logic.

The Developer Confidence Trap

But here's the thing: As developers, over time we gain the confidence that once the basic functionality is done, we can make any improvement — whether it's design, performance, or even reshaping the whole workflow. (Sometimes it even feels like pulling a snake out of the code 🐍).

And yet… I still make wrong turns. Wrong design calls. Wrong performance assumptions. Wrong "this will be easy" moments.

The Reality Check

But that's the fun of it — learning, iterating, and continuing down the road.

So here's to fixing the wrong decisions, improving what's missing, and making this event handler better than it needs to be. Stay tuned for the next update — it might involve fewer snakes. Or more.

🔑 Figuring Out Authentication in Next.js (While Trying Not to Lose My Sanity 😅)

rashidpbi — Sat, 09 Aug 2025 10:35:33 +0000

I'm going to be honest — I'm still figuring out the authentication flow in my Next.js app. Right now, I'm using Google OAuth for a Calendar integration, and every time I think I've nailed it… a token expires and my whole "flawless" login flow collapses.

If you've been down this road, you already know the fun parts:

Cookies disappearing like socks in the dryer
Google's invalid_grant error appearing out of nowhere
That feeling when your API route works only if you log in 5 seconds ago

This post isn't "Here's the perfect authentication guide." It's more like "Here's what I'm doing right now so my app works — but I know there are better ways."

The messy reality of OAuth

Most OAuth tutorials basically stop after:

Click "Sign in with Google"
Get access_token
Call an API 🎉

That's fine for a demo. In real life:

Tokens expire (sometimes faster than you expect)
Refresh tokens aren't always provided
You have to decide where to handle expiry — server, client, or both

Spoiler: I learned you actually need both.

My current API route (work in progress)

Here's the route I'm using to fetch Google Calendar events. It's not perfect, but it's keeping my app from falling apart (most of the time).

// /pages/api/eventList.js
import { google } from "googleapis";
import oauth2Client from "@/utils/google-auth";

export default async function handler(req, res) {
  function getFirstDayOfLastMonth() {
  const now = new Date();
  return new Date(now.getFullYear(), now.getMonth() - 1, 1).toISOString();
}
  const {
    google_access_token,
    expiry_date,
    refresh_token_expires_in,
    refresh_token,
  } = req.cookies;
  if (req.method === "GET") {
    try {
      oauth2Client.setCredentials({
        access_token: google_access_token,
        expiry_date,
        refresh_token_expires_in,
        refresh_token,
      });
      const calendar = google.calendar({ version: "v3", auth: oauth2Client });

      const { data } = await calendar.events.list({
        auth: oauth2Client,
        calendarId: "primary",
        // maxResults:13,
         timeMin: getFirstDayOfLastMonth()
        // timeMin: "2025-07-01T00:00:00.000Z",
      });

      res.status(200).json({ events: data.items });
    } catch (error) {
       console.error("Google API error:", error);

  // Normalize error
  let normalizedError = "Unknown error";

  if (error?.response?.data?.error) {
    normalizedError = error.response.data.error;
  } else if (error?.errors?.length) {
    normalizedError = error.errors[0].message;
  } else if (error?.message) {
    normalizedError = error.message;
  }

  res.status(400).json({ error: normalizedError,  code: error?.code || null });
    }
  } else {
    res.setHeader("Allow", ["GET"]);
    res.status(405).end(`Method ${req.method} Not Allowed`);
  }
}

The good:

If there's no token, I stop immediately.
If Google says the token is bad, I return a 401.

The "still figuring out" parts:

I don't refresh tokens automatically yet.
I don't update cookies when I do get a new token.
My error handling works, but it's not super descriptive.

Client-side "bail out" strategy

Right now, my frontend just looks for 401 and punts the user back to /login.

async function fetchEvents() {
  const res = await fetch("/api/eventList");

  if (res.status === 401) {
    localStorage.setItem("loggedOutDueToTokenIssue", "true");
    window.location.href = "/login";
    return;
  }

  return res.json();
}

It's simple, and it works… but it also means the user gets kicked out even in cases where I could have refreshed the token in the background.

Things I know I need to improve

✅ Automatic token refresh on the server (before hitting Google's API)

✅ Updating cookies when I refresh a token

✅ Returning more structured error messages so the client knows exactly what happened

✅ Maybe centralizing all token logic so I don't repeat it in every route

Final thoughts (for now)

I'm sharing this because sometimes dev posts make it sound like people go from "I want OAuth" to "I have the perfect auth system" in one weekend. The truth is, I'm still tripping over my own code, but each small improvement makes the whole thing less fragile.

If you've built a rock-solid Google OAuth flow in Next.js — especially one that gracefully handles token refresh — please drop your tips in the comments. I could really use them. 🙃

Understanding Middleware in Express.js (With Simple Implementation)

rashidpbi — Wed, 06 Aug 2025 09:15:13 +0000

If you've worked with Express.js, you've probably seen app.use() everywhere. But what exactly is middleware? How does app.use(fn) work behind the scenes?

In this post, let's break down what middleware is and how it works in Express.js

🔑 What is Middleware?

In Express.js, middleware is simply a function that runs during the request-response cycle. It has access to the request object (req), the response object (res), and a special next() function that passes control to the next middleware.

Express uses middleware to handle logging, authentication, error handling, CORS, body parsing, and more.

🏗 The Syntax of Middleware

Middleware is typically added using app.use():

app.use((req, res, next) => {
  console.log('Middleware executed!');
  next(); // Pass control to the next middleware
});

If you don't call next(), the request will hang and never reach the final route handler.

🌐 Common Use Cases of Middleware

Here are a few examples of middleware in action:

1️⃣ Logging Every Request

app.use((req, res, next) => {
  console.log(`${req.method} ${req.url} at ${new Date().toISOString()}`);
  next();
});

✅ This runs for every request and logs request info.

2️⃣ Applying Middleware to Specific Routes

app.use('/admin', (req, res, next) => {
  console.log('Admin route accessed');
  next();
});

✅ Runs only for /admin and its sub-routes.

3️⃣ Using Third-Party Middleware (e.g., CORS)

const cors = require('cors');
app.use(cors());

✅ Enables CORS for all requests.

4️⃣ Serving Static Files

app.use(express.static('public'));

✅ Serves HTML, CSS, JS, and images directly from the public folder.

🚨 Error-Handling Middleware

In Express, error-handling middleware looks slightly different—it has 4 parameters:

app.use((err, req, res, next) => {
  console.error(err.stack);
  res.status(500).send('Something broke!');
});

Express automatically detects this pattern and uses it to catch errors.

🎯 Key Takeaways

✅ Middleware is at the heart of Express.js.

✅ It allows preprocessing of requests before they hit route handlers.

✅ app.use(fn) registers middleware functions in a chain-like system.

✅ Calling next() is crucial to move to the next middleware.

🧵 Understanding JavaScript Promises, Callbacks & Handling Multiple Async Tasks

rashidpbi — Tue, 05 Aug 2025 20:03:22 +0000

JavaScript is single-threaded, yet it handles tasks like API calls, timers, and user interactions efficiently — thanks to callbacks and promises. Let's explore how these tools work together and how to manage multiple async operations.

🧠 Callback & Asynchronicity

A callback is a function passed into another function to run later — perfect for async tasks like fetching data or waiting for a timeout.

setTimeout(() => {
  console.log("This runs later");
}, 1000);

But callbacks can lead to callback hell, making code hard to read and maintain.

🚀 Enter Promises

A Promise represents a value that may be available now, later, or never.

const fetchData = new Promise((resolve, reject) => {
  setTimeout(() => resolve("Done!"), 2000);
});

fetchData.then(console.log).catch(console.error);

Using async/await improves readability even more:

async function getData() {
  try {
    const result = await fetchData;
    console.log(result);
  } catch (err) {
    console.error(err);
  }
}

🔄 Handling Multiple Promises

JavaScript provides powerful utilities for handling multiple promises at once:

✅ `Promise.all([...])`

Waits for all promises to resolve. Fails fast if any reject.

Promise.all([p1, p2, p3])
  .then(console.log)
  .catch(console.error);

🧘 `Promise.allSettled([...])`

Waits for all to settle (resolve or reject) and returns results for each.

Promise.allSettled([p1, p2, p3]).then(console.log);

🏁 `Promise.race([...])`

Returns the first settled (resolve or reject) promise.

Promise.race([p1, p2]).then(console.log).catch(console.error);

🥇 `Promise.any([...])`

Returns the first fulfilled promise. Ignores rejections unless all fail.

Promise.any([p1, p2]).then(console.log).catch(console.error);

🧩 Final Thoughts

Callbacks introduced async flow.
Promises simplified it.
Promise combinators (all, allSettled, race, any) give us flexible control over multiple tasks.
Use async/await for cleaner, more readable code.

From Imposter Syndrome to Progress: A Developer's Mental Journey

rashidpbi — Thu, 31 Jul 2025 05:43:29 +0000

In my experience so far, almost every developer goes through imposter syndrome—except a rare few.

I've seen many talented people quit, believing they "may not be able to make it."

But here's the truth:

💡 Things start making sense only after periods of consistent effort.

The journey is often frustrating but rewarding along the way (and honestly, there's no real "end point" to learning in this field 🙂). I've been there too—moments of self-doubt, overthinking, and negative spirals.

Strategies That Helped Me (and Might Help You Too)

🔹 1. Take a Short Break

Sometimes stepping away is the best move. Go for a walk. Clear your mind. Often, solutions "click" when you're no longer stuck in the same thought loop.

🔹 2. Redefine Your Goal

Instead of saying, "I must solve this now," change your goal to:

"I'll spend 10 more minutes exploring this."

Draw a line for every 10 minutes spent or for every small bit of progress made. ✅ Micro-wins add up and build momentum.

🔹 3. Look Back to Move Forward

Remind yourself how far you've already come. If you've overcome past hurdles, you can overcome this one too.

🔹 4. Switch Context

Solve a different problem for a while. A small win elsewhere can recharge your motivation and perspective.

💭 Final Words

If you're feeling stuck or doubting yourself—know this: You're not alone. Most developers have been there.

What matters is staying consistent, patient, and kind to yourself during the journey.

👉 Keep going. Things will click. They always do.

🚀 A Practical Guide to TypeScript in Next.js (For Real-World Devs)

rashidpbi — Tue, 29 Jul 2025 15:06:10 +0000

I recently dove deep into integrating TypeScript with a Next.js project, and while the official docs are helpful, I wanted to consolidate my understanding in a way that actually clicks — for myself and for anyone else walking the same path. This post captures everything I wish I'd known earlier: not just the how, but also the why behind TypeScript's behavior in a Next.js setup.

🔧 Setting Up TypeScript in a Next.js Project

If you're starting from scratch, here's how to set up TypeScript with a Next.js app:

1. Create a Next.js Project

npx create-next-app@latest my-next-app
cd my-next-app

2. Install TypeScript and Type Definitions

pnpm add -D typescript @types/react @types/node
# or
npm install -D typescript @types/react @types/node

3. Run the Dev Server

When you run pnpm dev or npm run dev, Next.js detects TypeScript and automatically generates a basic tsconfig.json for you. You don't need to configure compilation separately — Next.js handles that under the hood.

🤖 So… What Does TypeScript Actually Do?

TypeScript brings static typing to JavaScript. Think of it as a spell checker for your logic. It catches errors like these:

let age: number = "25"; // ❌ Error: Type 'string' is not assignable to type 'number'

This kind of feedback before running your app is what makes TS shine — especially as your codebase grows.

🧠 End Goal of Using TypeScript?

After proper integration, your TypeScript setup should:

✅ Catch bugs before runtime

✅ Improve code readability and maintainability

✅ Boost IDE features like autocomplete and refactoring

✅ Make large projects safer to work on (hello, refactors!)

And the best part? You don't need to run any special build command for TS in Next.js. The framework handles compilation transparently.

🔄 Does TypeScript Compilation Actually Happen?

Yes, but you rarely see it directly.

In dev mode (pnpm dev), TypeScript is compiled on the fly.
In production builds (pnpm build), Next.js compiles everything to pure JavaScript inside the .next/ directory.

So ultimately, browsers only see JavaScript. TypeScript helps us during development and build time.

❓ Do You Need to Manually Compile .ts Files?

Nope. Not in Next.js.

If you're curious, you can compile TS with tsc manually in plain TypeScript projects, but with Next.js, it's all baked in.

🧩 Type Errors & Editor Support

Does TS stop you from assigning wrong types?

Yes, and that's its superpower.

function greet(name: string) {
  return "Hello, " + name;
}

greet(42); // ❌ Error: Argument of type 'number' is not assignable to type 'string'

Does this error handling come from a VS Code extension?

No. VS Code has built-in TypeScript support — you get error squiggles, IntelliSense, and quick fixes out of the box. Extensions like ESLint or Prettier can enhance it, but aren't necessary to use TypeScript.

🧾 What Is tsconfig.json and Do You Need It?

The tsconfig.json file is TypeScript's configuration brain. While VS Code can run without it, having one:

📁 Controls which files to include/exclude

🔐 Enables strict type checking

✨ Supports path aliases (e.g. @/components)

Example config:

{
  "compilerOptions": {
    "strict": true,
    "jsx": "preserve",
    "moduleResolution": "node",
    "baseUrl": ".",
    "paths": {
      "@/*": ["src/*"]
    },
    "noEmit": true
  },
  "include": ["next-env.d.ts", "**/*.ts", "**/*.tsx"],
  "exclude": ["node_modules"]
}

📄 What Are Type Declaration Files (.d.ts)?

A Type Declaration File is like telling TypeScript:

"Hey, this function/variable exists — trust me — and here's what its type looks like."

Use case:

You're working with a global JavaScript library that's not typed.

Example:

// global library: myLib.js
myLib.makeGreeting("hello");

Instead of TS screaming at you, you declare its shape:

// global.d.ts
declare namespace myLib {
  function makeGreeting(s: string): string;
  let numberOfGreetings: number;
}

Now TypeScript understands how to treat myLib.

Bonus: Overloaded Functions

TS can also handle functions that behave differently based on input:

declare function getWidget(n: number): Widget;
declare function getWidget(s: string): Widget[];

So getWidget(1) returns one widget, and getWidget("all") returns an array.

✅ Final Words

TypeScript isn't about writing more code — it's about writing safer code. In a modern stack like Next.js, it integrates seamlessly, improves DX (Developer Experience), and saves you from a ton of head-scratching bugs down the line.

If you're still unsure whether to go all-in with TS, try enabling it in just one file — you might not go back.

🔀 Maintaining a Linear Commit History in Git

rashidpbi — Sat, 26 Jul 2025 17:58:10 +0000

While working with Git branches like develop and main, it's common to frequently merge changes. But did you know that doing so with regular merges can break a linear commit history?

Here's what I learned today 👇

💡 Problem

If you keep merging from develop to main using regular git merge, Git will create merge commits, leading to a non-linear (branched) commit history.

This can make git log harder to read, especially in large projects.

✅ How to Maintain a Linear History

To ensure a clean, straight commit history on main, use one of these strategies:

1. Rebase Before Merge

git checkout develop
git rebase main # Replay develop commits on top of main
git checkout main
git merge --ff-only develop # Fast-forward only

✅ This avoids merge commits and keeps the history linear.

2. Use Squash Merging (Optional)

If you want to combine all develop changes into a single commit before merging:

git checkout main
git merge --squash develop
git commit

🎯 Useful for condensing work into one clean commit.

3. Use Fast-Forward Merges Only

Prevent accidental merge commits:

git merge --ff-only develop

📌 Final Tip

🔁 Repeat this pattern consistently to keep main clean and linear — great for production branches and readable history.

Tags: #git #github #versioncontrol #devtips #100DaysOfDev

🔄 React Lifecycle, useEffect, and What’s Really Happening in Next.js

rashidpbi — Fri, 25 Jul 2025 16:13:45 +0000

When I started learning React and Next.js, I wanted to understand not just how to use hooks like useEffect, but what's really happening under the hood. Here's a beginner-friendly breakdown of what I learned — and how it ties together with core JavaScript concepts.

🧩 Understanding `useEffect` with React Lifecycle

React components go through three main phases:

Mounting – inserted into the DOM
Updating – re-render due to props/state change
Unmounting – removed from the DOM

In functional components, useEffect acts as a replacement for old class lifecycle methods like componentDidMount, componentDidUpdate, and componentWillUnmount.

useEffect(() => {
  // runs once on mount
  return () => {
    // cleanup before unmount
  };
}, []);

✅ Common patterns

Purpose	useEffect usage
Run once on mount	`useEffect(() => {...}, [])`
Run on update	`useEffect(() => {...}, [deps])`
Cleanup	`return () => {...}` inside useEffect

Think of useEffect as a way to handle side effects (like API calls, subscriptions) after the DOM is updated.

⚠️ Can I Use useState Inside useEffect?

No — calling useState() inside useEffect() violates the Rules of Hooks.

❌ Invalid

useEffect(() => {
  const [count, setCount] = useState(0); // ❌ Not allowed
}, []);

✅ Valid

const [count, setCount] = useState(0);
useEffect(() => {
  setCount(5); // ✅ Allowed
}, []);

🔍 JavaScript Concepts Behind Next.js

Next.js is a powerful React framework, but it's built on top of vanilla JavaScript and Node.js. Here are the core JS concepts powering it:

Concept	Why It Matters
import/export	Modular code structure
async/await & Promises	Data fetching & API routes
Closures	Powering hooks and handlers
Array methods (map, filter)	Rendering lists
Spread/Rest & Destructuring	Cleaner state updates
File system APIs	Routing and API creation
Environment variables	App config (.env.local)
Node.js concepts	Server-side logic in API routes

The more you understand JavaScript fundamentals, the easier Next.js becomes.

🧠 Final Thoughts

Learning React and Next.js by diving into the underlying JS helped me gain real clarity. Instead of memorizing patterns, I now understand why things work — and when to use them.

If you're a beginner, my tip: spend time understanding hooks, lifecycle, and JS concepts like promises, closures, and modules. It pays off quickly 🚀

🤯 Understanding Google OAuth2 Token Refresh in Node.js (with googleapis)

rashidpbi — Thu, 24 Jul 2025 18:22:16 +0000

When integrating Google OAuth2 in your Node.js / Next.js app using the googleapis library, a key question is:

🧠 "How do I handle access token expiration and refresh automatically?"

Turns out — you don't need to handle much at all. But understanding why and how took me down a rabbit hole. Here's what I learned so you don't get stuck like I did.

🔑 The Basics

When you authorize a user via the OAuth2 web server flow (access_type: "offline"), Google returns:

access_token – short-lived, used for API requests
refresh_token – used to get a new access token
expiry_date – timestamp (in ms) when the access token expires

✅ The Simple Solution

The good news? You can make Google auto-refresh tokens just by doing this:

oauth2Client.setCredentials({
  access_token,
  refresh_token,
  expiry_date,
});

Then, call the API like normal:

const calendar = google.calendar({ version: "v3", auth: oauth2Client });
await calendar.events.delete({
  calendarId: "primary",
  eventId: "123",
});

If the access_token is expired, the client automatically refreshes it using the refresh_token.

🎉 No need to manually check expiry or refresh!

🤔 Then Why Do People Use getAccessToken()?

Great question!

Use getAccessToken() only when you need the raw token string, such as:

Adding it to custom headers
Injecting into a GraphQL/WebSocket context
Logging / debugging

const { token } = await oauth2Client.getAccessToken();

Otherwise, skip it. Google handles everything internally during requests.

🧪 How I Tested the Refresh Behavior

Want to test token refresh manually without waiting for expiration?

Just fake the expiry like this:

oauth2Client.setCredentials({
  access_token,
  refresh_token,
  expiry_date: Date.now() - 1000, // fake it as expired
});

Then make a normal API call — it will refresh in the background.

👀 Bonus: Log When Token Refresh Happens

You can log when a refresh happens using the tokens event:

oauth2Client.on("tokens", (tokens) => {
  console.log("🔄 Refreshed tokens:", tokens);
});

Perfect for debugging or confirming it's working.

🧠 Lessons Learned

The docs are technically right, but don't show everything clearly
The googleapis package uses google-auth-library internally, which handles refresh logic
Set a past expiry_date + make a request = auto-refresh
Use getAccessToken() only when you need the token string
You don't need to memorize class hierarchies — but checking inheritance (like OAuth2Client → AuthClient) helps

🏁 Final Tip

If you're ever unsure about how a client like OAuth2Client behaves:

Look for event hooks (like tokens)
Check method docs (getAccessToken, request)
Look at class inheritance
Test locally with fake expiry