Forem: Neeraj Lagwankar

Securing Vibe Coded Applications using Cloudflare Access

Neeraj Lagwankar — Sat, 12 Apr 2025 07:45:38 +0000

Background

I wanted to share some large video files with my friends on Discord, but due to the file size limit I could not. I could have easily uploaded them to YouTube (and make them unlisted) or my Google Drive (which would have eaten up my space), but where's the fun in that. Instead, I thought, why not upload them to my R2 bucket and then share that URL instead.

This being a fun little project, I thought why not also give "vibe coding" a try. The project is open source on my GitHub as well.

But now the issue was, the domain from which I was uploading the files was unauthenticated. Anyone could just visit the domain and begin uploading files to my R2 bucket which I did not want. Furthermore, having auth for such a simple side project seemed overkill to me.

Cloudflare Access to the rescue

Cloudflare Access allows you to configure who can reach your application based on the policies you set. Automatic identification via GitHub OAuth worked the best for me since I'm always logged into GitHub from pretty much everywhere. Below steps will show you how to configure one for yourself.

Confguration

Creating a login method

Go to Cloudflare One, click on Settings and then Authentication.

Under Login methods click on Add new and then click on GitHub on the next screen.

Follow the on screen instructions and put in the App ID and Client Secret.

Creating a policy

Now that a login method has been created, we need to configure it a bit.

Under Access, click on Policies and then Add an application.
Enter Policy name, Action as Allow and Session duration to whatever you want. I personally like to set it to 24 hours.

Under Selector select Login methods and under Value choose the GitHub login method you created earlier.
Click on + Add include, choose Emails under Selector and add the emails which you want to allow under the Value field.
Click on Save.

Securing the application

Under Access, click on Applications and then Add an application.
Select Self-hosted.
Add an Application name. If your website is on a subdomain, enter it, else leave it blank and choose the Domain already added in your Cloudflare account.
Click on Select existing policies and choose the GitHub policy which you created earlier.

Under Login methods disable Accept all available identity providers, select only the GitHub provider (in case you have multiple configured) and enable Instant Auth which would automatically trigger the GitHub OAuth flow.

Click on Next, Next and Save.

Now if anyone visits your application, they would be allowed only if their GitHub email maches the one which you have specified. You have now successfully secured your "vibe coded" application.

If you have a separate API, ensure you have something similar in place for that as well. I only needed to secure my single app since it was a fullstack application.

Enjoy 🥳

Using Cloudflare Durable Objects with SQL Storage, D1, and Drizzle ORM

Neeraj Lagwankar — Thu, 27 Feb 2025 06:23:37 +0000

Before we begin, ensure that you're on the Workers paid plan to use Durable Objects.

Background

Recently, in one of my side projects, I wanted to use Durable Objects with the SQL API which should use the same schema as my D1 database (Cloudflare's serverless SQL database). And all this should be achieved via drizzle ORM. This post covers how I made it all work together.

But before we proceed, what are Durable Objects? A DO (Durable Object) allows you to stick some data to it which persists between requests making your app "stateful". I think Wes too summed it up pretty neatly:

Classes that stick around
— Wes Bos (@wesbos) February 24, 2025

The complete code can be found on my GitHub. All the links which helped me fix some pain points are mentioned in the README and are also at the bottom of this post.

Project and environment setup

Project setup with Hono

We'll begin by creating a Hono app. I'm using Bun as my package manager.

I'll run bun create hono@latest to begin scaffolding the app.

Give your app a name. I gave do-d1-drizzle.
Choose cloudflare-workers as your template.
Choose your package manager. I chose bun.
Install the dependencies.

Install these additional dependencies: bun add better-sqlite3 dotenv drizzle-orm && bun add -D drizzle-kit.

Then, go to your Cloudflare dashboard and create a D1 database.

Update your wrangler.jsonc with the below config

{
  "$schema": "node_modules/wrangler/config-schema.json",
  "name": "do-d1-drizzle",
  "main": "src/index.ts",
  "compatibility_date": "2025-02-25",
  "d1_databases": [
    {
      "binding": "DO_D1_DB",
      "database_name": "do-d1-drizzle",
      "database_id": "2c796f08-3b14-42d3-85e4-a3a389114b00",
      "migrations_dir": "drizzle/migrations",
      "migrations_table": "__drizzle_migrations",
    },
  ],
}

binding - can be any name via which you want to access the database.
database_name - the name given while creating the database.
database_id - the id generated after the database is created.
migrations_dir - the directory where drizzle would generate it's migrations which D1 should refer.
migrations_table - the table under which information regarding migrations should be stored.

Under your src directory, create a types.ts file with the below content

export type Env = {
  Bindings: {
    DO_D1_DB: D1Database;
  };
};

Also, create a db directory and add two files: index.ts and schema.ts. Taking reference of the offical drizzle guide for D1, we'll create 2 tables with simple data models: userTable and a postTable

schema.ts

import { relations } from 'drizzle-orm';
import { int, sqliteTable, text } from 'drizzle-orm/sqlite-core';

export const userTable = sqliteTable('user_table', {
  id: int().primaryKey({ autoIncrement: true }),
  name: text().notNull(),
});

export const postTable = sqliteTable('post_table', {
  id: int().primaryKey({ autoIncrement: true }),
  title: text().notNull(),
  content: text().notNull(),
  userId: int().references(() => userTable.id),
});

export const userRelations = relations(userTable, ({ many }) => ({
  posts: many(postTable),
}));

export const postRelations = relations(postTable, ({ one }) => ({
  user: one(userTable, {
    fields: [postTable.userId],
    references: [userTable.id],
  }),
}));

index.ts

import { drizzle } from 'drizzle-orm/d1';

import type { Env } from '../types';
import * as schema from './schema';

export function createDB(env: Env['Bindings']) {
  const db = drizzle(env.DO_D1_DB, { schema });
  return db;
}

We'll now have to update our package.json with these scripts:

  "scripts": {
    "dev": "wrangler dev",
    "deploy": "wrangler deploy --minify",
    "db:generate": "drizzle-kit generate",
    "db:migrate": "wrangler d1 migrations apply DO_D1_DB --local",
    "db:studio": "LOCAL_DB_PATH=$(find .wrangler/state/v3/d1/miniflare-D1DatabaseObject -type f -name '*.sqlite' -print -quit) drizzle-kit studio"
  },

db:generate - this will generate migrations based on the schema and the changes you make. Each time any modifications are made to the schema, this has to run.
db:migrate - this will apply the migrations on the local D1 instance. This won't update your remote D1 since wrangler emulates the bindings which you're using (apart from AI) for you to test locally w/o deploying to their network. This too would have to be run, each time any modifications are made to the schema.
db:studio - since the D1 instance is local, we can view it via drizzle-kit studio command. This basically finds the latest sqlite instance in the wrangler directory and assigns it to LOCAL_DB_PATH. This will be used in the drizzle.config.ts which we'll be creating later on.

Tokens and IDs

We're going to create some tokens and get some ids to get it all working together since we're going to use GitHub Actions to deploy our Worker to Cloudflare.

Account and D1 IDs

Log into Cloudflare dashboard, go to Workers & Pages and make a note of the Account ID visible at the right side.
Make a note of the D1 database id which you created in the earlier step. You can refer the same from wrangler.jsonc as well.

We'll now create 2 tokens: a D1 token and a deployment token.

D1 token

To create D1 token, visit: API Tokens.
Click on Create Token and then click on Get Started at the bottom.
Give it a name. Then under permissions, select Account then D1 then Edit.
Click on Continue to summary and then Create Token.
Make a note of this token as this won't be shown again after you navigate away from this screen.

Workers token

To create Workers deployment token, visit: API Tokens.
Click on Create Token and then click on Use template besides Edit Cloudflare Workers.
Give it a name. Then under Account Resources, select your account.
Click on Continue to summary and then Create Token.
Make a note of this token as this won't be shown again after you navigate away from this screen.

For secret environment variables, it is recommended to use .dev.vars file instead of .env while working with Workers. So create a .dev.vars file at the root (outside src) with the below content

CLOUDFLARE_ACCOUNT_ID=YOUR_ACCOUNT_ID
CLOUDFLARE_DATABASE_ID=YOUR_DATABASE_ID
CLOUDFLARE_D1_TOKEN=YOUR_D1_TOKEN

The Workers deployment token will come into picture later.

In the root directory, create a drizzle.config.ts file with the below content:

import { config } from 'dotenv';
import { defineConfig } from 'drizzle-kit';

config({ path: '.dev.vars' });

export default process.env.LOCAL_DB_PATH
  ? {
      schema: './src/db/schema.ts',
      dialect: 'sqlite',
      dbCredentials: {
        url: process.env.LOCAL_DB_PATH,
      },
    }
  : defineConfig({
      schema: './src/db/schema.ts',
      dialect: 'sqlite',
      out: './drizzle/migrations',
      driver: 'd1-http',
      dbCredentials: {
        accountId: process.env.CLOUDFLARE_ACCOUNT_ID!,
        databaseId: process.env.CLOUDFLARE_DATABASE_ID!,
        token: process.env.CLOUDFLARE_D1_TOKEN!,
      },
    });

config - by default it looks for .env file. Since we have our variables in .dev.vars, we need to specify the correct path.
The first condition becomes true when you're running the db:studio command. It goes in the else block when the db:migrate command is run.
Check the dialect and driver keys. During db:studio, we do not need d1-http driver as we're just running the drizzle-kit studio UI to see what all there is in our DB.

D1 setup

Alright! We can now run the scripts one by one to see whether our D1 configuration is good to go or not. Run the following commands one by one.

`bun db:generate`

This was the console output for me:

$ drizzle-kit generate
No config path provided, using default 'drizzle.config.ts'
Reading config file '/home/flashblaze/projects/do-d1-drizzle/drizzle.config.ts'
2 tables
post_table 4 columns 0 indexes 1 fks
user_table 2 columns 0 indexes 0 fks

[✓] Your SQL migration file ➜ drizzle/migrations/0000_tough_slyde.sql

This would have also created a drizzle folder with a single migration. Below is how it looks for me. The migration name would be different for you, but the structure should be pretty much the same

drizzle/
├─ migrations/
│  ├─ meta/
│  │  ├─ _journal.json
│  │  ├─ 0000_snapshot.json
│  ├─ 0000_tough_slyde.sql
node_modules/
src/
.dev.vars
.gitignore
bun.lock
drizzle.config.ts
package.json
README.md
tsconfig.json
wrangler.jsonc

If a migrations.js is not created under drizzle/migrations, create one with the below content. Note that you might have to replace the migration file name with the one which has been generated

import m0000 from './0000_tough_slyde.sql';

import journal from './meta/_journal.json';

export default {
  journal,
  migrations: {
    m0000,
  },
};

Now to apply the migrations, run the below command.

`bun db:migrate`

Upon running it, you will get a confirmation prompt. Press y to proceed and it should look something like this

$ wrangler d1 migrations apply DO_D1_DB --local

 ⛅️ wrangler 3.109.3
--------------------

Migrations to be applied:
┌──────────────────────┐
│ name                 │
├──────────────────────┤
│ 0000_tough_slyde.sql │
└──────────────────────┘
✔ About to apply 1 migration(s)
Your database may not be available to serve requests during the migration, continue? … yes
🌀 Executing on local database DO_D1_DB (2c796f08-3b14-42d3-85e4-a3a389114b00) from .wrangler/state/v3/d1:
🌀 To execute on your remote database, add a --remote flag to your wrangler command.
🚣 3 commands executed successfully.
┌──────────────────────┬────────┐
│ name                 │ status │
├──────────────────────┼────────┤
│ 0000_tough_slyde.sql │ ✅     │
└──────────────────────┴────────┘

To view the database, run

`bun db:studio`

Visit https://local.drizzle.studio. It would look something like this

D1 deployment

We'll now set up GitHub Actions to deploy the Worker when it is pushed to the main branch. For this, create a workflow.yml file under .github/workflows directory with this content

name: Deploy Worker
on:
  push:
    branches:
      - main
    paths:
      - '.github/workflows/workflow.yml'

jobs:
  deploy:
    runs-on: ubuntu-latest
    timeout-minutes: 60
    steps:
      - uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20.17.0'

      - name: Install Bun
        uses: oven-sh/setup-bun@v1
        with:
          bun-version: latest

      - name: Install dependencies
        run: bun install

      - name: Deploy API to Cloudflare
        uses: cloudflare/wrangler-action@v3
        with:
          apiToken: ${{ secrets.CLOUDFLARE_API_TOKEN }}
          accountId: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }}
          command: deploy

      - name: Apply D1 Migrations
        uses: cloudflare/wrangler-action@v3
        with:
          apiToken: ${{ secrets.CLOUDFLARE_D1_TOKEN }}
          accountId: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }}
          command: d1 migrations apply DO_D1_DB --remote

We're using Node version 20.17.0 and installing bun via their action
Next we're deploying to Cloudflare using their action. As you can see we're referring CLOUDFLARE_API_TOKEN, CLOUDFLARE_ACCOUNT_ID and CLOUDFLARE_D1_TOKEN. We already have these variables which we've taken a note of in the earlier step

Since the above action is referring these variables, we need to put them in our GitHub repo. As such, go to Secrets and variables under your repo Settings, click on New repository secret and add these values respectively under Actions. After pushing all these changes to your repo, your Worker should be deployed successfully! 🎉

Now let's move on to DO part.

DO setup

Config and class

Update your wrangler.jsonc with the below one. I'm only attaching the part related to the DO

 "durable_objects": {
    "bindings": [
      {
        "name": "DO_D1_DO",
        "class_name": "SampleObject"
      }
    ]
  },
  "migrations": [
    {
      "tag": "v1",
      "new_sqlite_classes": ["SampleObject"]
    }
  ],
  "rules": [
    {
      "type": "Text",
      "globs": ["**/*.sql"],
      "fallthrough": true
    }
  ]

For SQL backend, DO requires the config in the above pattern. Refer drizzle guide.
SampleObject is the name of the class which we'll be creating in the next step.

Create a sample-durable.ts file inside src with the below content:

/// <reference types="@cloudflare/workers-types" />
import { DurableObject } from 'cloudflare:workers';
import {
  type DrizzleSqliteDODatabase,
  drizzle,
} from 'drizzle-orm/durable-sqlite';
import { migrate } from 'drizzle-orm/durable-sqlite/migrator';

import { userTable } from './db/schema';
import type { Env } from './types';

import migrations from '../drizzle/migrations/migrations.js';

export class SampleObject extends DurableObject {
  storage: DurableObjectStorage;
  db: DrizzleSqliteDODatabase;

  constructor(ctx: DurableObjectState, env: Env) {
    super(ctx, env);
    this.storage = ctx.storage;
    this.db = drizzle(this.storage, { logger: false });
  }

  async migrate() {
    await migrate(this.db, migrations);
  }

  async insert({ name }: { name: string }) {
    return await this.db.insert(userTable).values({ name }).returning();
  }

  async getUsers() {
    return await this.db.select().from(userTable);
  }
}

We're exporting the SampleObject class which we've referenced in wrangler.jsonc.
In the constructor we're assigning storage and db using drizzle. Refer the guide.
Then, we've created 3 methods:

migrate - which we'll be calling in our workflow.yml to keep it in sync with our schema based on the migrations which we're importing.

insert - which we'll be calling inside our API route to add an user.

getUsers - which we'll be calling inside our API route to get all the users.

Update the types.ts with the following

import { SampleObject } from './sample-durable';

export type Env = {
  Bindings: {
    DO_D1_DB: D1Database;
    DO_D1_DO: DurableObjectNamespace<SampleObject>;
  };
  Variables: {
    stub: DurableObjectStub<SampleObject>;
  };
};

Migrations and data entry

Everything now in place, we need to create some endpoints to interact with D1 as well as with DO. Update your src/index.ts with the following

import { Hono } from 'hono';
import { Env } from './types';
import { createDB } from './db';
import { userTable } from './db/schema';
import { SampleObject } from './sample-durable';

const app = new Hono<Env>();

app
  .get('/', c => {
    return c.text('Hello Hono!');
  })
  .get('/migrate', async c => {
    const durableObject = c.env.DO_D1_DO.idFromName('do-d1-drizzle');
    const durableObjectStub = c.env.DO_D1_DO.get(durableObject);
    await durableObjectStub.migrate();
    return c.json({
      message: 'Migrated!',
    });
  })
  .get('/create', async c => {
    const db = createDB(c.env);
    const dbUser = await db
      .insert(userTable)
      .values({ name: `db-user-${new Date().toISOString()}` })
      .returning()
      .get();

    const durableObject = c.env.DO_D1_DO.idFromName('do-d1-drizzle');
    const durableObjectStub = c.env.DO_D1_DO.get(durableObject);
    const doUser = await durableObjectStub.insert({
      name: `do-user-${new Date().toISOString()}`,
    });

    return c.json({ dbUser, doUser });
  })
  .get('/users', async c => {
    const db = createDB(c.env);
    const dbUsers = await db.select().from(userTable);

    const durableObject = c.env.DO_D1_DO.idFromName('do-d1-drizzle');
    const durableObjectStub = c.env.DO_D1_DO.get(durableObject);
    const doUsers = await durableObjectStub.getUsers();

    return c.json({ dbUsers, doUsers });
  });

export { SampleObject };

export default app;

We're typing the Hono instance with the Env to get type hints
/migrate endpoint has to be hit once the app is running/deployed to migrate the DO SQL backend. This endpoint is using the migrate method which we created
/create endpoint creates an user in D1 and DO and returns both the records
/users endpoint fetches all the users from D1 and DO
We're also named exporting SampleObject since DO looks for it in the main file which we're running. In our case it is src/index.ts

The migrate endpoint should have some kind of auth like maybe a custom header which the app would check before migrating to prevent unnecessary DO hits.

Test test test

Run bun dev which will run the app on http://localhost:8787.
Visit http://localhost:8787/migrate to run the DO migrations.
Visit http://localhost:8787/create to create a dummy user.
Visit http://localhost:8787/users to fetch all the D1 and DO users.

We're not doing anything with the posts, but similar to how userTable was imported and used in the SampleObject class, postTable operations too can be performed.

DO deployment

That's all good, but what about when the app is deployed? Well, for that we'll use GitHub Actions and hit the endpoint once the deployment is completed. Add the below step after the Apply D1 Migrations in workflow.yml

- name: Apply DO Migrations
  run: |
    sleep 10  # Wait for deployment to be fully ready
    curl -X GET "https://do-d1-drizzle.flashblaze.workers.dev/migrate"

https://do-d1-drizzle.flashblaze.workers.dev is the URL where your Worker is deployed

And we're done! With this we can now safely use the same schema for D1 and DO.

Useful links

https://github.com/flashblaze/do-d1-drizzle - GitHub repo for this blog post
https://github.com/neondatabase-labs/cloudflare-drizzle-neon/blob/main/migrate.ts - referring the .dev.vars
https://github.com/drizzle-team/drizzle-orm/discussions/1545#discussioncomment-8689233 - this comment led me to the below blog post
https://kevinkipp.com/blog/going-full-stack-on-astro-with-cloudflare-d1-and-drizzle - how to use drizzle-kit studio with local DB

By the time this post is published, the Worker URL might not be reachable since I'll be removing it.

Migrating my Turso DB to Cloudflare D1

Neeraj Lagwankar — Tue, 29 Oct 2024 16:43:18 +0000

Checkout the previous post on How I deployed my Astro + Turso + Drizzle project to Cloudflare Pages if you want to know more about the project.

Background

I wanted to migrate my Turso DB to Cloudflare D1. As such this post will go into the details of the challenges I faced during the migration process.

You can find the project and the repository below:

MapViz

flashblaze/map

Challenges

Making D1 work with drizzle and Astro

D1 as well as drizzle-kit requires the project to have a wrangler.toml file. Here is mine:

#:schema node_modules/wrangler/config-schema.json
name = "map"
compatibility_date = "2024-10-11"
pages_build_output_dir = "./dist"

[placement]
mode = "smart"

[vars]
NODE_VERSION = "20.17.0"
PNPM_VERSION = "9.9.0"

[[d1_databases]]
binding = "MAP"
database_name = "map"
database_id = "10eb6d23-6724-46e8-9bf2-c4091739f69f"
migrations_dir = "migrations"
migrations_table = "__drizzle_migrations"

Ensure the corresponding D1 binding is also set in Cloudflare dashboard. Based on their docs it seemed like drizzle expects the argument to be of type D1Database. Since env.d.ts file is being used throughout the application for environment related stuff, I updated it like so:

/// <reference path="../.astro/types.d.ts" />

type Runtime = import("@astrojs/cloudflare").Runtime<Env>;

declare namespace App {
  interface Locals extends Runtime {
    env: {
      CLOUDFLARE_ACCOUNT_ID: string;
      CLOUDFLARE_DATABASE_ID: string;
      CLOUDFLARE_D1_TOKEN: string;
      CLOUDFLARE_D1_BINDING: string;
      MAP: D1Database;
    };
  }
}

interface ImportMeta {
  readonly env: {
    readonly CLOUDFLARE_ACCOUNT_ID: string;
    readonly CLOUDFLARE_DATABASE_ID: string;
    readonly CLOUDFLARE_D1_TOKEN: string;
    readonly CLOUDFLARE_D1_BINDING: string;
  };
}

If you observe, MAP in the env.d.ts file matches the binding in the wrangler.toml file.

Turso dump was not working

I wanted to take a dump of my data. After searching, I found out about the dump command. I ran turso db shell map-viz ".dump" > map-viz.sql. map-viz being the name of my database. However, every single time, the map-viz.sql was being created with empty content. I'm not sure what was wrong since I was correctly executing the command and the data was also present. So I finally resorted to manually exporting the data in the CSV format.

D1 does not support importing data in the CSV format

Feeling good about myself after clearing the Turso hurdle, I was disappointed to find out that D1 does not support CSV import (at least as of this writing). So how to solve this new issue then?

I updated my env to point to the hosted D1 and ran pnpm db:migrate to apply the migrations to my database. Good thing was D1 allowed running SQL queries directly. Since I had the CSV data, I wanted to create SQL statements from it. What good way than to use Claude for this. I asked it to write SQL queries and provided it a couple of CSV records. After modifying the output a bit, here is the final JS file which I used:

const fs = require("fs");
const csv = require("csv-parse/sync");

const fileName = "location.csv";
const tableName = "location";

// Function to escape single quotes in string values
function escapeQuotes(value) {
  return value.replace(/'/g, "''");
}

// Function to format value for SQL
function formatValue(value) {
  if (value === "") return "NULL";
  if (isNaN(value)) return `'${escapeQuotes(value)}'`;
  return value;
}

// Read the CSV file
const fileContent = fs.readFileSync(fileName, "utf8");

// Parse the CSV content
const records = csv.parse(fileContent, {
  columns: true,
  skip_empty_lines: true,
});

// Generate INSERT statements
const insertStatements = records.map((record) => {
  const columns = Object.keys(record).join(", ");
  const values = Object.values(record).map(formatValue).join(", ");
  return `INSERT INTO ${tableName} (${columns}) VALUES (${values});`;
});

// Write INSERT statements to a file
fs.writeFileSync(`${fileName}.sql`, insertStatements.join("\n"));

console.log(`INSERT statements have been written to ${fileName}.sql`);

After running the script it generated the SQL statements like so:

INSERT INTO location (id, created_at, updated_at, latitude, longitude, city, region, region_code, country, hash, count, last_visit) VALUES (54, '2024-10-12 11:21:03', 1728732060, -34.0866, 18.8144, 'Somerset West', 'Western Cape', 'WC', 'ZA', '-34.08660-18.81440-Somerset West-Western Cape-WC-ZA-45.222.74.86', 1, 1728732060);
INSERT INTO location (id, created_at, updated_at, latitude, longitude, city, region, region_code, country, hash, count, last_visit) VALUES (64, '2024-10-12 17:19:12', 1728753549, 46.3153, 4.8344, 'Mâcon', 'Bourgogne-Franche-Comté', 'BFC', 'FR', '46.31530-4.83440-Mâcon-Bourgogne-Franche-Comté-BFC-FR-2a01:cb10:82ae:c600:259e:a34c:1e8e:a4b5', 1, 1728753549);

SQL commands now being generated, the last step was to import the data. For which I ran wrangler d1 execute map --file=./location.csv.sql --remote and voila! The data was there in my D1 database.

Conclusion

Even though I faced some challenges during integration of Cloudflare services and migrating data, moving to D1 was a good decision since the initial load times have pretty much been cut in half.

Deploying my Astro + Turso + Drizzle project to Cloudflare Pages

Neeraj Lagwankar — Mon, 21 Oct 2024 03:30:00 +0000

Background

I wanted to build a project which utilized map in some way using deck.gl. So I thought what better way than to visualize the users who are visiting the project itself. I knew I would need visitor's location (rough/accurate it did not matter to me that much) and I was aware that Cloudflare allows you to enable location headers from which I could extract the data which I wanted.

This post won't go into detail of the project itself as such. Rather the issues and the flow itself for deploying the app. Below are the links to the project and the repository:

MapViz

flashblaze/map

Tech stack

I knew I wanted a fullstack framework to access the headers from the app itself. As such, I went with Astro since I was familiar with it and the docs also explain in great detail on how to deploy Astro site on Cloudflare Pages.
For rendering the map, I went with Preact and deck.gl.
For storing the location data, I could have gone with Cloudflare's own D1, but I went with Turso and drizzle ORM as my ORM.

Skill issue

drizzle-kit: `import.meta` is not available

This was my drizzle.config.ts and after running the drizzle-kit generate command I ran into this this error: "import.meta" is not available with the "cjs" output format and will be empty

import { defineConfig } from "drizzle-kit";

export default defineConfig({
  schema: "./src/db/schema.ts",
  out: "./migrations",
  dialect: "turso",
  dbCredentials: {
    url: import.meta.env.TURSO_CONNECTION_URL ?? "",
    authToken: import.meta.env.TURSO_AUTH_TOKEN ?? "",
  },
});

Based on the error message, it felt like it needs the environment variables using process.env format. As such I had to update the config like so:

import { defineConfig } from "drizzle-kit";
import { config } from "dotenv";

// drizzle-kit does not support import.meta.env, so we need to load the .env file manually.
config({ path: "../.env" });

export default defineConfig({
  schema: "./src/db/schema.ts",
  out: "./migrations",
  dialect: "turso",
  dbCredentials: {
    url: process.env.TURSO_CONNECTION_URL ?? "",
    authToken: process.env.TURSO_AUTH_TOKEN ?? "",
  },
});

which fixed the issue.

Using drizzle with Astro

To use drizzle with Astro, I had to export a function in which I was passing the environment variables to the drizzle config. These are the files in question:

src/db/index.ts

import { drizzle } from "drizzle-orm/libsql";
import { createClient } from "@libsql/client";

export function createDB(env: App.Locals["env"]) {
  const client = createClient({
    url: env.TURSO_CONNECTION_URL,
    authToken: env.TURSO_AUTH_TOKEN,
  });

  return drizzle(client);
}

src/env.d.ts

/// <reference path="../.astro/types.d.ts" />

type Runtime = import("@astrojs/cloudflare").Runtime<Env>;

declare namespace App {
  interface Locals extends Runtime {
    env: {
      TURSO_CONNECTION_URL: string;
      TURSO_AUTH_TOKEN: string;
    };
  }
}

interface ImportMetaEnv {
  readonly TURSO_CONNECTION_URL: string;
  readonly TURSO_AUTH_TOKEN: string;
}

interface ImportMeta {
  readonly env: ImportMetaEnv;
}

src/pages/index.astro

---
import { createDB } from "../db";

const db = createDB(Astro.locals.env);
---

Preact compat was not working as expected with deck.gl

I followed the docs and installed the integration using pnpm astro add preact command. Docs also suggested on adding overrides for compat here. I followed the pnpm related docs and added this to my package.json

  "pnpm": {
    "overrides": {
        "react": "npm:@preact/compat@latest",
        "react-dom": "npm:@preact/compat@latest"
    }
  }

However, I ran into these errors

WARN Issues with peer dependencies found
.
├─┬ deck.gl 9.0.33
│ ├── ✕ missing peer react@npm:@preact/compat@latest
│ ├── ✕ missing peer react-dom@npm:@preact/compat@latest
│ └─┬ @deck.gl/react 9.0.33
│   ├── ✕ missing peer react@npm:@preact/compat@latest
│   └── ✕ missing peer react-dom@npm:@preact/compat@latest
├─┬ drizzle-orm 0.34.1
│ └── ✕ missing peer react@npm:@preact/compat@latest
└─┬ react-map-gl 7.1.7
  ├── ✕ missing peer react@npm:@preact/compat@latest
  └── ✕ missing peer react-dom@npm:@preact/compat@latest
✕ Conflicting peer dependencies:
  react      react-dom

I even tried installing react and react-dom which felt unnecessary but wanted to try it nonetheless. Still the issue persisted.

So what was the solution?

Removing the overrides altogether.

It builds on my machine but not on Cloudflare via GitHub 😔

Try as I may, if I deploy my app using wrangler deploy it used to work, however as soon as I was pushing anything to GitHub, the build used to fail. Reading through the logs and searching online, I figured out that Cloudflare was building my app using Node v18 and pnpm v8 while I was using Node v20 and pnpm v9.

Setting NODE_VERSION to 20.17.0 and PNPM_VERSION to 9.9.0 under Variables and Secrets in the dashboard fixed the build issue.

The website takes too long to load

As of this writing, the website takes about 10 seconds to load when loaded for the first time. I think this is due to the cold start of the Turso DB. One solution is to keep the DB "hot" by making API calls at certain intervals which I don't plan on doing. So I have yet to find an actual solution for this 🥲.

What's next?

Right now, I'm in the process of migrating to Cloudflare D1. Below are the D1 specific links:

D1 MapViz

flashblaze/map (D1 branch)

I will update this section once I have completely migrated and tested the app along with the challenges faced during migration as well, lol. I also need to work on a good CI/CD pipeline using GitHub Actions since the migrations are currently being run manually.

Publishing ESLint rules to npm using pnpm monorepo

Neeraj Lagwankar — Sat, 13 Jan 2024 12:44:39 +0000

Background

At work (Codebuddy), we wanted to create shareable ESLint rules to be used across the projects instead of copy pasting the rules each time. This can be achieved by following the Official shareable docs, but I wanted to outline how to achieve the same using a monorepo and also mention some issues which I faced along the way.

Creating packages

This setup has been inspired by antfu's eslint-config where he too has used a monorepo. Let us first begin by creating a pnpm workspace by creating these files

pnpm-workspace.yaml

packages:
 - "packages/*"

package.json

{
  "name": "your-eslint-configs",
  "version": "1.0.0",
  "description": "Common ESLint configs",
  "license": "MIT",
  "keywords": [
    "eslint",
    "eslint-config"
  ]
}

.npmrc

auto-install-peers=true
use-lockfile-v6=true

Then create a packages directory with all the necessary packages. For now we will be creating 2 packages: base and react:

base

index.js

module.exports = {
  env: {
    es2021: true,
    browser: true,
    node: true,
  },
  extends: [
    'eslint:recommended',
    'airbnb',
    'plugin:import/recommended',
    'plugin:promise/recommended',
    // This disables the formatting rules in ESLint that Prettier is going to be responsible for handling.
    // Make sure it's always the last config, so it gets the chance to override other configs.
    'plugin:prettier/recommended',
    'prettier',
  ],
  parserOptions: {
    ecmaVersion: 'latest',
    sourceType: 'module',
  },
  rules: {
    'prettier/prettier': [
      'error',
      {
        endOfLine: 'auto',
      },
    ],
    'max-len': 'off',
    'linebreak-style': ['error', 'unix'],
    quotes: ['error', 'single', { avoidEscape: true }],
    semi: ['error', 'always'],
    'object-curly-newline': 'off',
    'arrow-parens': 'off',
    'implicit-arrow-linebreak': 'off',
    'no-nested-ternary': 'off',
    'nonblock-statement-body-position': ['error', 'any'],
    camelcase: 'error',
    'consistent-return': 0,
    'no-restricted-syntax': 'off',
    'no-console': ['error', { allow: ['warn', 'error'] }],
    'arrow-body-style': ['error', 'as-needed'],
    'no-unused-vars': [
      'error',
      {
        argsIgnorePattern: '^_',
        varsIgnorePattern: '^_',
        caughtErrorsIgnorePattern: '^_',
      },
    ],
    'no-shadow': 'error',
    'no-underscore-dangle': 'off',
  },
};

package.json

{
  "name": "@your-org/eslint-config-base",
  "version": "1.0.0",
  "description": "Common JS ESLint rules",
  "license": "MIT",
  "main": "index.js",
  "keywords": [
    "eslint",
    "eslint-config"
  ],
  "peerDependencies": {
    "eslint": ">=8",
    "eslint-config-airbnb": ">=19.0.4",
    "eslint-plugin-import": ">=2.29.1",
    "eslint-plugin-prettier": ">=5.1.2",
    "eslint-plugin-promise": ">=6.1.1"
  },
  "engines": {
    "node": ">=18"
  }
}

If you check the name field, we're scoping it to an org name.

After installing the packages by running pnpm i from the root of the directory, below is the directory structure:

node_modules
packages/
└── base/
    ├── index.js
    └── package.json
.npmrc
package.json
pnpm-lock.json
pnpm-workspace.yaml

Use the above base into react package:

react

index.js

module.exports = {
  extends: [
    'plugin:react/recommended',
    'plugin:jsx-a11y/recommended',
    '@your-org/eslint-config-base',
  ],
  parserOptions: {
    ecmaFeatures: {
      jsx: true,
    },
    ecmaVersion: 'latest',
    sourceType: 'module',
  },
  plugins: ['react'],
  rules: {
    'react/function-component-definition': [
      2,
      {
        namedComponents: 'arrow-function',
        unnamedComponents: 'arrow-function',
      },
    ],
    'react/prop-types': 'off',
    'react/no-unstable-nested-components': 'off',
    'react/react-in-jsx-scope': 'off',
    'react/require-default-props': 'off',
    'react/jsx-props-no-spreading': 'off',
    'import/no-extraneous-dependencies': ['error', { devDependencies: ['vite.config.js'] }],
  },
};

In the extends array, put the config at the last so that it overrides the rules. If you have included a plugin in an earlier config, do not include it in the plugins array else, it will cause issues while linting.

To use @your-org/eslint-config-base, add it as a dependency. To do so, go into packages/react and run pnpm add @your-org/eslint-config-base. This will automatically install the package from the workspace. Below is the package.json:

react/package.json

{
  "name": "@your-org/eslint-config-react",
  "version": "1.0.0",
  "description": "Common ESLint rules for React with Vite",
  "license": "MIT",
  "main": "index.js",
  "keywords": [
    "eslint",
    "eslint-config"
  ],
  "peerDependencies": {
    "eslint": ">=8",
    "eslint-plugin-jsx-a11y": ">=6.8.0",
    "eslint-plugin-react": ">=7.33.2"
  },
  "engines": {
    "node": ">=18"
  },
  "dependencies": {
    "@your-org/eslint-config-base": "workspace:^"    
  }
}

And the updated directory structure:

node_modules
packages/
├── base/
│   ├── index.js
│   └── package.json
└── react/
    ├── index.js
    └── package.json
.npmrc
package.json
pnpm-lock.json
pnpm-workspace.yaml

Using the packages in a project to test it

Now that the configs are created, next step would be to use them in a project and see whether they are working or not. To do so, create a Vite project with React template. To link the package, check the commands here or follow the below commands.

Go into the created project, and run pnpm add -D <path-to-your-directory>/packages/react to install it from the packages dir.
Add it to .eslintrc.js like so:

.eslintrc.js

module.exports = {
  extends: ['@your-org/eslint-config-react'],
};

Publishing the packages

To publish the packages, go into each package and run pnpm publish --access public . If everything is set up correctly, then it will be published 🥳. Below are some issues which I faced while publishing. Do check if you run into any of the issues

I tried running npm adduser and npm login, however I got these errors

> npm login
npm notice Log in on https://registry.npmjs.org/
Login at:
https://www.npmjs.com/login?next=/login/cli/c2db3009-70e8-41ea-9194-04abd03d7c5c
Press ENTER to open in the browser...
npm ERR! code ERR_INVALID_ARG_TYPE
npm ERR! The "file" argument must be of type string. Received undefined
npm ERR! Cannot read properties of undefined (reading 'stdin')

npm ERR! A complete log of this run can be found in:
npm ERR!     /home/neeraj/.npm/_logs/2023-12-11T16_39_39_060Z-debug-0.log

Fortunately I found this Solution. Check if .npmrc exists if it exsist, then add the below line to it else create it and add the below line to it:

//registry.npmjs.org/:_authToken=token_here

If you want to see how Codebuddy has implemented the same for Next.js and TypeScript, do check it out on GitHub

Migrating my website from Gatsby to Astro

Neeraj Lagwankar — Fri, 25 Nov 2022 17:46:38 +0000

Background

The year was 2019 and I wanted to build a website using React. I had some experience in it, having done a project during my 3rd year of engineering but I wanted my site to be SEO friendly, fast, have client side navigation and good DX.

So after researching, I found two frameworks which fit my bill perfectly: Gatsby and Next.js. I wasn't going to call any APIs and my content was all going to be static so I did not need any SSR solution. And since Gatsby had excellent plugin support I decided to go with it.

Gatsby: The Chosen One

Being a new and a favourite framework amongst the developers there was no shortage of resources. As I was going for writing blog posts (which admittedly I did less of) I followed this tutorial by Andrew Mead:

After some tries and moving from one library to another for rendering some 3D stuff and animating pixels, my site was up and running at https://old.flashblaze.xyz which was https://flashblaze.xyz initially.

The tech stack I used was:

You can find the repo on GitHub and "peruse" through code.

Due to it being a popular framework built with first class plugin support, there was no shortage of 1st party as well as 3rd party plugins. Want to integrate Google Analytics? There is a plugin for it. Want to lazy load images with blur and have different sizes for mobile, desktop and other screen sizes? There is a plugin for it. Want to integrate it with a CMS of your choice? There is a plugin for it.

You get the picture.

Since I was going to write blog posts using MDX, needed good SEO, along with PWA (why not) and with the above mentioned stack, I needed a lot of plugins and by lot I mean A LOT.

Here is my package.json

{
  "name": "flashblaze-website",
  "private": true,
  "description": "Personal website of Neeraj Lagwankar",
  "version": "1.0.0",
  "author": "Neeraj Lagwankar <neerajlagwankar@gmail.com>",
  "scripts": {
    "build": "gatsby build",
    "develop": "env-cmd -f .env.development gatsby develop -H 0.0.0.0",
    "format": "prettier --write \"**/*.{js,jsx,json,md,mdx}\"",
    "lint": "npm run format && eslint --fix . && echo 'Lint complete.'",
    "start": "npm run develop",
    "serve": "npm run build && gatsby serve",
    "clean": "gatsby clean"
  },
  "dependencies": {
    "@mdx-js/mdx": "^1.6.22",
    "@mdx-js/react": "^1.6.22",
    "@supabase/supabase-js": "^1.21.1",
    "gatsby": "^3.11.1",
    "gatsby-plugin-google-analytics": "^3.11.0",
    "gatsby-plugin-google-fonts-v2": "^1.0.0",
    "gatsby-plugin-manifest": "^3.11.0",
    "gatsby-plugin-mdx": "^2.11.0",
    "gatsby-plugin-offline": "^4.11.0",
    "gatsby-plugin-preact": "^5.11.0",
    "gatsby-plugin-react-helmet": "^4.11.0",
    "gatsby-plugin-remove-serviceworker": "^1.0.0",
    "gatsby-plugin-sharp": "^3.11.0",
    "gatsby-plugin-sitemap": "^4.7.0",
    "gatsby-plugin-theme-ui": "^0.10.1",
    "gatsby-plugin-typography": "^3.11.0",
    "gatsby-remark-autolink-headers": "^4.8.0",
    "gatsby-remark-images": "^5.8.0",
    "gatsby-remark-prismjs": "^5.8.0",
    "gatsby-remark-relative-images": "^2.0.2",
    "gatsby-source-filesystem": "^3.11.0",
    "preact": "^10.5.14",
    "preact-render-to-string": "^5.1.19",
    "prismjs": "^1.24.1",
    "react": "^17.0.2",
    "react-dom": "^17.0.2",
    "react-helmet": "^6.1.0",
    "react-icons": "^4.2.0",
    "react-player": "^2.9.0",
    "react-spring": "^9.2.4",
    "react-typography": "^0.16.20",
    "remark-emoji": "^2.2.0",
    "theme-ui": "^0.10.0",
    "typography": "^0.16.21"
  },
  "devDependencies": {
    "babel-eslint": "^10.1.0",
    "env-cmd": "^10.1.0",
    "eslint": "^7.32.0",
    "eslint-config-prettier": "^8.3.0",
    "eslint-plugin-prettier": "^3.4.0",
    "prettier": "^2.3.2"
  },
  "keywords": ["gatsby", "portfolio", "flashblaze"],
  "repository": {
    "type": "git",
    "url": "https://github.com/flashblaze/flashblaze-website"
  },
  "bugs": {
    "url": "https://github.com/flashblaze/flashblaze-website/issues"
  }
}

Having this huge repository of plugins made me try different tools and libraries and integrate whatever I wanted and it just worked™.

But a storm was coming 🌪

Signs of trouble

Both the frameworks were adding features and I too was churning out a post per month (for now). I was fiddling around with my site regarding which analytics to use, trying out Preact, and some minor fixes here and there.

Then Gatsby v4 was released.

It introduced new features like DSG, SSR, along with a couple of performance improvements. Seeing a major version and looking at the features I wanted to upgrade as well. Since a lot of plugins are dependent on Gatsby's API they also had a comprehensive upgrade guide.

The thing was, most of my plugins were unmaintained, or they recommended alternate plugins which did not have full feature set. So I thought why not wait a couple of months and see what happens.

And so I waited.

After approximately 3-4 months I again looked at the plugins and oh boy were things changed! The plugins, the dependencies all were updated by major versions and some of required a full rewrite of my site. I don't remember exactly but I believe theme-ui was one of them (on which my whole site was basically built on). I tried updating my dependencies one by one, but it did not work and that's probably on me, but I was just plain tired of checking the docs of each dependency, see the migration path and do it all over again.

After spending countless hours and making no significant progress with it, I saw no point in spending more time on it. Add to that the enormous build times on my local machine (I had to build locally a few times due to it being a SSG framework and I wanted to see whether it would break on Vercel or not as it had happened a few times before), as well as on Vercel I just let it be.

Astro has entered the chat

During all this time another JS framework was being developed called Astro. Astro claimed to ship zero JavaScript, 1st class MD/MDX support, great 1st party plugins and to top it all off, allowed you to choose framework of your choice on a per page/per component basis. That's right. You can import a React, Vue, Svelte or any of the supported frameworks all in a single Astro component and it would just work™!

I was beyond impressed with these features and I was keeping a close eye on when Astro will ship v1.0. And it was released on 9th Aug 2022.

Since I was developing my website from scratch I discarded the old design and redesigned it to make it look decent with minimal JS. And so I pushed my 1st commit on 14th Aug 2022

Current tech stack

Instead of some UI framework/styling solution which was specifically tailored for React, I went with Tailwind CSS. It is hugely popular, has good support for almost all the frameworks, is a 1st party plugin from Astro and was great to get started with. For my posts I chose MDX and for components in MDX I chose React.

Here is my package.json. As you can see, it is pretty minimal as opposed to the earlier one all thanks to the things which Astro provides out of the box along with some of the libraries which I chose to forgo due to change in requirements.

{
  "name": "flashblaze-website",
  "version": "1.0.0",
  "private": true,
  "scripts": {
    "dev": "astro dev",
    "start": "astro dev",
    "build": "astro build",
    "preview": "astro preview"
  },
  "devDependencies": {
    "@astrojs/image": "^0.11.6",
    "@astrojs/mdx": "^0.12.0",
    "@astrojs/react": "^1.2.2",
    "@astrojs/sitemap": "^1.0.0",
    "@astrojs/tailwind": "^2.1.3",
    "@fontsource/jetbrains-mono": "^4.5.11",
    "@fontsource/montserrat": "^4.5.13",
    "@tailwindcss/typography": "^0.5.8",
    "astro": "^1.6.11",
    "eslint": "^8.28.0",
    "eslint-config-prettier": "^8.5.0",
    "eslint-plugin-prettier": "^4.2.1",
    "instagram-private-api": "^1.45.3",
    "prettier": "^2.8.0",
    "prettier-plugin-astro": "^0.7.0",
    "react": "^18.2.0",
    "react-dom": "^18.2.0"
  },
  "dependencies": {
    "@jsdevtools/rehype-toc": "^3.0.2",
    "@swup/gtm-plugin": "^1.0.2",
    "@swup/head-plugin": "^1.2.1",
    "@swup/scripts-plugin": "^1.1.0",
    "react-icons": "^4.6.0",
    "react-player": "^2.11.0",
    "rehype-autolink-headings": "^6.1.1",
    "rehype-slug": "^5.1.0",
    "remark-autolink-headings": "^7.0.1",
    "remark-gfm": "^3.0.1",
    "remark-slug": "^7.0.1",
    "remark-toc": "^8.0.1",
    "swup": "^2.0.19",
    "tailwindcss": "^3.2.4"
  }
}

The build times also improved by quite a margin.

But all said and done, Astro too is not perfect and here are some of the Pros and Cons which I found while working with it.

Pros and cons of Astro

Pros

HTML 1st framework
- Any component you write which needs to be interactive, you specifically have to enable client side JavaScript which sort of makes you think whether you actually need this part to be interactive or not.
Multi framework support
Good plugin support
Easy access to files directory without needing a custom config file
- While this might have changed in the recent versions of Gatsby, the version of Gatsby which I used needed to create a gatsby-node.js file to access the file system. Along with that since Gatsby is GraphQL 1st, I had to access the parsed file using GraphQL which you can find here.
- In Astro I don't have to do any of it, and all my files are available using this single 1 line command const posts = await Astro.glob('../../content/*.mdx'); which is just amazing!
Good Image components for generating images for various sizes with AVIF support for supported browsers
Friendly community in Discord with constant discussion around various topics

Cons

No client side routing
- Like Gatsby or Next, Astro does not have any client side navigation. So each link click triggers a full page reload. Astro recommends to use Swup as mentioned here. Turbo is also another option though the team does not recommend it. I'm currently using Swup which I'll probably switch from or completely remove it as I have added TOC to MDX and clicking on a title is not redirecting the page to that particular section.
Partial HMR
- Only *.astro files support HMR. So if you're editing MDX or a separate component, you're out of luck.
Partial compatibility with React libraries
- Some CSS-in-JS libraries are not supported: #4432 and I believe it can be said for some Context based UI libraries or some state management libraries as well. Although for state management Astro recommends to use Nano Stores
No blurhash for images like Next or Gatsby

The end?

For now, yeah. I'm quite happy with the current setup and who knows, instead of switching to another framework and then writing a post on it, I might just write one for the heck of it.

SVG Animations in React using react-spring

Neeraj Lagwankar — Mon, 15 Jun 2020 15:33:36 +0000

Introduction

Animations are an important part of a website, and when implemented correctly, they deliver a good user experience.
Although there are some animation libraries which work with React, we are going to take a look at react-spring a great animation library which is based on physics (yes you read that right) instead of durations.

The need for this post arose when I tried to animate an svg using react-spring but I could not find a good resource from start to finish. Although react-spring documents on animating an svg, implementing it as is will not work as a number of parameters required such as svg path length, stroke dash array, etc are not mentioned.

So, let us begin!

Setup

Begin by typing

npx create-react-app react-spring-demo

in your terminal. Go inside the created project and install react-spring by typing npm install --save react-spring

Type

npm run start

in terminal to start the React app.

Go to http://localhost:3000 to view the running app.

Go to src directory and create a new file Animation.js which will contain the animation code.

Remove everything from App.js and import Animation.js. Inside Animation.js type a simple hello world program as a placeholder.

Below is App.js

// App.js
import React from 'react';
import Animation from './Animation';

const App = () => {
  return (
    <div>
      <Animation />
    </div>
  );
};

export default App;

Below is Animation.js

//Animation.js
import React from 'react';

const Animation = () => {
  return <h1>Hello World!</h1>;
};

export default Animation;

Animation

Replace the code in Animation.js by the following code

// Animation.js
import React, { useEffect, useRef } from 'react';

const Animation = () => {
  const pathRef = useRef();

  useEffect(() => {
    console.log(pathRef.current.getTotalLength());
  }, []);

  return (
    <div>
      <svg>
        <circle
          strokeWidth="3"
          cx="100"
          cy="50"
          r="40"
          stroke="black"
          fill="none"
          ref={pathRef}
        />
      </svg>
    </div>
  );
};

export default Animation;

To animate an svg, you need the path length of it. css-tricks explains on how to achieve this using HTML, CSS and vanilla JavaScript which I translated to React.

To get the path length, you'll need a reference to the path which is achieved through useRef hook which is used to reference the DOM or React element. getTotalLength() gives us the total length.

useEffect hook is used to get the length of the svg path as soon as the component is mounted.

You can either note down the length from browser console and then use it in useState or you can render an invisible svg temporarily and render the final svg on setting the offset value. I'm going to follow second method as I won't have to constantly check console.log() whenever I change the svg.

Move the shape already!

Yeah yeah. Now the fun part of animating the circle

Copy the following code in Animation.js

// Animation.js
import React, { useEffect, useState, useRef } from 'react';
import { Spring } from 'react-spring/renderprops';

const Animation = () => {
  const pathRef = useRef();
  const [offset, setOffset] = useState(null);

  useEffect(() => {
    setOffset(pathRef.current.getTotalLength());
  }, [offset]);

  return (
    <div>
      {offset ? (
        <Spring from={{ x: offset }} to={{ x: 0 }}>
          {(props) => (
            <svg>
              <circle
                strokeDashoffset={props.x}
                strokeDasharray={offset}
                strokeWidth="3"
                cx="100"
                cy="50"
                r="40"
                stroke="black"
                fill="none"
                ref={pathRef}
              />
            </svg>
          )}
        </Spring>
      ) : (
        <svg>
          <circle
            strokeWidth="3"
            cx="100"
            cy="50"
            r="40"
            stroke="none"
            fill="none"
            ref={pathRef}
          />
        </svg>
      )}
    </div>
  );
};

export default Animation;

To create the animation of circle being completed from length 0 to full length, we need its length which is stored in offset.

Initially, when the component is loaded the offset value is null. To get the length, we need the svg. As we do not need to display it, stroke is set to none. As soon as offset value is set, we display the svg and animate it.

Spring renderprop is used to move data from one state to another. strokeDasharraydefines the length of dashes to display in our svg. Since we want the complete circle, its value should be the length of the circle i.e. offset.

strokeDashoffset sets the offset value which moves the position of the dashes. Now we animate it from its offset value to 0 so it looks like the circle is being drawn.

You can also configure various parameters like friction, tension, precision, etc. The complete list can be found here

This is the modified code which shows what changing some values does

// Animation.js
import React, { useEffect, useState, useRef } from 'react';
import { Spring } from 'react-spring/renderprops';

const Animation = () => {
  const pathRef = useRef();
  const [offset, setOffset] = useState(null);

  useEffect(() => {
    setOffset(pathRef.current.getTotalLength());
  }, [offset]);

  return (
    <div>
      {offset ? (
        <Spring
          from={{ x: offset }}
          to={{ x: 0 }}
          config={{ tension: 4, friction: 0.5, precision: 0.1 }}
        >
          {(props) => (
            <svg>
              <circle
                strokeDashoffset={props.x}
                strokeDasharray={offset}
                strokeWidth="3"
                cx="100"
                cy="50"
                r="40"
                stroke="black"
                fill="none"
                ref={pathRef}
              />
            </svg>
          )}
        </Spring>
      ) : (
        <svg>
          <circle
            strokeWidth="3"
            cx="100"
            cy="50"
            r="40"
            stroke="none"
            fill="none"
            ref={pathRef}
          />
        </svg>
      )}
    </div>
  );
};

export default Animation;

Conclusion

react-spring is an amazing animation library which is based on physics and gives amazing results based on actual physical properties. You can similarly animate opacity, change colours, etc. and have a blast with it.

You can view the complete project on GitHub

Displaying Real-Time Views using React, Gatsby and Firebase

Neeraj Lagwankar — Tue, 07 Apr 2020 15:55:18 +0000

This post is my take on displaying real-time views using Firebase and React. This has previously been done by Guillermo Rauch on rauchg.com and Lee Robinson on leerob.io.
Lee also explains how he did this in his blog.

So why should you read my post if they have already done so and even explained it? The reason being, both of the implementations require some sort of node environment to execute code while my post shows how you can achieve it on the client-side.

Another reason being, both websites are using Nextjs while mine is using Gatsbyjs and I couldn't find anything related to it. So here we are.

Setup

Setting up Firebase

Sign in to Firebase and go to console and create a new project. I'll name mine react-gatsby-views. You can enable Google Analytics if you want and click on create project

Navigate to Develop -> Database and click on "Create Database"
Choose "Start in Test Mode"

Choose your location and click on "Done"
Click on "Project Settings".

Click on web icon to create a "Web App"

Enter your name, I'll name mine react-gatsby-views-app do not enable Firebase hosting and click on "Register app"

Click on "Continue to console" as we'll need the config object later

Go to "Database" and select "Realtime Database"

Go to "Rules" and set read, write to true and click on "Publish" allowing us to update data without sigining in and using the config object

Setting up Gatsby

Create a Gatsby project by typing npx gatsby new enter_project_name in your terminal.
Go inside the created directory and install gatsby-firebase-plugin and firebase by typing npm install firebase gatsby-plugin-firebase in your terminal.
Register the Gatsby plugin by adding the below lines to your gatsby-config.js file

module.exports = {
  plugins: [
    ...otherPlugins,

    {
      resolve: 'gatsby-plugin-firebase',
      options: {
        credentials: {
          apiKey: '<YOUR_FIREBASE_API_KEY>',
          authDomain: '<YOUR_FIREBASE_AUTH_DOMAIN>',
          databaseURL: '<YOUR_FIREBASE_DATABASE_URL>',
          projectId: '<YOUR_FIREBASE_PROJECT_ID>',
          storageBucket: '<YOUR_FIREBASE_STORAGE_BUCKET>',
          messagingSenderId: '<YOUR_FIREBASE_MESSAGING_SENDER_ID>',
          appId: '<YOUR_FIREBASE_APP_ID>',
        },
      },
    },
  ],
};

you can refer the documentation here.

Since we are using Realtime Database, add import "firebase/database" to gatsby-browser.js and gatsby-ssr.js files.

// gatsby-browser.js and gatsby-ssr.js
import 'firebase/database';

Integration

Go to your Firbase console and select your web app.

Scroll down to Your apps and and copy the firebaseConfig object.

Create an .env file at the root of your project and paste the content like so

API_KEY='your_values_here'
AUTH_DOMAIN='your_values_here'
DATABASE_URL='your_values_here'
PROJECT_ID='your_values_here'
STORAGE_BUCKET='your_values_here'
MESSAGING_SENDER_ID='your_values_here'
APP_ID='your_values_here'
MEASUREMENT_ID='your_values_here'

Edit the gatsby-config.js file to consume the environment variables

    {
      resolve: 'gatsby-plugin-firebase',
      options: {
        credentials: {
          apiKey: process.env.API_KEY,
          authDomain: process.env.AUTH_DOMAIN,
          databaseURL: process.env.DATABASE_URL,
          projectId: process.env.PROJECT_ID,
          storageBucket: process.env.STORAGE_BUCKET,
          messagingSenderId: process.env.MESSAGING_SENDER_ID,
          appId: process.env.APP_ID,
        },
      },
    },

Install env-cmd as a dev dependency to use the environment variables by typing npm i -D env-cmd
Modify "develop" command in package.json to env-cmd -f .env gatsby develop
Add the below code to gatsby-config.js

require("dotenv").config({
  path: `.env.${process.env.NODE_ENV}`,
})
module.exports = {
  ...
}

Implementation

Go to src/pages/ and remove the unnecessary content with a simple one

// index.js
import React from 'react';
import ViewCounter from '../components/ViewCounter';

const Index = () => (
  <div>
    <ViewCounter id="index" />
  </div>
);

export default Index;

Don't worry if you get an error

we'll create the ViewCounter component in just a minute.

Create directory lib under src and a file named increment-views.js in it. It should look like this

src
 |-lib
    |-increment-views.js

Copy the below code into the file

// increment-views.js
import firebase from 'gatsby-plugin-firebase';

const incrementViews = async (id) => {
  const ref = firebase.database().ref(`/views`).child(id);

  ref.transaction((currentViews) => {
    return currentViews + 1;
  });
};

export default incrementViews;

This basically creates a reference of database to and creates an entry of id under views. Different ids will create additional entries and will update the view whenever the function is called.

ref.transaction() is used to modify the data at the location. In our case views of id are incremented.

Create a file ViewCounter.js under src/components/ and copy the below code

// ViewCounter.js
import React, { useEffect, useState } from 'react';
import firebase from 'gatsby-plugin-firebase';
import incrementViews from '../lib/increment-views';

const ViewCounter = ({ id }) => {
  const [viewCount, setViewCount] = useState('');

  useEffect(() => {
    // 1 is displayed for a split second and then the correct count
    // This is a workaround
    const onViews = (newViews) => {
      setViewCount(newViews.val() === 1 ? 0 : newViews.val());
    };

    incrementViews(id);

    firebase.database().ref(`/views`).child(id).on(`value`, onViews);

    return () => {
      if (firebase.database()) {
        firebase.database().ref(`/views`).child(id).off(`value`, onViews);
      }
    };
  }, [id]);

  return (
    <div style={{ color: '#7e7e7e' }}>
      {viewCount ? viewCount : `---`} views
    </div>
  );
};

export default ViewCounter;

On loading this component, id is sent to increment-views to increment the value and the returned value is stored in viewCount.

Upon completion, if an instance of database exists, detach it using off()

Now everytime you refresh the page or anyone visits it, view count will be incremented

App Views

Firebase Views

Deployment

Since I have deployed my site on Zeit, it uses now secrets. Each host provider has a different mechanism to handle environment variables.

I hope you've liked this post. Any suggestions, improvements are welcome.

Forem: Neeraj Lagwankar

Securing Vibe Coded Applications using Cloudflare Access

Background

Cloudflare Access to the rescue

Confguration

Creating a login method

Creating a policy

Securing the application

Using Cloudflare Durable Objects with SQL Storage, D1, and Drizzle ORM

Background

Project and environment setup

Project setup with Hono

Tokens and IDs

Account and D1 IDs

D1 token

Workers token

D1 setup

bun db:generate

bun db:migrate

bun db:studio

D1 deployment

DO setup

Config and class

Migrations and data entry

Test test test

DO deployment

Useful links

Migrating my Turso DB to Cloudflare D1

Background

Challenges

Making D1 work with drizzle and Astro

Turso dump was not working

D1 does not support importing data in the CSV format

Conclusion

Deploying my Astro + Turso + Drizzle project to Cloudflare Pages

Background

Tech stack

Skill issue

drizzle-kit: import.meta is not available

Using drizzle with Astro

Preact compat was not working as expected with deck.gl

It builds on my machine but not on Cloudflare via GitHub 😔

The website takes too long to load

What's next?

Publishing ESLint rules to npm using pnpm monorepo

Background

Creating packages

base

react

Using the packages in a project to test it

Publishing the packages

Migrating my website from Gatsby to Astro

Background

Gatsby: The Chosen One

Signs of trouble

Astro has entered the chat

Current tech stack

Pros and cons of Astro

Pros

Cons

The end?

SVG Animations in React using react-spring

Introduction

Setup

Animation

Move the shape already!

Conclusion

You can view the complete project on GitHub

Displaying Real-Time Views using React, Gatsby and Firebase

Setup

Setting up Firebase

Setting up Gatsby

Integration

Implementation

Deployment

You can view the complete project on GitHub

`bun db:generate`

`bun db:migrate`

`bun db:studio`

drizzle-kit: `import.meta` is not available