Forem: Devarshi Shimpi

Voice Search in Chrome Extensions Is Harder Than It Looks

Devarshi Shimpi — Mon, 16 Mar 2026 15:57:17 +0000

I thought this was just an hour of work. It wasn't. Here's everything that went wrong and what actually worked in the end.

Starting with the obvious choice

window.SpeechRecognition is built into Chrome. No API keys, no server, completely free. It felt like the perfect starting point for adding voice search to my extension.
After a day of testing, I dropped it.
The mic permission popup was all over the place. Sometimes it would show up randomly mid-session. Sometimes it would just stop listening with no error, no warning, nothing. Results were different depending on the machine and OS. For a new tab extension that's meant to feel polished, that just wasn't good enough.
I switched to Deepgram's Nova-3 model. It's fast, accurate, and sends results back in real time over WebSocket, so you don't have to wait for a full sentence before seeing any output.
But now I needed a server, which kicked off a whole chain of problems.

Why you can't call Deepgram directly from the extension

Chrome extensions are easy to unpack and read. Any secret you put in the code is basically public. So keeping a Deepgram API key in the client was never going to work.
I needed a server in the middle. My first thought was Railway. I've used it before and getting a Node server running there takes maybe five minutes. But I second guessed that pretty quickly. A server on Railway means it has to start up cold sometimes, it costs money every month, and the speed depends on where the server is located. Cloudflare Workers runs closer to the user since it runs at the edge, and the free plan is generous enough that a voice search API would run for free forever. Easy choice.
The setup I had in mind: the extension sends raw audio to the Worker, the Worker passes it to Deepgram, and the text comes back the same way.

Simple enough on paper. Actually building it was another story.

Hono looked like the right tool. It wasn't.

I use Hono for pretty much everything on Cloudflare Workers. Clean, fast, easy routing. So I reached for it without thinking twice.
Set up a /transcribe route, handled the WebSocket upgrade, deployed it. The Worker just froze. No error from my code, just Cloudflare eventually killing the request with a 500 and a message saying the Worker "would never generate a response."
Took me a while to figure out what was going on. Cloudflare needs a special webSocket property on the Response object to finish a WebSocket connection. That's how it knows which socket to hand back to the client.
Hono wraps the built-in Response to add its own features. Somewhere in that process, the webSocket property gets lost. Cloudflare gets a response with no socket, doesn't know what to do, and kills the request.
The fix was to skip Hono for this route and just write it raw:

export default {
  async fetch(request, env) {
    if (url.pathname === "/transcribe") {
      const pair = new WebSocketPair();
      const [client, server] = pair;
      server.accept();
      return new Response(null, { status: 101, webSocket: client });
    }
  },
};

101 Switching Protocols. Finally.

The timing bug I should've seen coming

Audio was flowing but the Worker kept logging Deepgram not ready. Pretty obvious in hindsight.
The moment the client gets a 101 back, it starts sending audio right away. But the Worker had only just started its own connection to Deepgram. That connection wasn't open yet. So audio was showing up before Deepgram was ready to take it.
My first fix was to wait for the Deepgram connection to open before sending the 101 back:

await new Promise((resolve) => {
  deepgramSocket.onopen = resolve;
});
return new Response(null, { status: 101, webSocket: client });

This worked. But it quietly created a new problem I didn't notice until later.

Cloudflare's 10ms CPU limit is real

The free plan on Cloudflare Workers gives you 10ms of CPU time per request. Not total time, just active processing time. Waiting on a network call doesn't count, so in theory waiting for Deepgram to connect should be fine.
In practice, keeping the request open through the whole connection process added enough overhead that CPU usage was sitting at 40 to 90ms. Cloudflare was going to start dropping requests.

The fix was to stop waiting. Return the 101 right away, let Deepgram connect in the background, and just hold any audio that comes in too early:

let deepgramReady = false;
const pendingChunks = [];

deepgramSocket.addEventListener("open", () => {
  deepgramReady = true;
  for (const chunk of pendingChunks) deepgramSocket.send(chunk);
  pendingChunks.length = 0;
});

server.addEventListener("message", (event) => {
  if (!deepgramReady) {
    pendingChunks.push(event.data);
  } else {
    deepgramSocket.send(event.data);
  }
});

return new Response(null, { status: 101, webSocket: client });

CPU usage dropped to around 2ms. Deepgram still connects, it just doesn't hold everything else up while it does.

AudioWorklet and Manifest V3 don't work together

This was the most painful part of the whole thing.
MV3 extensions only let you run scripts that are part of your own extension package. No inline scripts, no scripts from other websites, nothing generated at runtime. AudioWorkletNode is the standard modern way to process audio in a background thread, and it needs you to load a separate file using addModule(url). You can already see where this is going.

First try was using Vite's ?url import:

import processorUrl from "./processor.js?url";
// Output: data:text/javascript;base64,...

Blocked. Makes sense, data URIs aren't allowed.
Second try was putting the file in the public/ folder and loading it with chrome.runtime.getURL:

const url = chrome.runtime.getURL("audio/pcm-processor.js");
await ctx.audioWorklet.addModule(url);

This really should have worked. A chrome-extension:// URL is from your own extension, so the policy should allow it. I was pretty sure this was the answer.
It failed with AbortError: Unable to load worklet module. No extra info, no useful error message.
After going through Chromium bug reports, turns out this is a known broken behaviour in how Chrome handles extension files in Worklet threads. There are open issues, no fix in sight.

The old deprecated API that actually works

I gave up on AudioWorklet and used ScriptProcessorNode instead. It's been marked as deprecated for years but it runs directly in the page using a callback, so there's no extra file to load and no policy issues. For converting Float32 audio to Int16, the performance hit is basically nothing.

const processor = audioCtx.createScriptProcessor(4096, 1, 1);
processor.onaudioprocess = (e) => {
  const input = e.inputBuffer.getChannelData(0);
  const int16 = float32ToInt16(input);
  ws.send(int16);
};

Works every time without fail. The modern recommended way broke. The old way just works. That's extension development.

A few smaller things worth knowing

Cleaning up properly is harder than it sounds. Web Audio can leak memory if you don't clean up after yourself. When voice search stops, you need to close the WebSocket, disconnect the ScriptProcessor, stop all microphone tracks (this turns off the mic light in the browser toolbar), and close the AudioContext. Skip any one of these and you'll have audio processes running in the background that you can't see.
Silence detection matters a lot. Without it, the mic just stays on forever. Every time Deepgram sends back a transcript or a speech_started event, reset a 2.5 second timer. When the timer runs out, stop listening. It makes the whole thing feel much less annoying to use.
Add the Worker URL to host_permissions in your manifest. You need to allow wss://your-worker.workers.dev/* or the browser blocks the connection before it even gets to any policy check.

What actually changed

Before all of this, the extension was using window.SpeechRecognition with around 500ms before it even started listening, results that changed between machines, and random failures. After the rewrite, it connects in around 100ms, the Worker uses 1 to 3ms of CPU per request, and it works the same way every time.
Every single problem in this build came from the same place: the standard tools weren't built for this environment. Hono breaks WebSockets on Cloudflare. AudioWorklet breaks in MV3 extensions. Once you understand why something fails, the fix is usually obvious. The hard part is getting there.

Happy Coding!!!

Thank you for reading! If you found this blog post helpful, please consider sharing it with others who might benefit. Feel free to check out my other blog posts and visit my socials!

React (RSC) Exploits Are Real and It's Hurting Engineering Teams

Devarshi Shimpi — Thu, 08 Jan 2026 16:11:01 +0000

If you work in web engineering, the transition into 2026 hasn’t been defined by new features, but by a single, terrifying realization: The boundary between your client and server is broken.

In December, "React2Shell" (CVE-2025-55182) exposed a critical RCE in React Server Components. Barely after teams patched, two more high-severity exploits emerged in the same subsystem. This is the definitive technical post-mortem.

The "React2Shell" RCE (CVE-2025-55182)

To understand why this vulnerability (CVSS 10.0) was so devastating, we first have to understand the machinery it destroyed, the React Flight Protocol.

For years, the mental model for React developers was simple: React renders UI in the browser, and an API (REST/GraphQL) fetches data. The server and client were distinct worlds, separated by a clear network boundary.

React Server Components (RSC) erased that boundary.

In the RSC world, the server doesn't send HTML to the client. It streams a proprietary serialization format called "Flight." This stream contains descriptions of UI components, serialized data, and crucially Promises that resolve to data.

How React2Shell Works

React2Shell was not standard SQL injection or XSS. It was logic abuse targeting a deserializer. Attackers crafted HTTP POST requests with specific "Flight" payloads. These binary-like streams mimicked valid component trees while hiding a "Thenable" Object, or fake Promise.

Injection: Attacker sends serialized object containing malicious __proto__ keys.
Deserialization: Server parses stream and tries resolving fake Promise.
Prototype Pollution: Lack of sanitization lets __proto__ overwrite Object.prototype on running Node.js process.
Gadget Chain: Modified prototype triggers internal calls targeting Function constructor.

Accessing Function constructor means game over. Arbitrary strings like require('child_process').exec(...) compile and execute immediately.

How Next.js was Affected

Because Next.js App Router enables RSC by default, every Next.js application (versions 15.x, 16.x, and canary builds) was vulnerable out of the box. You didn't need to write a buggy Server Action to be hacked. You didn't even need to use Server Components explicitly. If your application booted up react-server-dom-webpack, it was listening for these Flight payloads.

Credits: Next.js for the image

The DevOps Nightmare

For DevOps engineers, "React2Shell" was a worst-case scenario.

WAF Blindness: Standard Web Application Firewalls (WAFs) are trained to look for SQL injection (' OR 1=1) or script tags (<script>). They were not trained to inspect the proprietary text format of React Flight. The malicious payloads passed right through Cloudflare and AWS WAF rules initially.
Supply Chain Hell: The vulnerability wasn't in user code; it was deep in node_modules. You couldn't just "fix the code." You had to wait for Vercel and the React team to release patched binaries, then rebuild and redeploy every single microservice.

The Aftershocks (DoS and Leaks)

Just as engineering teams were recovering from the RCE panic, the security community found more cracks in the foundation. On December 11, 2025, the React team issued a new advisory for three additional CVEs.

While these aren't RCEs, they are operationally devastating and highlight the fragility of the current serialization implementation.

1. Denial of Service (CVE-2025-55184)

Severity: High (7.5/10)

This vulnerability allows attackers to "freeze" infrastructure with a single request.

Mechanism:
Flight protocol allows data chunks to reference other chunks. Researchers discovered they could create circular dependencies in payloads.

Chunk A references Chunk B.
Chunk B references Chunk A.

When the React deserializer attempts to resolve this structure, it enters an infinite synchronous loop.

The Impact on Infrastructure:
Because Node.js is single-threaded, this infinite loop blocks the entire Event Loop.

CPU Spike: The CPU immediately jumps to 100%.
Request Drops: The server stops responding to all other users. Health checks fail.
Cluster Destabilization: In Kubernetes, the liveness probe might fail, causing the pod to restart. But if the attacker sends a stream of these requests, they can put the entire cluster into a "CrashLoopBackOff" state, effectively taking down the application.

Note: The initial fix for this was incomplete, leading to CVE-2025-67779 (the "fix for the fix"), which forced DevOps teams to patch their systems a third time in two weeks.

2. Source Code Leak (CVE-2025-55183)

Severity: Medium (5.3/10)

Arguably most embarrassing vulnerability for React ecosystem. It allows attackers to trick servers into sending source code back to clients.

Mechanism:
Exploit relies on JavaScript string coercion. If Server Action returns object implicitly calling .toString() on a function within server runtime, default V8 behavior returns function source code.

"Secrets" Risk:
Developers often assume code inside use server files is private. They might write:

// DO NOT DO THIS
const STRIPE_KEY = "sk_live_12345"; 
export async function purchase() { ... }

Under normal circumstances, STRIPE_KEY stays on the server. But with CVE-2025-55183, an attacker can manipulate the serialization of the return value to dump the scope of the function, potentially revealing hardcoded API keys, internal comments, and database schema details.

Immediate Action Plan

If you are running Next.js App Router (v13.3+) or React 19, you must execute the following plan immediately:

The "Immediate" Update: Do not trust semantic versioning ranges. Pin your versions to the releases that explicitly fix all discussed CVEs.

npm install react@19.0.2 react-dom@19.0.2 next@15.1.3
# Verify deeply nested dependencies
npm list react-server-dom-webpack

Ensure react-server-dom-webpack is at least version 19.0.2.

Implement Rate Limiting:
The DoS exploit is cheap for attackers. You must implement aggressive rate limiting on all routes, especially POST requests, at the infrastructure level (Nginx, Cloudflare, AWS WAF).
Audit for Secrets:
Assume your server code can be leaked. Run a scan of your app/ directory. If you find a single API key, hardcoded password, or internal IP address in a .ts or .js file, move it to an environment variable immediately.

Conclusion

React Server Components are a powerful evolution of the web, but "React2Shell" has proven that this power comes with a terrifying new attack surface. The Flight protocol is complex, and as we have seen, complexity is the enemy of security.

Thank you for reading! If you found this blog post helpful, please consider sharing it with others who might benefit. Feel free to check out my other blog posts and visit my socials!

Dynamic Styling with calc() in TailwindCSS

Devarshi Shimpi — Tue, 14 Oct 2025 22:01:56 +0000

Introduction

TailwindCSS is fantastic, right? It lets us build beautiful, custom designs incredibly fast with its utility-first approach. We grab classes like p-4, flex, w-1/2, and boom – things start taking shape. But sometimes... sometimes you hit a wall. You need a layout element to be exactly 100% wide, minus the fixed width of a sidebar. Or maybe you want padding that dynamically adjusts based on the viewport plus a base value.

In this deep dive, we'll explore how calc() works, why it's such a powerful partner for Tailwind, and how you can leverage it to build more sophisticated, responsive, and pixel-perfect interfaces without ever leaving your HTML (mostly!).

First Things First: What Exactly is `calc()`?

Before we plug it into Tailwind, let's quickly refresh ourselves on what calc() actually does in plain old CSS. At its core, calc() is a native CSS function that lets you perform calculations right inside your property values. Think of it like a mini-calculator for your stylesheets.

It supports the basic arithmetic operations you'd expect:

Addition (+): calc(2rem + 10px)
Subtraction (-): calc(100% - 50px)
Multiplication (*): calc(1.5 * 1rem)
Division (/): calc(100vw / 3)

This ability to blend relative and absolute units is something static values just can't replicate easily.

/* Full width minus a fixed sidebar */
.main-content {
  width: calc(100% - 250px);
}

/* Dynamic padding based on viewport height */
.hero-section {
  padding-top: calc(5vh + 2rem);
}

Why Bring `calc()` into the Tailwind World?

"Okay," you might be thinking, "Tailwind has spacing, sizing, fractions... why complicate things?"

That's a fair question! Tailwind covers a huge range of common styling needs with its utilities. But calc() fills the gaps where:

You Need Mixed Units: Tailwind's w-1/2 is 50%, w-64 is 16rem. But what about calc(50% - 1rem)? Tailwind doesn't have a pre-built utility for every possible mathematical combination.
You Need Precise Dynamic Relationships: Calculating an element's size based on the viewport minus a fixed header/footer height is a prime use case.
You Want Fluidity Beyond Standard Fractions: Maybe a three-column layout needs precise gutters subtracted from fractional widths.
You're Dealing with External Constraints: Sometimes, an element's size needs to account for something outside its direct parent (like the viewport height).

Using Arbitrary Values `[]` with `calc()`

The framework embraced the idea that sometimes, you just need to write a specific CSS value directly. This is done using square brackets []. And guess what? You can put a calc() expression right inside!

The syntax looks like this:

<div class="property-[calc(expression)]">...</div>

Let's see it in action:

Creating a width that's full-width minus some padding:

<div class="w-[calc(100%-2rem)] bg-blue-100 p-4">
  My width adapts, always leaving 1rem of space on each side (total 2rem).
</div>

Setting a height relative to the viewport minus a header:

<header class="h-16 bg-gray-800 text-white">...</header> <main class="h-[calc(100vh-4rem)] bg-gray-100 overflow-y-auto">
  This content area fills the remaining vertical space perfectly.
</main>

Applying dynamic margins or padding:

<div class="mt-[calc(2rem+5vh)] bg-green-100 p-3">
  My top margin grows slightly as the viewport height increases.
</div>

It's that straightforward! You use the Tailwind property prefix (w-, h-, mt-, p-, etc.) followed by your calc() expression wrapped in square brackets.

Let's Get Practical: Real-World `calc()` Scenarios in Tailwind

Theory is nice, but let's see where calc() truly shines in everyday development with Tailwind.

Example 1: The Classic Sidebar + Content Layout

This is a bread-and-butter layout. You have a fixed-width sidebar and want the main content area to take up the rest of the available space.

<div class="flex min-h-screen">
  <aside class="w-64 bg-gray-100 p-4 flex-shrink-0"> Sidebar Content
  </aside>

  <main class="w-[calc(100%-16rem)] bg-white p-6 flex-grow">
    Main Application Content Here...
    It perfectly fills the space next to the sidebar.
  </main>
</div>

Here, w-[calc(100%-16rem)] explicitly tells the main content area to calculate its width based on the full container width minus the sidebar's known width. flex-shrink-0 on the sidebar prevents it from shrinking if space gets tight, and flex-grow on main allows it to expand (though the calc() width often makes this redundant, it's good practice in flex layouts).

Example 2: Making Room for Fixed Headers/Footers

Sticky headers are common, but they can overlap content or require awkward padding. calc() makes managing the space elegant.

<body class="flex flex-col min-h-screen">
  <header class="h-16 bg-indigo-600 text-white p-4 sticky top-0 z-10"> Fixed Header
  </header>

  <main class="flex-grow p-6 bg-gray-50" style="padding-top: calc(4rem + 1.5rem);">
    Content Section
  </main>

  <section class="h-[calc(100vh-4rem)] bg-gray-100 p-6 overflow-y-auto">
     This section takes exactly the remaining viewport height below the header.
  </section>

  <footer class="h-12 bg-gray-700 text-white p-3 mt-auto"> Footer
  </footer>
</body>

In the section example, h-[calc(100vh-4rem)] ensures that specific part of the page uses precisely the vertical space available below the 4rem header. No guesswork needed.

Example 3: Fluid Typography That Breathes

Want your text headings to scale smoothly with the viewport width, not just jump between breakpoints? calc() combined with viewport units (vw) is your friend.

<h1 class="text-[calc(1.5rem+2vw)] font-bold text-gray-900 leading-tight">
  This Headline Scales Fluidly
</h1>
<p class="text-[calc(1rem+0.5vw)] text-gray-700">
  Even paragraph text can subtly adapt to the screen size, improving readability across devices.
</p>

Here, the font size has a base value (1.5rem or 1rem) and adds a small percentage of the viewport width (2vw or 0.5vw). This creates a much smoother scaling effect than relying solely on text-lg, text-xl, etc., at different breakpoints.

Example 4: Precise Centering and Positioning

Sometimes flex or grid centering isn't quite right, especially for absolutely positioned elements or overlays where you need an offset.

<div class="relative h-screen bg-gray-200">
  <div class="absolute top-[calc(50%-50px)] left-[50%] -translate-x-1/2 -translate-y-1/2 bg-white p-8 rounded shadow-lg">
    I'm centered horizontally, but slightly offset vertically!
  </div>
</div>

Here, top-[calc(50%-50px)] positions the element's top edge 50 pixels above the halfway point of the container, while the transform utilities handle the rest of the centering adjustment based on the element's own size.

Going Beyond Arbitrary Values: Custom `calc()` Utilities

Arbitrary values are fantastic for one-offs. But what if you find yourself repeatedly using the same calc() expression? Like that h-[calc(100vh-4rem)] for content below your standard header? Typing that out every time is tedious and error-prone.

This is where extending your Tailwind configuration shines. You can define your own custom utilities that encapsulate these common calculations.

Add this to your tailwind.config.ts:

import type { Config } from 'tailwindcss';

const config: Config = {
  theme: {
    extend: {
      // Example: Add custom height calculation
      height: {
        'screen-minus-header': 'calc(100vh - 4rem)', // Assuming 4rem header
      },
      // Example: Add custom width calculation
      width: {
        'content-area': 'calc(100% - 16rem)', // Assuming 16rem sidebar
      },
      // Example: Add custom spacing
      spacing: {
        'dynamic-gutter': 'calc(1rem + 2vw)',
      }
    }
  },
  plugins: [],
  content: [
    // Ensure your content paths are configured here
    './src/**/*.{html,js,jsx,ts,tsx,vue}',
  ]
};

export default config;

Now, you can use these just like native Tailwind utilities:

<main class="h-screen-minus-header w-content-area p-dynamic-gutter">
  Look Ma, custom calc utilities!
</main>

This makes your HTML cleaner, your calculations consistent, and your design system more robust.

Conclusion

TailwindCSS provides an incredible foundation for rapid UI development. By understanding and integrating the native CSS calc() function through arbitrary values and custom configurations, you unlock a whole new level of dynamic control and precision.

Thank you for reading! If you found this blog post helpful, please consider sharing it with others who might benefit. Feel free to check out my other blog posts and visit my socials!

Introduction to Next.js 15: What's New and the improvements!

Devarshi Shimpi — Tue, 17 Dec 2024 05:30:00 +0000

Introduction

Next.js 15 has introduced a range of exciting features and improvements that enhance both performance and developer experience. Here’s a detailed overview of what's new!

Seamless Upgrades with @next/codemod CLI

The enhanced codemod CLI simplifies upgrading to the latest Next.js and React versions. It automates code transformations, ensuring a smooth transition to new APIs and features.

npx @next/codemod@canary upgrade latest

Performance Enhancements

Next.js 15 focuses heavily on improving the speed and efficiency of applications:

Turbopack Boost: Next.js 15's integration with Turbopack accelerates development server startup by up to 53%, providing faster feedback loops.
Hybrid Rendering: Partial prerendering combines static and dynamic content for quicker initial loads and improved user experience.
Enhanced Caching: Optimized caching strategies reduce network requests, resulting in faster load times and predictable data fetching.

Developer Experience (DX) Improvements

Next.js 15 prioritizes the developer experience with several new tools and features:

Asynchronous Request-Specific APIs: APIs for handling cookies, headers, and search parameters have been updated to support asynchronous operations. This change allows for cleaner code and enhances application responsiveness.

New Debugging Tools: Enhanced error messages and stack traces make debugging more efficient, helping developers quickly identify and resolve issues.
New Form Component: A built-in form component simplifies form handling by eliminating the need for third-party libraries. It supports automatic validation, and progressive enhancement, ensuring that forms work even without JavaScript enabled.

import Form from 'next/form';

export default function Page() {
  return (
    <Form action="/search">
      <input name="query" />
      <button type="submit">Submit</button>
    </Form>
  );
}

Experimental Authorization APIs: New APIs for handling authorization errors (forbidden and unauthorized) provide granular control over authentication processes.
TypeScript Configuration Support: Developers can now use TypeScript for their configuration files by renaming next.config.js to next.config.ts. This feature improves type safety and autocompletion, reducing errors during development.

import type { NextConfig } from 'next';

const nextConfig: NextConfig = {
  /* config options here */
};

export default nextConfig;

Static Route Indicator

Next.js now displays a Static Route Indicator during development to help you identify which routes are static or dynamic. This visual cue makes it easier to optimize performance by understanding how your pages are rendered.

New Middleware Capabilities

A standout feature in Next.js 15 is the introduction of middleware, which allows developers to run code before requests are completed. This is particularly useful for tasks such as authentication and logging.

Support for React 19 and ESLint 9

Next.js 15 officially supports React 19, which introduces several performance optimizations and new features including the new React Compiler.

It also adds support for ESLint 9 while maintaining backward compatibility with ESLint 8. This ensures better code quality through improved linting capabilities tailored for React hooks usage.

Conclusion

Next.js 15 represents a significant advancement in web development capabilities with its blend of performance enhancements, improved developer tools, and robust support for modern React features.

Thank you for reading! If you found this blog post helpful, please consider sharing it with others who might benefit. Feel free to check out my other blog posts and visit my socials!

Managing Dependencies and Security in JavaScript with NPM

Devarshi Shimpi — Fri, 09 Aug 2024 13:13:19 +0000

Introduction

The JavaScript ecosystem, particularly with NPM, is both a boon and a bane for developers. On one hand, it provides an incredibly vast library of modules that can accelerate development. On the other hand, it can feel like a tangled web of dependencies, raising legitimate security concerns. Let's dive deep into the intricacies of NPM, the security implications, and how modern bundlers mitigate these risks.

Understanding NPM and Its Ecosystem

NPM is the default package manager for Node.js, which is widely used for server-side and full-stack JavaScript development. It allows developers to easily install, share, and manage code modules.

The convenience it offers has made it a cornerstone of modern JavaScript development. However, with great convenience comes great responsibility.

The Dependency Hell

When you set up a basic project with NPM, you often find yourself pulling in numerous dependencies. Each dependency can have its own dependencies, creating a cascading effect that can quickly spiral out of control. This phenomenon is often referred to as dependency hell.

Consider this scenario: You install a popular library like TailwindCSS. TailwindCSS itself has a few dependencies.

Those dependencies, in turn, have their own dependencies, and so on. Before you know it, your project has hundreds of packages installed, many of which you may not be familiar with. This can make your project more vulnerable to security risks, as it’s challenging to vet each package and its updates.

The Security Concerns

One of the primary security concerns with NPM is the potential for malicious code to be introduced into your project through dependencies. This can happen in a few ways:

Compromised Packages: A legitimate package you depend on might get compromised. This can happen if a maintainer's account is hacked or if the maintainer themselves goes rogue.
Typosquatting: Malicious actors sometimes publish packages with names similar to popular packages, hoping that developers will mistype the name and inadvertently install the malicious package.
Dependency Chains: Even if your direct dependencies are secure, they might depend on other packages that are not. This creates a long chain of trust that can be difficult to manage.

The Polyfill.io Incident

Link to the article here

A recent incident involving a service called Polyfill.io highlighted these risks. Polyfill.io is a CDN service that provides JavaScript polyfills for older browsers. It was discovered that this service could potentially serve different versions of the same script based on the browser's user agent. This variability made it impossible to use integrity checks to verify the script, creating a security vulnerability.

Many websites, including high-profile ones like Hulu, were loading scripts from this service. This incident underscores the dangers of relying on third-party CDNs for critical scripts, as a compromise in the CDN can lead to widespread vulnerabilities.

So, Are We Trading Security for Convenience?

Yes, managing dependencies in a large software project is inherently complex, and no system is foolproof. However, modern package managers, bundlers, and security best practices provide robust safeguards against most common attack vectors.

The key takeaway is this: understand how your tools work. Don't blindly trust; verify. Pin your dependency versions, audit your dependencies regularly, and stay informed about potential vulnerabilities. By adopting a proactive security mindset and leveraging the tools at your disposal, you can reap the benefits of a vibrant package ecosystem without compromising the integrity of your code.

Modern Bundlers to the Rescue

Fortunately, modern JavaScript development has tools to mitigate these risks. Bundlers like Webpack, Vite, and Rollup play a crucial role in ensuring the security and efficiency of web applications.

What is a Bundler?

A bundler takes the various modules and dependencies in your project and combines them into a single file (or a few files) that can be efficiently loaded by the browser. This process not only improves performance by reducing the number of HTTP requests but also helps in managing dependencies more securely.

How Bundlers Improve Security

Local Assets: When you build your project using a bundler, it compiles all your code and dependencies into a single bundle. This means that your application is serving all its JavaScript from your own domain, not relying on third-party CDNs. This significantly reduces the risk of third-party script compromises.
Lock Files: NPM generates a package-lock.json file that locks the versions of all installed packages. This ensures that the same versions are used every time someone installs your project, even if newer versions of the dependencies are released. This consistency is crucial for security.

Integrity Checks: Modern build tools can include integrity checks to ensure that the files served to the browser match the expected hashes. This makes it harder for compromised or altered packages to go unnoticed.

Example with Vite

Let's take Vite, a modern bundler, as an example. When you install dependencies and build your project with Vite, it bundles all the necessary JavaScript files into a single minified file. Here’s a step-by-step of what happens:

Install Dependencies: You install your dependencies using NPM.
Build the Project: You run vite build, which compiles your project.
Serve Local Assets: When you deploy your project, all the JavaScript files are served from your own domain. No external CDNs are involved.

This process ensures that the JavaScript running on your site is exactly what you expect, with no surprises from third-party CDNs.

Addressing Common Misconceptions

There are several misconceptions about NPM and modern JavaScript development that contribute to the fear of security risks. Let’s address some of these:

Misconception 1: NPM Directly Serves Files to Users

Some believe that when users visit a site, they are directly fetching files from NPM. This is not true. NPM is used to manage and install dependencies during the development process. When you build and deploy your project, all the code is served from your own servers, not from NPM.

Misconception 2: Dev Dependencies are Included in Production

Another common misconception is that dev dependencies (packages used for development purposes, like testing or linting tools) are included in the final bundle served to users. This is false. Dev dependencies are only used during development and are not included in the production build.

Misconception 3: Package Lock Files are Unnecessary

Some developers overlook the importance of package-lock.json files. These files ensure that the exact same versions of dependencies are used every time the project is installed, which is crucial for maintaining security and consistency. Without a lock file, there’s a risk of pulling in newer, potentially compromised versions of dependencies.

Best Practices for Secure JavaScript Development

To further mitigate security risks, follow these best practices:

Regular Audits: Regularly audit your dependencies using tools like npm audit to identify and address vulnerabilities.
Lock File Maintenance: Always use and maintain your package-lock.json file. Ensure that your CI/CD pipelines respect the lock file to prevent accidental upgrades.
Dependency Management: Be mindful of the dependencies you add to your project. Avoid unnecessary dependencies and consider the reputation and activity of the package maintainers.
Use Trusted Sources: Prefer well-established libraries and avoid packages with unclear or questionable histories.
Stay Updated: Keep your dependencies up to date with the latest security patches. Tools like Dependabot can automate this process for you.

By taking proactive steps to secure your dependencies and being aware of how your tools work, you can harness the power of NPM and modern JavaScript development while keeping your projects safe and secure.

Conclusion

The NPM ecosystem, with its vast library of packages, undeniably brings convenience to JavaScript development. However, it also introduces potential security risks that cannot be ignored. Understanding how modern bundlers work, maintaining a strict dependency management strategy, and following best practices can significantly mitigate these risks.

Thank you for reading! If you found this blog post helpful, please consider sharing it with others who might benefit. Feel free to check out my other blog posts and visit my socials!

The End of Google URL Shortener and breaks 4.6 BILLION URLs!

Devarshi Shimpi — Thu, 01 Aug 2024 11:18:20 +0000

Introduction

The innovations Google has brought to the table, from Chrome to the Google ecosystem, have undeniably shaped the internet. But sometimes, their decisions leave us scratching our heads, frustrated and disappointed. One such decision is the end of goo.gl, their URL shortener service, which brings back memories of other products they have shelved over the years—like Google Reader and, more recently, Google Domains.

The Rise and Fall of goo.gl

When goo.gl was launched, it was a nifty tool that made sharing long, cumbersome URLs a breeze. It offered analytics and QR codes, making it a favorite among both casual users and developers.

But in 2018, Google announced that it would no longer support the creation of new goo.gl links, nudging users towards alternatives like Firebase Dynamic Links

Fast forward to now, and we've learned that all goo.gl links will completely stop working by August 2025. This isn’t just about not being able to make new links anymore; it means that all existing links will die. Clicking on them after the cutoff date will lead to a 404 error -- a digital dead end.

Alternatives to Google URL Shortener

Google suggested Firebase Dynamic Links as an alternative, but guess what? That service is also being deprecated on August 25, 2025. It's a frustrating loop, recommending one product as a replacement only to kill it off later. It makes planning and continuity a nightmare for users.

As goo.gl sunsets, users are left seeking alternatives. Services like Bitly, TinyURL, and dub.co offer similar functionalities, each service comes with its own set of features, policies, and levels of reliability.

I personally prefer dub.co and it has been great in my experience till now. Their team was quick enough to even make the migration process as seamless as possible! Especially their quick alternative as ggl.link

Conclusion

The decision to end goo.gl is a reminder of the impermanence of digital tools. While Google's decision might be based on practical considerations, the impact on users is real and far-reaching. It disrupts current operations, potentially erases valuable information, and once again highlights the precariousness of relying on a single company for critical digital infrastructure.

Thank you for reading! If you found this blog post helpful, please consider sharing it with others who might benefit. Feel free to check out my other blog posts and visit my socials!

How to create a new Next.js project with Cloudflare Pages and Workers

Devarshi Shimpi — Thu, 18 Jul 2024 14:58:33 +0000

Introduction

In this guide, we'll walk through creating a new Next.js 14 project using TypeScript and deploying it on Cloudflare Pages with Workers for a full-stack solution. We'll use the create-cloudflare CLI (C3) to set up our project, and deploy the application.

Step 1: Create a new Git repository

Go to GitHub, click the "+" icon in the top right, and select "New repository". Set the repository name to nextjs-cf-pages-workers or whatever you would like to, choose Public or Private visibility, and click "Create repository".

Your new repository is now ready! Clone the repository and get ready for the next step!

Step 2: Create a New Next.js Project

To get started, we'll use the create-cloudflare CLI (C3) to create a new Next.js project. Open your terminal and run the following command:

npm create cloudflare@latest my-next-app -- --framework=next

This command initializes a new Next.js project in a directory named my-next-app. Follow the prompts to configure your project. The CLI will install the necessary dependencies, including the Wrangler CLI and the @cloudflare/next-on-pages adapter.

In your terminal, this is how it should look like. After the project is created, navigate to the project directory, and run npm run dev. You should have a browser preview like this:

Step 3: Configure the Project for Cloudflare Pages

You can deploy using mutliple options, I have covered 2 in this article.

Log in to the Cloudflare dashboard and select your account. Navigate to Workers & Pages > Create application > Pages > Connect to Git. Authorize access to your GitHub account and select the new repository you created.

Make sure you have added nodejs_compat as the compatibility flags or the build will fail!

Step 4: Configure and Deploy Without C3

If you prefer not to use C3, you can manually configure and deploy your project. Install the @cloudflare/next-on-pages adapter:

npm install @cloudflare/next-on-pages

Step 5: Set Up Bindings for Local Development

Bindings allow your application to interact with Cloudflare developer products. To set up bindings for local development, modify your Next.js configuration:

// next.config.mjs
import { setupDevPlatform } from '@cloudflare/next-on-pages/next-dev'

if (process.env.NODE_ENV === 'development') {
  await setupDevPlatform()
}

/** @type {import('next').NextConfig} */
const nextConfig = {}

export default nextConfig

Ensure you have a wrangler.toml file at the root of your project with a KV binding:

# wrangler.toml
name = "my-next-app"
compatibility_flags = ["nodejs_compat"]

[[kv_namespaces]]
binding = "MY_KV"
id = "<YOUR_KV_NAMESPACE_ID>"

Alternatively, you can run the following command and it should deploy the project as shown below.

npm run deploy

Success!

By following these steps, you've successfully created and deployed a full-stack Next.js 14 project with TypeScript on Cloudflare Pages and Workers. This setup leverages Cloudflare's powerful developer products to enhance your application's capabilities.

Conclusion

Thank you for reading! If you found this blog post helpful, please consider sharing it with others who might benefit. Feel free to check out my other blog posts and visit my socials!

Managing Metadata in Next.js for Enhanced SEO and User Experience

Devarshi Shimpi — Tue, 02 Jul 2024 11:13:43 +0000

Introduction

In Next.js 14, there are two primary ways to manage metadata for your application: using a static metadata object or a dynamic generateMetadata function. Below is a detailed guide on how to utilize both options effectively.

This guide provides an in-depth look at both approaches, helping you understand how to effectively implement metadata in your Next.js application.

Next.js Demo with Metadata Output

In this live example, we'll create a simple Next.js application showcasing the usage of metadata. Then, we'll view the rendered output in the browser and visualise the metadata in action.

We start by creating a new Next.js project with create-next-app

npx create-next-app@latest

Here's the options I chose while creating it.

Add this sample code in the following block and let's preview it in the browser.

Code:

Output:

And here's the browser output with get with the tags, keep reading the entire article to see how you could implement in your code.

Static Metadata

To define static metadata, you export a Metadata object from a layout.ts or page.ts file using the App Router.

Example:

import { Metadata } from 'next'

export const metadata: Metadata = {
  title: 'Static Page Title',
  description: 'This is a static page description',
}

export default function Page() {}

This method is suitable when the metadata does not depend on runtime information.

Dynamic Metadata

Dynamic metadata allows you to generate metadata based on dynamic data, such as route parameters or fetched data.

Example:

import { Metadata, ResolvingMetadata } from 'next'

type Props = {
  params: { id: string }
  searchParams: { [key: string]: string | string[] | undefined }
}

export async function generateMetadata(
  { params, searchParams }: Props,
  parent: ResolvingMetadata
): Promise<Metadata> {
  const id = params.id
  const product = await fetch(`https://api.example.com/products/${id}`).then((res) => res.json())

  const previousImages = (await parent).openGraph?.images || []

  return {
    title: product.name,
    description: product.description,
    openGraph: {
      images: [product.imageUrl, ...previousImages],
    },
  }
}

export default function Page({ params, searchParams }: Props) {}

This method is useful when the metadata depends on dynamic data or needs to extend parent metadata.

Key Points

Server Components Only: Both metadata and generateMetadata are only supported in Server Components.
Single Export Rule: You cannot export both the metadata object and generateMetadata function from the same route segment.

Metadata Fields

Next.js provides a variety of metadata fields to customize the metadata of your application comprehensively.

Title

String

  export const metadata: Metadata = {
    title: 'Next.js Application',
  }

Output: <title>Next.js Application</title>

Template Object

  export const metadata: Metadata = {
    title: {
      template: '%s | Next.js',
      default: 'Next.js',
    },
  }

Output in child routes: <title>About | Next.js</title>

Absolute

  export const metadata: Metadata = {
    title: {
      absolute: 'About Us',
    },
  }

Output: <title>About Us</title>

Description

export const metadata: Metadata = {
  description: 'The React Framework for the Web',
}

Output: <meta name="description" content="The React Framework for the Web" />

Basic Fields

export const metadata: Metadata = {
  generator: 'Next.js',
  applicationName: 'Next.js App',
  keywords: ['Next.js', 'React', 'JavaScript'],
  authors: [{ name: 'Author Name', url: 'https://example.com' }],
}

Output:

<meta name="generator" content="Next.js" />
<meta name="application-name" content="Next.js App" />
<meta name="keywords" content="Next.js,React,JavaScript" />
<meta name="author" content="Author Name" />
<link rel="author" href="https://example.com" />

Open Graph

export const metadata: Metadata = {
  openGraph: {
    title: 'Next.js',
    description: 'The React Framework for the Web',
    url: 'https://nextjs.org',
    siteName: 'Next.js',
    images: [
      {
        url: 'https://nextjs.org/og.png',
        width: 800,
        height: 600,
      },
    ],
    locale: 'en_US',
    type: 'website',
  },
}

Output:

<meta property="og:title" content="Next.js" />
<meta property="og:description" content="The React Framework for the Web" />
<meta property="og:url" content="https://nextjs.org/" />
<meta property="og:site_name" content="Next.js" />
<meta property="og:locale" content="en_US" />
<meta property="og:image" content="https://nextjs.org/og.png" />
<meta property="og:image:width" content="800" />
<meta property="og:image:height" content="600" />

Twitter

export const metadata: Metadata = {
  twitter: {
    card: 'summary_large_image',
    title: 'Next.js',
    description: 'The React Framework for the Web',
    images: ['https://nextjs.org/og.png'],
  },
}

Output:

<meta name="twitter:card" content="summary_large_image" />
<meta name="twitter:title" content="Next.js" />
<meta name="twitter:description" content="The React Framework for the Web" />
<meta name="twitter:image" content="https://nextjs.org/og.png" />

Robots

export const metadata: Metadata = {
  robots: {
    index: false,
    follow: true,
    googleBot: {
      index: true,
      follow: false,
    },
  },
}

Output:

<meta name="robots" content="noindex, follow" />
<meta name="googlebot" content="index, nofollow" />

MetadataBase

metadataBase allows setting a base URL prefix for metadata fields that require a fully qualified URL.

Example:

export const metadata: Metadata = {
  metadataBase: new URL('https://example.com'),
  openGraph: {
    images: '/og-image.png',
  },
}

Output:

<meta property="og:image" content="https://example.com/og-image.png" />

Best Practices

Use Static Metadata When Possible: If metadata doesn't depend on runtime information, prefer static metadata for simplicity.
Dynamic Metadata for Dynamic Data: Use generateMetadata for routes where metadata depends on dynamic data or needs to extend parent metadata.
Combine Metadata Fields: Utilize a combination of different metadata fields to ensure comprehensive metadata coverage for SEO and social media integration.
Utilize metadataBase: Set a metadataBase in your root layout to simplify URL-based metadata field definitions.

Conclusion

By following these guidelines, you can effectively manage metadata in your Next.js 14 application, enhancing both SEO and user experience.

Thank you for reading! If you found this blog post helpful, please consider sharing it with others who might benefit. Feel free to check out my other blog posts and visit my socials!

Google's AI-Powered Cloud IDE Project IDX Goes Open Beta!

Devarshi Shimpi — Mon, 10 Jun 2024 09:39:50 +0000

Introduction

At the 2024 Google I/O developer conference, Google unveiled an exciting new tool for developers—Project IDX. Now in open beta, Project IDX is set to revolutionise the way we approach web and mobile app development.

With its AI-powered features and seamless cloud integration, this web-based integrated development environment (IDE) promises to simplify and enhance the development workflow.

What is Project IDX?

Project IDX is a next-generation, web-based IDE that aims to streamline the development process. Built on the popular Code OSS project and leveraging the robust infrastructure of Google Cloud, Project IDX offers a fully configurable virtual machine (VM) environment right in your browser.

For more details and to join the open beta, visit the Project IDX website.

This setup ensures reliability, safety, and complete configurability, making it an ideal choice for developers of all levels.

Making the Most of Project IDX

Get Started Quickly
Start new projects or import existing ones from GitHub effortlessly. Use pre-configured templates and choose from popular frameworks and languages like JavaScript, Dart, and soon Python and Go.
Leverage IDX AI for Enhanced Coding
Utilize IDX AI for intelligent code completion, translations, and explanations of complex snippets, boosting coding speed and quality.
Utilize Built-In Emulators for Mobile Development
Test your mobile apps with built-in Android emulators and iOS simulators, previewing changes in real-time within Project IDX.
Seamless Deployment with Firebase Hosting
Deploy web and Flutter projects directly to Firebase Hosting with a few clicks, ensuring fast, secure, and global hosting.
Collaborate with Ease
Use the experimental collaborative workspace sharing to invite team members, enabling real-time collaboration on code, terminals, emulators, and more.

Conclusion

Google's Project IDX is set to transform the development landscape with its innovative, AI-powered, and cloud-based IDE. Now in open beta, it's the perfect time to explore its capabilities and integrate it into your development workflow.

Thank you for reading! If you found this blog post helpful, please consider sharing it with others who might benefit. Feel free to check out my other blog posts and visit my socials!

Deploy MinIO on Amazon EKS and use your S3 Compatible Storage

Devarshi Shimpi — Thu, 23 May 2024 08:06:09 +0000

Introduction

Tired of the limitations and costs of AWS S3? Unlock a powerful alternative with MinIO, seamlessly integrated with Amazon EKS. This guide provides a step-by-step walkthrough to deploy MinIO, a scalable, multi-tenant object storage solution, on Amazon EKS in just 15 minutes.

Amazon EKS, a managed Kubernetes service on AWS, simplifies Kubernetes management, while MinIO, available on the AWS Marketplace, brings robust object storage capabilities. Imagine handling terabytes to exabytes of data, all while isolating tenants in their own namespaces, all without the confines of S3.

This guide empowers you to ditch AWS S3 and embrace a superior alternative. Let's get started!

Prerequisites

Before diving in, ensure you have the following tools installed:

awscli
kubectl
eksctl

Have these three configuration parameters handy:

AWS Account Number: Find it in the AWS Console or using this command:

export AWS_ACCOUNT_NUMBER=`aws sts get-caller-identity --query "Account" --output text`
echo $AWS_ACCOUNT_NUMBER

Region: For example, us-west-2.
Cluster Name: For example, minio-cluster.

Initial Setup

1. Set Up Cluster

New Cluster:
Replace <CLUSTER_NAME> and execute:

eksctl create cluster \
--name <CLUSTER_NAME> \
--version 1.21 \
--node-type=c6i.24xlarge \
--nodes-min=4 \
--nodes=4 \
--nodes-max=4 \
--zones=us-west-2a,us-west-2b,us-west-2c

2. Install AWS EBS CSI Driver

This driver allows using gp3 and sc1 storage types within EKS:

kubectl apply -k "github.com/kubernetes-sigs/aws-ebs-csi-driver/deploy/kubernetes/overlays/stable/?ref=release-1.5"

Cluster Configuration

1. Create IAM Policy

Replace <CLUSTER_NAME> and <AWS_ACCOUNT_NUMBER> in iam-policy.json:

aws iam create-policy \
--policy-name minio-eks-<CLUSTER_NAME> \
--policy-document file://iam-policy.json

2. Create an OIDC Provider

eksctl utils associate-iam-oidc-provider --region=us-west-2 --cluster=<CLUSTER_NAME> --approve

3. Create Trust, Role, and Service Account

For MinIO Operator:

eksctl create iamserviceaccount \
   --name minio-operator \
   --namespace minio-operator \
   --cluster <CLUSTER_NAME> \
   --attach-policy-arn arn:aws:iam::<AWS_ACCOUNT_NUMBER>:policy/minio-eks-<CLUSTER_NAME> \
   --approve \
   --override-existing-serviceaccounts

For AWS EBS CSI Driver:

eksctl create iamserviceaccount 
   --name ebs-csi-controller-sa 
   --namespace kube-system 
   --cluster <CLUSTER_NAME> 
   --attach-policy-arn arn:aws:iam::<AWS_ACCOUNT_NUMBER>:policy/minio-eks-<CLUSTER_NAME> 
   --approve 
   --override-existing-serviceaccounts

Installing MinIO

Deploy the MinIO Operator:

kubectl apply -k github.com/miniohq/marketplace/eks/resources

Accessing MinIO

1. Retrieve the JWT for Operator Console

kubectl -n minio-operator get secret $(kubectl -n minio-operator get serviceaccount console-sa -o jsonpath="{.secrets[0].name}") -o jsonpath="{.data.token}" | base64 --decode

2. Port Forward to Operator Console

kubectl -n minio-operator port-forward svc/console 9090

Open http://localhost:9090 in your browser and log in with the retrieved JWT.

3. Create a Tenant

Conclusion

Congratulations! In just 15 minutes, you've successfully deployed MinIO on Amazon EKS, paving the way for a robust and scalable object storage solution. This guide offers a powerful starting point for migrating away from AWS S3, empowering you with flexibility, cost-efficiency, and a superior alternative for your data storage needs.

Thank you for reading! If you found this blog post helpful, please consider sharing it with others who might benefit. Feel free to check out my other blog posts and visit my socials!

How To Create An AI Chatbot with Google GEMINI using Node.js

Devarshi Shimpi — Wed, 17 Apr 2024 10:29:23 +0000

Introduction

Generative AI has become a popular topic in the field of technology over the past year. Many developers are creating interesting projects using this technology. Google has developed its own generative AI model called Gemini.

In this article, we will be building a simple Node.js ChatBot and integrating Google Gemini into it. We will utilize the Google Gemini SDK for this purpose.

What is Gemini?

Google Gemini is an advanced AI model developed by Google AI. Unlike traditional AI models, Gemini is not limited to processing text alone. It can also comprehend and operate on diverse formats such as code, audio, images, and video. This feature opens up exciting possibilities for your Node.js projects.

Project Setup

1. Creating a Node.js Project

To begin our project, we need to set up a Node.js environment. Let's create a new Node.js project by running the following command in the terminal:

npm init -y

This command will initialize a new Node.js project.

2. Add boilerplate from Google AI Studio

Get the initial code from Google AI Studio, then click Get Code and copy the code for the Node.js and paste it into a file called as index.js

Also, make sure to generate an API key from the AI Studio. Select your Google Cloud project and click Create

3. Install Dependencies:

Now, We'll install the required dependencies of our project.

npm install @google/generative-ai ora chalk prompt-sync

The packages are used for the following:

@google/generative-ai: Google's package for generative AI tasks like text and image generation.
ora: Creates loading spinners and progress bars in the terminal.
chalk: Styles text in the terminal with colors and styles.
prompt-sync: Allows synchronous user input prompts in Node.js applications.

4. Create a chatbot and customize it

In the initial version of our chatbot script, we relied on CommonJS require statements for importing modules. However, in the final iteration, we embraced ES6 import syntax for cleaner and more modern code organization.

Go to your package.json file and add the following line below "main": "index.js",:

"type": "module",

It should look something like this (Top section only):

{
  "name": "devarshishimpi-google-gemini-nodejs-chatbot",
  "version": "1.0.0",
  "description": "Simple Google Gemini ChatBot for Nodejs",
  "main": "index.js",
  "type": "module",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },

and continued...

Then, we update from using const to using import

import { GoogleGenerativeAI, HarmCategory, HarmBlockThreshold } from "@google/generative-ai";
import chalk from 'chalk';
import ora from 'ora';
import prompt from 'prompt-sync';

One significant enhancement was the introduction of a user input mechanism using the prompt-sync library. This allowed users to interact with the chatbot in real-time, entering their messages directly into the console.

const userInput = promptSync(chalk.green('You: '));

Then, we customize the user interface with ora and chalk and make it more user responsive and easy to use

while (true) {
    const userInput = promptSync(chalk.green('You: '));
    if (userInput.toLowerCase() === 'exit') {
        console.log(chalk.yellow('Goodbye!'));
        process.exit(0);
    }
    const result = await chat.sendMessage(userInput);
    const response = result.response;
    console.log(chalk.blue('AI:'), response.text());
}

Then, we add some error handling logic to our code:

if (result.error) {
    console.error(chalk.red('AI Error:'), result.error.message);
    continue;
}
const response = result.response.text();
console.log(chalk.blue('AI:'), response);

5. Final Output

Please find the final code for project at, please star ⭐️ the repo if you found it useful:

devarshishimpi / google-gemini-nodejs-chatbot

Simple Google Gemini ChatBot for Nodejs

Google Gemini Node.js Chatbot

Simple Google Gemini ChatBot for Nodejs

Installation

npm install @google/generative-ai ora chalk prompt-sync

Replace the API_KEY in index.js with your own API key.

node index.js

Contributing

Pull requests are welcome. For major changes, please open an issue first to discuss what you would like to change. Please view the CONTRIBUTING.md for more information.

View on GitHub

Output:

We use node index.js to run our code. Make sure to replace YOUR_API_KEY with your generated API Key from Google API Studio.

Conclusion

Thank you for reading! If you found this blog post helpful, please consider sharing it with others who might benefit. Feel free to check out my other blog posts and visit my socials!

WordPress.com vs. WordPress.org – The Differences & Which To Choose

Devarshi Shimpi — Sat, 17 Feb 2024 13:05:06 +0000

Are WordPress.com and WordPress.org the same? It's a question that may seem obvious, but the truth is that those three little letters after the period make a huge difference and could impact the success of your website in the future.

So, what are the differences between WordPress.com and WordPress.org? Besides sharing the name 'WordPress', there are significant differences to consider when choosing the platform for your website.

What Is The Difference Between WordPress.com and WordPress.org?

To make things clear, let's cover all the differences between WordPress.com and WordPress.org, starting with the fundamental difference:

The Fundamental Difference

WordPress.org is managed by the non-profit WordPress Foundation, and it is a self-hosted content management system. This means that you can install it anywhere and buy your own domain to set up a website. It is not only a self-hosted content management system, but it is also the world's leading content management system.

WordPress.com, on the other hand, is essentially the largest WordPress-as-a-Service (WaaS) platform owned by Automattic, the company run by WordPress co-founder, Matt Mullenweg. It is powered by the WordPress.org open-source software.

TL;DR – WordPress.com vs. WordPress.org Differences

In short, WordPress.com is a limited version of WordPress.org that has been simplified for a different demographic.

The main differences between the two are:

WordPress.com:

Hosting is provided by WordPress.com
Limited monetization options - no advertising options other than the "official" WordPress.com advertising program
Limited plugin installation or updates on the free plan (higher-tier plans have similar limitations)
Limited choice of free themes
Limited customization options
No Google Analytics on the free plan
Upgrade required for the use of custom domains without the WordPress.com subdomain
No eCommerce features or integrated payment options on the free plan
No membership websites

WordPress.org:

Requires external hosting (e.g., using a cloud provider or a shared hosting service)
More flexibility in monetization options
Unrestricted plugin installation and updates
Access to a wide range of free and premium themes
Customization options are not limited
Google Analytics and other tracking tools can be used
Ability to use custom domains
eCommerce features and integrated payment options available
Membership websites can be created

Verdict

While WordPress.com may have its advantages, there are more limitations compared to WordPress.org. Your decision on whether to choose WordPress.com or WordPress.org should be based on the requirements and goals of your website.

Pricing and Cost Differences

Budget is always one of the first things you have to figure out when you’re building something. In this case, there are big differences between the pricing and costs of WordPress.com and WordPress.org, so to help you plan your budget better, we have broken down both solutions.

WordPress.com offers four different pricing plans that can be paid annually, upfront, or monthly.

Here’s a detailed pricing breakdown for WordPress.com

Besides these, WordPress.com does offer a free plan, and all you have to do is buy the domain. However, you will have their subdomain displayed e.g www.yourwebsite.wordpress.com.

When it comes to WordPress.org, it’s completely free to use. However, there are other costs that WordPress.org doesn’t cover, which WordPress.com covers for you.

Hosting – You can either set up a server with a cloud provider like DigitalOcean, Linode or Vultr or using a shared hosting service
Security — Depending on your hosting, you might need some premium security features or plugins that can cost up to $250 per year.
Premium themes — there are free ones, but to get the most out of WordPress.org, you’ll probably want to go with premium themes. They usually cost up to $150 per year.
Premium plugins — another optional thing, but if you’re serious about scaling your website fast, you will probably want to go with some premium plugins like Rank Math for SEO.

Ease of Use

Both WordPress.com and WordPress.org have a learning curve, but the ease of use may vary depending on your level of experience and needs.

WordPress.com is designed for blogging, and its setup is more straightforward. However, it comes with limitations and fewer options for customization.

WordPress.org offers more freedom and flexibility but may require more technical expertise to set up and configure.

Plugins

Plugins play a crucial role in extending the functionality of your website. Here's how plugins are handled on WordPress.com and WordPress.org:

WordPress.com restricts plugin usage to the Business plan. On the free plan and lower-tier plans, you won't have the ability to install or upload plugins. This limits your control over the website's features.

With WordPress.org, you have no limitations when it comes to plugins. You can freely install and configure any plugin, whether free or premium, to customize your website.

After Action Report – Use WordPress.org for Maximum Versatility & Control

Although both platforms have their advantages and disadvantages, there's no question that WordPress.org is the best solution for businesses that are already established or planning significant growth.

With WordPress.org, you have complete control over your website. You can choose from a vast selection of addons and plugins to integrate various functionalities, customize themes, and have full control over your website's appearance.

Happy Coding!!!

Thank you for reading! Feel free to check out my other blog posts and visit my socials!

Forem: Devarshi Shimpi

Voice Search in Chrome Extensions Is Harder Than It Looks

Starting with the obvious choice

Why you can't call Deepgram directly from the extension

Hono looked like the right tool. It wasn't.

The timing bug I should've seen coming

Cloudflare's 10ms CPU limit is real

AudioWorklet and Manifest V3 don't work together

The old deprecated API that actually works

A few smaller things worth knowing

What actually changed

Happy Coding!!!

Read more

React (RSC) Exploits Are Real and It's Hurting Engineering Teams

The "React2Shell" RCE (CVE-2025-55182)

How React2Shell Works

How Next.js was Affected

The DevOps Nightmare

The Aftershocks (DoS and Leaks)

1. Denial of Service (CVE-2025-55184)

2. Source Code Leak (CVE-2025-55183)

Immediate Action Plan

Conclusion

Read more

Dynamic Styling with calc() in TailwindCSS

Introduction

First Things First: What Exactly is calc()?

Why Bring calc() into the Tailwind World?

Using Arbitrary Values [] with calc()

Let's Get Practical: Real-World calc() Scenarios in Tailwind

Example 1: The Classic Sidebar + Content Layout

Example 2: Making Room for Fixed Headers/Footers

Example 3: Fluid Typography That Breathes

Example 4: Precise Centering and Positioning

Going Beyond Arbitrary Values: Custom calc() Utilities

Conclusion

Read more

Introduction to Next.js 15: What's New and the improvements!

Introduction

Seamless Upgrades with @next/codemod CLI

Performance Enhancements

Developer Experience (DX) Improvements

Static Route Indicator

New Middleware Capabilities

Support for React 19 and ESLint 9

Conclusion

Read more

Managing Dependencies and Security in JavaScript with NPM

Introduction

Understanding NPM and Its Ecosystem

The Dependency Hell

The Security Concerns

The Polyfill.io Incident

So, Are We Trading Security for Convenience?

Modern Bundlers to the Rescue

What is a Bundler?

How Bundlers Improve Security

Example with Vite

Addressing Common Misconceptions

Misconception 1: NPM Directly Serves Files to Users

Misconception 2: Dev Dependencies are Included in Production

Misconception 3: Package Lock Files are Unnecessary

Best Practices for Secure JavaScript Development

Conclusion

Read more

The End of Google URL Shortener and breaks 4.6 BILLION URLs!

Introduction

The Rise and Fall of goo.gl

Alternatives to Google URL Shortener

Conclusion

Read more

How to create a new Next.js project with Cloudflare Pages and Workers

Introduction

Step 1: Create a new Git repository

Step 2: Create a New Next.js Project

Step 3: Configure the Project for Cloudflare Pages

Step 4: Configure and Deploy Without C3

Step 5: Set Up Bindings for Local Development

Success!

Conclusion

First Things First: What Exactly is `calc()`?

Why Bring `calc()` into the Tailwind World?

Using Arbitrary Values `[]` with `calc()`

Let's Get Practical: Real-World `calc()` Scenarios in Tailwind

Going Beyond Arbitrary Values: Custom `calc()` Utilities