How I add a view counter in my blog post

Meet some issues when I implemented this feature. Let's see how I resolve them during development!

Published on June 26, 2024Last updated on January 11, 2025

10 min read

49 views

0 views

This website is built using Next and deployed with Vercel.

In February I refactored this website from Pages Router to App Router.

The blog post just some pages pre-rendered as static HTML using generateStaticParams.

There are many new things in Next.js and I never tried them. So I want to add a little feature in my blog to play around with Next.js.

A simple <ViewCounter /> component will do that!

What will <ViewCounter /> do?

When readers see the blog post there will be a little indicator showing how many times this post has been viewed and no matter how many times they refresh the post page, the view count will only be increased once per day. Quite simple huh?

Requirement

A place to persist data.
A rate limiter to limit the mutation for each IP address.

Let's do it

Why PostgreSQL?

We need a place to store the data. There are many different databases these days. SQLite, MongoDB, DuckDB... you name it!

The database I usually work with is MySQL. This blog is just a little toy I can play around so I like to try something different. PostgreSQL seems like a more popular choice in 2024 and you can use it for everything.

It's 2024. There are many providers out there and they offer free tiers.

Why Neon?

I don't know how much difference between them cause I have not used a service like this. But Koyeb¹ and Vercel² are partnered with Neon. Why don't I just use Neon directly?

Why Drizzle?

To prevent work with the database directly we need to choose an ORM to help us communicate the database.

There are tons of ORMs you can choose from.

Drizzle said they are fast🚀 which they are.

Although my website like almost zero visitors right now performance is not a thing I need to worry about.

But who cares. We like things going fast, right?

Why Upstash?

Upstash
Vercel KV

Vercel KV is partnered³ with Upstash. Vercel only provides 3,000 requests per day Upstash requests per day are up to 10,000.

Red pill and blue pill

Route handler

We can do it old-fashioned. Our little component sends a RESTful API to get the view count with an evil useEffect. Next.js allows us to create a request handler for the specific route which is handy.

We simply need two endpoints.

GET /api/v1/views/{slug}/count
POST /api/v1/views/{slug}/count

export const runtime = 'edge';

export async function GET(
  req: NextRequest,
  { params }: { params: { slug: string } },
) {
  const slug = params.slug;
  try {
    const result = await getViewCountBySlug(slug);
    return NextResponse.json(result, { status: 200 });
  } catch (error) {
    console.log(error);
    return NextResponse.json({ count: 0 }, { status: 200 });
  }
}

export async function POST(
  req: NextRequest,
  { params }: { params: { slug: string } },
) {
  const slug = params.slug;
  if (!slug) return new NextResponse('Slug not found', { status: 400 });
  const ip = getIpFromNextRequest(req);
  const ok = await redis.set(getIncrViewCountRateLimitKey(slug, ip), 1, {
    nx: true,
    ex: process.env.NODE_ENV === 'development' ? 10 : 24 * 60 * 60,
  });
  if (!ok) {
    return new NextResponse(null, { status: 202 });
  }
  await incrViewCountBySlug(slug, ip);
  return new NextResponse(null, { status: 200 });
}

Server component

I'm new to server component which I find quite interesting when I go through the Next.js documentation.

App Router comes with server component as default. It means every react component you write Next.js will treat it as server component unless you put use client on top of your file.

The component down below which I use in my /posts/{slug}/page.tsx file.

When I deploy to Vercel, it will become a serverless function when the user visits /posts/{slug} this route the page will be dynamically rendered.

export async function ViewCounter({ slug }: { slug: string }) {
  const ip = getIP();
  await incrViewCountBySlug(slug, ip);
  let count = 0;
  try {
    const entity = await getViewCountBySlug(slug);
    count = entity.count;
  } catch (error) {
    console.log('getViewCountBySlug error', error);
  }
  return <div>{count} views</div>;
}

This approach comes up with a benefit. I don't need to validate the slug if a blog post I have written.

My post is generated with generateStaticParams function. Users wgi visit the page not exist will be redirected to not-found page. <ViewCounter /> will not be mounted which means the view count will not be increased.

The implementation with a route handler is not safe if the user knows the endpoint. There will be some dirty data in our database when the user sends a request like curl -X POST /api/v1/views/3.1415926/count. If we use the route handler approach we need to validate the slug if correct.

The problem in local development

The whole website is serverless, I don't own any EC2 or VPS instance. When it comes to local development, I encounter some issues.

The library they provide is not for local development. Take an example when I try to insert a new row in Postgres.

When we use ORM to talk to our database we need to tell the ORM which database we want it connect.

The URL will look like this postgres://username:password@hostname:port/database

But the library Neon provides we can't use it in local development with Drizzle. Cause it design for serverless

There are two ways we can test in development.

Alias

We can use an alias to map our actual db execution to another(node-postgres).

We got a single db export from /src/db/index.ts

import { neon } from '@neondatabase/serverless';
import { drizzle } from 'drizzle-orm/neon-http';

export const db = drizzle(neon(`${process.env.DATABASE_URL}`));

The db object is what we use everywhere to interact with our database.

We leverage alias to map our db object from /src/db/index.ts to /src/db/dev.ts.

First, we need to new a tsconfig.dev.json which extends our production tsconfig.json

{
  "extends": "./tsconfig.json",
  "compilerOptions": {
    "paths": {
      "@/*": ["./src/*"],
      "@/db": ["./src/db/dev"]
    }
  }
}

Second, we need to change our next.config.js

const nextConfig = {
  pageExtensions: ['js', 'jsx', 'mdx', 'ts', 'tsx'],
  experimental: {
    ppr: true,
  },
  typescript: {
    tsconfigPath:
      process.env.NODE_ENV === 'development'
        ? './tsconfig.dev.json'
        : './tsconfig.json',
  },
};

Create a new /src/db/dev.ts

import { Pool } from 'pg';
import { drizzle } from 'drizzle-orm/node-postgres';

export const db = drizzle(new Pool(), { logger: true });

Now we can interact with our database locally.

But this approach comes up with another problem when I try to implement the <ViewCounter /> feature with a route handler.

The route handler will be transformed into Function when you deploy Next.js application to Vercel which is served by their Edge Network.

There are two types of runtime we can choose, Node.js and Edge.

When I checked out the documentation they said Edge runtime is lightweight and distributed globally which means fast🚀.

Edge runtime has some limits that you can't use like fs module provided by Node.js.

export const runtime =
  process.env.NODE_ENV === 'development' ? 'nodejs' : 'edge';

export async function GET(
  req: NextRequest,
  { params }: { params: { slug: string } },
) {
  // ...
  return NextResponse.json({ count: 0 }, { status: 200 });
}

I'm a genius!

But when I deploy to Vercel things go sideways. It did not transform to Edge function.

Turns out it can't and there might be inconsistent behavior between two different environments. You might find out it works well in development but properly a potential bug in production. That will be a nightmare!

Proxy

Since the alias not working like I expected I started looking for another solution. Not just me meeting this kind of issue, right?

After I do some searching through the internet found out local-neon-http-proxy in a github issue.

Follow the README guide and done!

There is also a similar repository for Upstash local development.

If we use alias there will be hidden foot guns from the differences between development and production.

Drizzle error

ERROR: Transforming const to the configured target environment ("es5") is not supported yet

When I executed drizzle-kit generate I got the above message printed above.

It seems the default generated tsconfig.json by Next.js the target was set to es5 that's why.

{
  "compilerOptions": {
    "target": "es5",
    "lib": ["dom", "dom.iterable", "esnext"],
    "allowJs": true,
    "skipLibCheck": true,
    "strict": true,
    "noEmit": true,
    "esModuleInterop": true,
    "module": "esnext",
    "moduleResolution": "bundler",
    "resolveJsonModule": true,
    "isolatedModules": true,
    "jsx": "preserve",
    "incremental": true,
    "plugins": [
      {
        "name": "next"
      }
    ],
    "paths": {
      "@/*": ["./src/*"]
    }
  },
  "include": ["next-env.d.ts", "**/*.ts", "**/*.tsx", ".next/types/**/*.ts"],
  "exclude": ["node_modules"]
}

Set the target greater than es5 and you are good to go.

Or you can patch the drizzle-kit package to use your hard set value instead of your tsconfig file.

The package manager I use is pnpm which has a built-in patch feature.

Type pnpm patch drizzle-kit in your terminal and follow the instructions it will generate something similar like down below.

diff --git a/bin.cjs b/bin.cjs
index 03f8f91c39812ccbe439d02d020e73ef760e6f40..78d2bb1a457d2b4c35737dbbaa06cdf0e7c6deef 100755
--- a/bin.cjs
+++ b/bin.cjs
@@ -20041,7 +20041,7 @@ var require_node2 = __commonJS({
           sourcefile: filename,
           loader: getLoader(filename),
           sourcemap: "both",
-          target: options.target,
+          target: "es6",
           jsxFactory: options.jsxFactory,
           jsxFragment: options.jsxFragment,
           format: format2,

Migration

When you run the migration using drizzle kit all information about executed migrations will be stored in the database inside the __drizzle_migrations table inside the drizzle schema.

id	hash	created_at
1	some_random_hash	17188552321123

I'm curious about the hash column, cause the value 17188552321123 is in the created_at column I can find it in drizzle generated JSON file but the hash value I can't find where it comes from.

So I start looking into the repository, find out the hash are created from the *.sql file.

Compared to Sequelize it seems Sequelize migration is more flexible. They provide up and down inside the same file. So you can immediately undo the migration if you find out something goes wrong after running the migration.

But it seems in Drizzle you can't do something like this at least they do not offer this kind of feature.

A workaround is after you generate a new .sql file you rollback the change and generate another .sql file. So you don't have to write it manually at that time.

The end

That's it and happy coding🎉