DEV Community: Desmond Obisi

Testing Risky Postgres Migrations Safely with Volume Cloning on Unikraft Cloud

Desmond Obisi — Tue, 22 Sep 2026 00:49:00 +0000

Database migrations can pass every check in development and still take production down, and the classic example is adding a NOT NULL column with no default to a table that already has rows. It works fine against an empty dev database and fails instantly against real data, which is the one place you cannot afford to find that out.

This guide builds a real multi-tenant API backed by PostgreSQL on Unikraft Cloud, then clones the live database's persistent volume, runs that exact failure against a real copy, and only promotes the fix once it has actually succeeded somewhere disposable.

A note on terminology before we start. Unikraft Cloud ships a first-class instance branching feature (--branch): it snapshots a running instance's memory and volume state, is copy-on-write, and pauses the source for only a few milliseconds. It is currently limited to enterprise customers and requires a license that includes branching. This post deliberately uses the other, broadly available mechanism instead — cloning the database's persistent volume and booting a fresh Postgres instance against the clone — which works on the hosted platform today and needs no special license. When you read "clone" below, that is what it means.

Prerequisites

Before starting, you will need:

Go 1.25 or later
Docker with BuildKit enabled
The Unikraft CLI, with unikraft login completed, and a Unikraft Cloud account
psql installed locally for verification
github.com/jackc/pgx/v5 and github.com/pressly/goose/v3 as your Postgres driver and migration tool, both fetched via go get

Building the app

ALTER TABLE notes ADD COLUMN priority INT NOT NULL; is the migration that makes this whole exercise worth doing. Postgres needs a value for every existing row the moment that column becomes NOT NULL, and with no default supplied, it has nothing to backfill with. Against an empty table, there is nothing to fail on, so the migration passes in a fresh local database and in most CI pipelines.

Against a populated table, it fails immediately, and the only way to know that in advance is to run it against data that actually looks like production. Staging databases drift, a pg_dump/restore cycle is slow and doubles your storage cost for the duration, and running the untested migration directly against production is the outcome this whole article exists to avoid.

Setting up the project

The repository is a small Go module with three entrypoints and a clear separation between the API and its supporting tooling:

pg-branching-unikraft/
├── cmd/
│   ├── api/       # the notes API server, deployed to Unikraft Cloud
│   ├── seed/       # seeds realistic, uneven multi-tenant data
│   └── migrate/    # applies the embedded goose migrations to DATABASE_URL
├── internal/
│   ├── db/          # pgx connection pool setup
│   └── api/         # HTTP handlers and router
├── migrations/       # 00001_init.sql, 00002_add_priority.sql (the fixed version that ships)
├── broken/           # the failing version of 00002, quarantined here on purpose
├── Dockerfile
├── Kraftfile
└── go.mod

go get github.com/jackc/pgx/v5 resolved to v5.10.0, and go get github.com/pressly/goose/v3 resolved to v3.27.2. Goose was chosen specifically because it keeps migrations as individual, ordered SQL files.

The schema and the API

The schema is deliberately simple, since the point of this project is the volume-cloning workflow around it, not the data model itself:

-- 00001_init.sql
CREATE TABLE tenants (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    name TEXT NOT NULL,
    created_at TIMESTAMPTZ NOT NULL DEFAULT now()
);

CREATE TABLE notes (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    tenant_id UUID NOT NULL REFERENCES tenants(id),
    title TEXT NOT NULL,
    body TEXT NOT NULL,
    created_at TIMESTAMPTZ NOT NULL DEFAULT now()
);

CREATE INDEX idx_notes_tenant_id ON notes(tenant_id);

gen_random_uuid() is built directly into PostgreSQL 13 and later, so there is no pgcrypto extension to enable here. It is easy to carry a CREATE EXTENSION pgcrypto line over out of habit from an older project, and the custom Postgres image used in this deployment does not ship that extension at all, so leaving that line in would break the very first migration.

The connection pool is thin, a single function reading DATABASE_URL and handing back a pgxpool.Pool:

package db

import (
    "context"
    "errors"
    "os"

    "github.com/jackc/pgx/v5/pgxpool"
)

// ErrNoDSN is returned when DATABASE_URL is not set.
var ErrNoDSN = errors.New("DATABASE_URL is not set")

// Pool creates a pgx connection pool from the DATABASE_URL environment variable.
// The DSN must include TLS settings appropriate for the Unikraft Cloud Postgres
// FQDN (sslmode=require), e.g.:
//
//  postgres://postgres:<pw>@<fqdn>:5432/postgres?sslmode=require
func Pool(ctx context.Context) (*pgxpool.Pool, error) {
    dsn := os.Getenv("DATABASE_URL")
    if dsn == "" {
        return nil, ErrNoDSN
    }
    return pgxpool.New(ctx, dsn)
}

The entrypoint just wires that pool into an HTTP server:

package main

import (
    "context"
    "log"
    "net/http"
    "os"

    "pg-branching-unikraft/internal/api"
    "pg-branching-unikraft/internal/db"
)

func main() {
    ctx := context.Background()

    pool, err := db.Pool(ctx)
    if err != nil {
        log.Fatalf("db: %v", err)
    }
    defer pool.Close()

    port := os.Getenv("PORT")
    if port == "" {
        port = "8080"
    }
    addr := "0.0.0.0:" + port

    log.Printf("notes API listening on %s", addr)
    if err := http.ListenAndServe(addr, api.Router(&api.Handlers{Pool: pool})); err != nil {
        log.Fatalf("server error: %v", err)
    }
}

Routing uses Go 1.22's method-and-pattern matching directly on http.ServeMux, so there's no router dependency to pull in for four endpoints:

package api

import "net/http"

// Router wires the notes API routes using Go 1.22+ method+pattern routing.
func Router(h *Handlers) http.Handler {
    mux := http.NewServeMux()
    mux.HandleFunc("GET /healthz", h.Healthz)
    mux.HandleFunc("POST /tenants", h.CreateTenant)
    mux.HandleFunc("POST /tenants/{tenant_id}/notes", h.CreateNote)
    mux.HandleFunc("GET /tenants/{tenant_id}/notes", h.ListNotes)
    return mux
}

And the four handlers themselves:

package api

import (
    "encoding/json"
    "errors"
    "net/http"
    "strings"
    "time"

    "github.com/jackc/pgx/v5"
    "github.com/jackc/pgx/v5/pgxpool"
)

// Handlers holds the dependencies for the HTTP handlers.
type Handlers struct {
    Pool *pgxpool.Pool
}

type Tenant struct {
    ID        string    `json:"id"`
    Name      string    `json:"name"`
    CreatedAt time.Time `json:"created_at"`
}

type Note struct {
    ID        string    `json:"id"`
    TenantID  string    `json:"tenant_id"`
    Title     string    `json:"title"`
    Body      string    `json:"body"`
    CreatedAt time.Time `json:"created_at"`
}

func writeJSON(w http.ResponseWriter, status int, v any) {
    w.Header().Set("Content-Type", "application/json")
    w.WriteHeader(status)
    _ = json.NewEncoder(w).Encode(v)
}

func writeError(w http.ResponseWriter, status int, msg string) {
    writeJSON(w, status, map[string]string{"error": msg})
}

// Healthz reports 200 when the database connection is alive. Also used to
// confirm scale-to-zero wake-up.
func (h *Handlers) Healthz(w http.ResponseWriter, r *http.Request) {
    if err := h.Pool.Ping(r.Context()); err != nil {
        writeError(w, http.StatusServiceUnavailable, "database unavailable: "+err.Error())
        return
    }
    writeJSON(w, http.StatusOK, map[string]string{"status": "ok"})
}

func (h *Handlers) CreateTenant(w http.ResponseWriter, r *http.Request) {
    var in struct {
        Name string `json:"name"`
    }
    if err := json.NewDecoder(r.Body).Decode(&in); err != nil {
        writeError(w, http.StatusBadRequest, "invalid JSON body")
        return
    }
    if strings.TrimSpace(in.Name) == "" {
        writeError(w, http.StatusBadRequest, "name is required")
        return
    }

    var t Tenant
    err := h.Pool.QueryRow(r.Context(),
        `INSERT INTO tenants (name) VALUES ($1) RETURNING id::text, name, created_at`,
        in.Name,
    ).Scan(&t.ID, &t.Name, &t.CreatedAt)
    if err != nil {
        writeError(w, http.StatusInternalServerError, "failed to create tenant: "+err.Error())
        return
    }
    writeJSON(w, http.StatusCreated, t)
}

func (h *Handlers) CreateNote(w http.ResponseWriter, r *http.Request) {
    tenantID := r.PathValue("tenant_id")
    var in struct {
        Title string `json:"title"`
        Body  string `json:"body"`
    }
    if err := json.NewDecoder(r.Body).Decode(&in); err != nil {
        writeError(w, http.StatusBadRequest, "invalid JSON body")
        return
    }
    if strings.TrimSpace(in.Title) == "" || strings.TrimSpace(in.Body) == "" {
        writeError(w, http.StatusBadRequest, "title and body are required")
        return
    }

    var n Note
    err := h.Pool.QueryRow(r.Context(),
        `INSERT INTO notes (tenant_id, title, body) VALUES ($1, $2, $3)
         RETURNING id::text, tenant_id::text, title, body, created_at`,
        tenantID, in.Title, in.Body,
    ).Scan(&n.ID, &n.TenantID, &n.Title, &n.Body, &n.CreatedAt)
    if err != nil {
        // Foreign-key violation on a nonexistent tenant surfaces here.
        writeError(w, http.StatusBadRequest, "failed to create note: "+err.Error())
        return
    }
    writeJSON(w, http.StatusCreated, n)
}

func (h *Handlers) ListNotes(w http.ResponseWriter, r *http.Request) {
    tenantID := r.PathValue("tenant_id")
    rows, err := h.Pool.Query(r.Context(),
        `SELECT id::text, tenant_id::text, title, body, created_at
         FROM notes WHERE tenant_id = $1 ORDER BY created_at`,
        tenantID,
    )
    if err != nil {
        writeError(w, http.StatusInternalServerError, "failed to query notes: "+err.Error())
        return
    }
    defer rows.Close()

    notes := make([]Note, 0)
    for rows.Next() {
        var n Note
        if err := rows.Scan(&n.ID, &n.TenantID, &n.Title, &n.Body, &n.CreatedAt); err != nil {
            writeError(w, http.StatusInternalServerError, "failed to scan note: "+err.Error())
            return
        }
        notes = append(notes, n)
    }
    if err := rows.Err(); err != nil && !errors.Is(err, pgx.ErrNoRows) {
        writeError(w, http.StatusInternalServerError, "row iteration error: "+err.Error())
        return
    }
    writeJSON(w, http.StatusOK, notes)
}

ListNotes initializes notes with make([]Note, 0) rather than a nil slice, so a tenant with no notes yet gets back [] in the JSON response instead of null, which matters if anything downstream deserializes the array without a nil check. And CreateNote doesn't validate tenant_id against the tenants table itself; it lets Postgres's own foreign key constraint reject a nonexistent tenant and surfaces that error directly, which is less code and gives a real database-backed guarantee instead of a race-prone existence check.

Deploying Postgres with a persistent volume

Postgres data on Unikraft Cloud lives on a volume, separate from the instance running the database engine, which is what makes cloning possible later. The volume is created first, sized modestly on purpose:

unikraft volume create --metro fra --name pgdemo-data --size 256M

unikraft run --metro fra --name pgdemo-db \
  -p 5432:5432/tls -m 1G \
  -e POSTGRES_PASSWORD=<your-db-password> \
  -e PGDATA=/volume/postgres \
  --volume pgdemo-data:/volume \
  --image <your-org>/pg-branching-demo-db:latest

The database image itself comes from Unikraft's own postgres example in unikraft-cloud/examples, PostgreSQL 16 built from source with the pg_ukc_scaletozero module included, rather than a stock Postgres image, since that module is what lets the instance participate correctly in scale-to-zero at all.

--size 256M is intentional. Unikraft Cloud volume quotas are account-wide, not per-volume: this account's total quota was 1024 MiB, and a 1 GiB source volume left no room to clone anything from it, failing with Failed to allocate volume. Quota exceeded ... current limit of 1024. Size the source volume with clones in mind, not just with the source's own data in mind.

This demo runs the database always-on. The volume-clone operation itself, the actual subject of this post, doesn't depend on scale-to-zero in any way, so the database's own scale-to-zero configuration has no bearing on anything that follows.

Seeding realistic, uneven data

A migration only fails in an interesting way if the table it touches actually looks like production, so the seed command deliberately avoids uniform data:

// Command seed populates the database with realistic, uneven multi-tenant data:
// at least 20 tenants, each with a randomized 10–200 notes. Run it against the
// deployed instance (set DATABASE_URL) — the whole point is branching from a
// realistic data shape, not a uniform toy table.
package main

import (
    "context"
    "fmt"
    "log"
    "math/rand"

    "pg-branching-unikraft/internal/db"
)

func main() {
    ctx := context.Background()

    pool, err := db.Pool(ctx)
    if err != nil {
        log.Fatalf("db: %v", err)
    }
    defer pool.Close()

    const tenantCount = 25
    totalNotes := 0

    for i := 0; i < tenantCount; i++ {
        name := fmt.Sprintf("Tenant %02d — %s", i+1, randCompany())
        var tenantID string
        if err := pool.QueryRow(ctx,
            `INSERT INTO tenants (name) VALUES ($1) RETURNING id::text`, name,
        ).Scan(&tenantID); err != nil {
            log.Fatalf("insert tenant: %v", err)
        }

        n := 10 + rand.Intn(191) // 10..200 inclusive
        batch := make([][]any, 0, n)
        for j := 0; j < n; j++ {
            batch = append(batch, []any{
                tenantID,
                fmt.Sprintf("Note %d for tenant %d", j+1, i+1),
                randBody(),
            })
        }
        for _, row := range batch {
            if _, err := pool.Exec(ctx,
                `INSERT INTO notes (tenant_id, title, body) VALUES ($1, $2, $3)`,
                row...,
            ); err != nil {
                log.Fatalf("insert note: %v", err)
            }
        }
        totalNotes += n
        log.Printf("tenant %d/%d: %d notes", i+1, tenantCount, n)
    }

    log.Printf("seed complete: %d tenants, %d notes total", tenantCount, totalNotes)
}

n := 10 + rand.Intn(191) is the entire mechanism behind the unevenness: rand.Intn(191) returns 0 through 190, so adding 10 gives a uniformly distributed 10 through 200 notes per tenant, inclusive on both ends. Run against the deployed instance, this produced 25 tenants and 2,870 notes, with per-tenant counts ranging from a minimum of 17 to a maximum of 183. That range is not cosmetic. It is what makes the upcoming migration failure a real failure against real data shape, rather than a contrived one against a toy table.

The risky migration, and its fix

The migration that fails lives in broken/, renamed deliberately so nobody applies it by accident:

-- broken/00002_add_priority_BROKEN_DO_NOT_APPLY_TO_SOURCE.sql
ALTER TABLE notes ADD COLUMN priority INT NOT NULL;

The version that actually ships, in migrations/, supplies a default so existing rows have something to backfill with:

-- migrations/00002_add_priority.sql
ALTER TABLE notes ADD COLUMN priority INT NOT NULL DEFAULT 0;

The fixed migration ships inside migrations/ and is applied through the small migrate command, which runs the embedded goose migrations against whatever DATABASE_URL points at. The broken file deliberately sits outside that path, plain SQL in broken/, run directly with psql against a throwaway clone to capture the raw failure, so it can never be picked up by migrate and applied to the source by accident.

// Command migrate applies the embedded goose migrations to DATABASE_URL.
//
//  go run ./cmd/migrate up      # apply all pending migrations
//  go run ./cmd/migrate down     # roll back the last migration
//  go run ./cmd/migrate status   # show migration status
//
// Point DATABASE_URL at the source or a branch as needed.
package main

import (
    "database/sql"
    "log"
    "os"

    _ "github.com/jackc/pgx/v5/stdlib"
    "github.com/pressly/goose/v3"

    "pg-branching-unikraft/migrations"
)

func main() {
    command := "up"
    if len(os.Args) > 1 {
        command = os.Args[1]
    }

    dsn := os.Getenv("DATABASE_URL")
    if dsn == "" {
        log.Fatal("DATABASE_URL is not set")
    }

    sqlDB, err := sql.Open("pgx", dsn)
    if err != nil {
        log.Fatalf("open db: %v", err)
    }
    defer sqlDB.Close()

    goose.SetBaseFS(migrations.FS)
    if err := goose.SetDialect("postgres"); err != nil {
        log.Fatalf("set dialect: %v", err)
    }
    if err := goose.Run(command, sqlDB, "."); err != nil {
        log.Fatalf("goose %s: %v", command, err)
    }
}

The same migrate binary applies the fixed migration to a clone during testing and later to the source during promotion; the only thing that changes between those two runs is which DATABASE_URL it's pointed at. The broken migration never goes near it. The whole point of the workflow below is running that broken file directly against a clone with psql, watching it fail for real, and only then reaching for the fixed migration through migrate.

The volume-cloning workflow

Cloning here is a consequence of Postgres's data living on a Unikraft Cloud volume: a volume can be cloned, and a fresh Postgres instance can be booted against that clone, which produces an independent, fully-populated copy of the database with no connection back to the source. Cloning requires the source volume to not be mounted read-write at the moment of the clone, so the workflow starts by briefly stopping the source instance, which also has the side benefit of guaranteeing a crash-consistent copy rather than one taken mid-write:

unikraft instances stop pgdemo-db
unikraft volume clone pgdemo-data --name pgdemo-clone1
unikraft instances start pgdemo-db

Measured end to end, that cycle cost about 8 seconds of source downtime: 4 seconds to stop, 2 seconds for the clone command itself to register the new volume, and 2 seconds to restart, with the clone's actual data copy continuing in the background afterward rather than blocking the restart. The source was back serving traffic well before the clone's data finished copying, and the clone, once ready, reported the same 2,870 notes as the source at the moment it was cloned.

With the clone made, booting a Postgres instance against it is the same deploy command as the source, pointed at the new volume instead:

unikraft run --metro fra --name pgdemo-clone-db \
  -p 5432:5432/tls -m 1G \
  -e POSTGRES_PASSWORD=<your-db-password> \
  -e PGDATA=/volume/postgres \
  --volume pgdemo-clone1:/volume \
  --image <your-org>/pg-branching-demo-db:latest

Running the broken migration against that clone, never against the source, produces the real failure this entire workflow exists to catch, before it ever has a chance to happen anywhere that matters:

psql:broken/00002_add_priority_BROKEN_DO_NOT_APPLY_TO_SOURCE.sql:14:
ERROR:  column "priority" of relation "notes" contains null values

The source database never saw that migration. A second, fresh clone, taken the same way, is where the fixed migration gets its own real test:

OK   00002_add_priority.sql
goose: successfully migrated database to version: 2

Querying that clone afterward confirmed all 2,870 existing rows picked up priority = 0 from the default, exactly as expected. Only once the fixed migration had actually succeeded somewhere disposable did it get applied to the source for real, with the same goose command pointed at the source's own DATABASE_URL, after which the source reported the identical result: 2,870 rows, all with priority = 0. Both clone instances and their cloned volumes were then removed, in that order, since a source volume cannot be deleted while it still has active clones attached to it.

The rest of the my experiences with volume cloning

Cleanup order matters when tearing clones back down. Unikraft Cloud refuses to delete a volume that still has clones referencing it, so a clone instance has to be removed before its underlying cloned volume will delete.

The API's container image also needed a second iteration. An initial static-glibc build on scratch crashed the microVM outright with a kernel crash: assertion error. The fix that shipped is a pure-Go, CGO_ENABLED=0 dynamic-PIE build on an Alpine rootfs instead of the fully static scratch build used for the MCP server example, since this binary needed the musl loader Alpine provides rather than eliminating the loader dependency entirely:

# syntax=docker/dockerfile:1

# Pure-Go dynamic-PIE build (no CGO/glibc), for the x86_64 metro. Unikraft's ELF
# loader needs a PIE; the resulting dynamic PIE uses the musl loader provided by
# the alpine final stage. CA certs are required for the TLS connection to the
# Postgres FQDN.
FROM golang:1.25-alpine AS build
WORKDIR /src
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -buildmode=pie -ldflags "-s -w" -o /api ./cmd/api

FROM --platform=linux/amd64 alpine:3.20
RUN apk add --no-cache ca-certificates
COPY --from=build /api /api
ENTRYPOINT ["/api"]

The Kraftfile that deploys it is small, and keeps DATABASE_URL out of the file entirely because it contains secrets, the database password:

spec: v0.6

runtime: base:latest
rootfs: ./Dockerfile

cmd: ["/api"]

# DATABASE_URL is passed at deploy time via `unikraft run -e DATABASE_URL=...`,
# never committed (it contains the DB password).

env:
  PORT: "8080"

Quality checks and costs

With the fix promoted, the API confirms the migration is backward-compatible without needing to know anything changed: GET /healthz still reports {"status":"ok"}, and a new note created through POST /tenants/{tenant_id}/notes picks up priority = 0 automatically, verified directly against the row in psql. That is the actual success condition for this whole exercise, the same running API, unaware a column was ever added, still working correctly on both sides of the migration.

The other thing worth knowing is what this pattern actually costs, and the honest answer has nothing to do with scale-to-zero. A clone exists for exactly as long as a migration test takes, then gets deleted, billed for compute and volume storage only across that window, against paying 24 hours a day for a separate always-on database per clone, the way a fleet of preview environments backed by individually provisioned managed Postgres instances typically does. The saving comes from the clone's lifetime being minutes, not from any idle-billing mechanism on the database itself.

Rounding up

What's running now is a real multi-tenant Postgres API where a migration that would have broken production instead broke a disposable copy first, and the fix that shipped had already succeeded somewhere expendable before it ever touched the source. The full source, including both versions of the migration and the exact cloning commands, is available at this repository. If you want to try this pattern yourself, Unikraft Cloud offers a free account to deploy your own volumes and instances at unikraft.com, and its docs cover scale-to-zero and volume snapshots in more depth than fits in this post.

Building & Deploying a Go MCP Server on Unikraft

Desmond Obisi — Mon, 13 Jul 2026 09:00:00 +0000

Model Context Protocol servers exist to give AI assistants a standard way to call out to real tools and real data. The moment you move one off your own machine and onto a host that other people's assistants can reach, you inherit the usual trade-off: keep it running and pay for idle compute between calls, or scale it to zero and eat a multi-second cold start the moment someone actually needs it.

Unikraft builds and boots your app as a unikernel: a minimal, purpose-built kernel containing only the code the app actually needs, rather than a general-purpose Linux kernel underneath a container. That's what gets boot times down to milliseconds, and deployment still starts from a Dockerfile, Unikraft just boots it as a microVM instead of running it as a container.

This post builds a Go MCP server backed by live GitHub data, then deploys it on Unikraft Cloud as a microVM that boots in around 24 milliseconds and costs nothing while idle, which changes that trade-off rather than just picking a side of it.

Prerequisites

Before starting, you will need:

Go 1.25 or later.
Docker with BuildKit enabled.
The Unikraft CLI, installed.
A free Unikraft Cloud account, with unikraft login completed in your terminal.
A GitHub fine-grained personal access token, scoped to read-only access on Contents, Issues, and Pull requests.
VS Code with GitHub Copilot Chat, or Claude Code, to actually exercise the deployed server as an MCP client rather than just curling it.

Why this is a good fit for microVMs specifically

Tool calls from an AI assistant are bursty by nature. A session might call a tool a handful of times in quick succession, then go quiet for hours while the person reads, thinks, or does something else entirely.

That access pattern punishes both of the usual hosting choices: an always-on container burns cost through all the quiet hours, and a container that scales to zero burns time on every burst, since a typical container cold start runs anywhere from several hundred milliseconds to a few seconds once you count image pull, runtime init, and application startup.

That's specifically what Unikraft is built for. In a published benchmark on a single AMD EPYC 7402P server, cold starts ran about 4ms for the first instance and stayed under 14ms even by the 5,000th concurrent VM on that same machine, and more recent platform work has pushed past a million scaled-to-zero microVMs on a single server while keeping cold starts and resumes in single-digit milliseconds.

Setting up the project

The server lives in a single Go module. The layout ends up simple on purpose: a main.go entrypoint, a tools package holding the three tool implementations plus shared helpers, and a github package wrapping an authenticated GitHub client.

mcp-github-insights/
├── main.go
├── tools/
│   ├── repo_stats.go
│   ├── open_prs.go
│   ├── search_code.go
│   └── tools.go
├── github/
│   └── client.go
├── Dockerfile
├── Kraftfile
└── go.mod

Two dependencies do almost all the work: mark3labs/mcp-go for the MCP server and transport, and google/go-github for talking to GitHub's REST API. Running go get -u github.com/mark3labs/mcp-go resolved to v0.55.1, and go get github.com/google/go-github/v68 resolved to v68.0.0, alongside golang.org/x/oauth2 at v0.36.0 for authenticating the GitHub client.

Wiring up the MCP server

The mcp-go API is small enough that the entire entrypoint fits in about 30 lines. It creates a server, registers the tools, and starts a Streamable HTTP listener:

package main

import (
    "log"
    "os"

    "github.com/mark3labs/mcp-go/server"

    "mcp-github-insights/tools"
)

func main() {
    port := os.Getenv("PORT")
    if port == "" {
        port = "8080"
    }
    addr := "0.0.0.0:" + port

    s := server.NewMCPServer(
        "github-insights",
        "0.1.0",
        server.WithToolCapabilities(true),
        server.WithRecovery(),
    )

    tools.Register(s)

    httpServer := server.NewStreamableHTTPServer(s)
    log.Printf("MCP GitHub Insights server listening on %s (endpoint: /mcp)", addr)
    if err := httpServer.Start(addr); err != nil {
        log.Fatalf("server error: %v", err)
    }
}

WithRecovery() is worth calling out specifically. It catches panics inside tool handlers and turns them into a normal MCP error response instead of taking the whole process down, which matters once real GitHub API responses, rate limits, missing repositories, malformed input, start hitting the server instead of whatever you tested with locally.

MCP's protocol has moved through more than one transport over its short life: stdio for local-only tools, then SSE, and now Streamable HTTP as the current standard. Read the installed version's source before writing this part of your own server, since guessing at a method name here is the single most common way to burn an afternoon. server.NewStreamableHTTPServer is what mcp-go v0.55.1 uses, and it is the right choice regardless, since Unikraft Cloud routes traffic to a TLS-terminated FQDN, which only works with a real network transport, not stdio.

The three tools

Each tool follows the same shape: register it with s.AddTool(mcp.NewTool(...), handler), pull arguments out of the request with req.RequireString or req.GetInt, do the actual GitHub API call, and return the result with mcp.NewToolResultText on success or mcp.NewToolResultError on failure.

get_repo_stats takes an owner and a repo, and returns stars, forks, open issue count, the default branch, and the SHA and date of the most recent commit. Here is the tool exactly as it ships in the repo:

package tools

import (
    "context"
    "time"

    "github.com/google/go-github/v68/github"
    "github.com/mark3labs/mcp-go/mcp"
)

type repoStats struct {
    Stars          int    `json:"stars"`
    Forks          int    `json:"forks"`
    OpenIssues     int    `json:"open_issues"`
    DefaultBranch  string `json:"default_branch"`
    LastCommitSHA  string `json:"last_commit_sha"`
    LastCommitDate string `json:"last_commit_date"`
}

func repoStatsTool() mcp.Tool {
    return mcp.NewTool("get_repo_stats",
        mcp.WithDescription("Get star, fork and open-issue counts plus the last commit for a GitHub repository."),
        mcp.WithString("owner", mcp.Required(), mcp.Description("Repository owner (user or organization).")),
        mcp.WithString("repo", mcp.Required(), mcp.Description("Repository name.")),
    )
}

func repoStatsHandler(ctx context.Context, req mcp.CallToolRequest) (*mcp.CallToolResult, error) {
    owner, err := req.RequireString("owner")
    if err != nil {
        return mcp.NewToolResultError("owner is required"), nil
    }
    repo, err := req.RequireString("repo")
    if err != nil {
        return mcp.NewToolResultError("repo is required"), nil
    }

    client, err := newClient(ctx)
    if err != nil {
        return mcp.NewToolResultError(err.Error()), nil
    }

    r, _, err := client.Repositories.Get(ctx, owner, repo)
    if err != nil {
        return mcp.NewToolResultError(ghError("fetch repository", err)), nil
    }

    out := repoStats{
        Stars:         r.GetStargazersCount(),
        Forks:         r.GetForksCount(),
        OpenIssues:    r.GetOpenIssuesCount(),
        DefaultBranch: r.GetDefaultBranch(),
    }

    commits, _, err := client.Repositories.ListCommits(ctx, owner, repo, &github.CommitsListOptions{
        ListOptions: github.ListOptions{PerPage: 1},
    })
    if err != nil {
        return mcp.NewToolResultError(ghError("fetch last commit", err)), nil
    }
    if len(commits) > 0 {
        out.LastCommitSHA = commits[0].GetSHA()
        out.LastCommitDate = commits[0].GetCommit().GetCommitter().GetDate().Format(time.RFC3339)
    }

    return jsonResult(out)
}

Two things are worth pointing out about this handler beyond what it obviously does. First, every failure path returns through mcp.NewToolResultError, never a bare Go error as the second return value, which is what keeps a GitHub outage or a typo'd repository name from ever reaching the client as a raw exception. Second, ghError is what turns a generic go-github error into the specific, readable message a model can actually reason about, rather than a wrapped stack trace. Running this against a real repository returns exactly what you would expect:

{
  "stars": 3762,
  "forks": 1467,
  "open_issues": 348,
  "default_branch": "staging",
  "last_commit_sha": "be744898b6947824e367e01765703401e08ce3c5",
  "last_commit_date": "2026-06-05T11:42:40Z"
}

That is real output from the deployed server, querying unikraft/unikraft.

list_open_prs takes an owner, a repo, and an optional min_age_days, and returns every open pull request older than that threshold, with its title, author, age, and a best-effort review decision:

package tools

import (
    "context"
    "time"

    "github.com/google/go-github/v68/github"
    "github.com/mark3labs/mcp-go/mcp"
)

type openPR struct {
    Number         int    `json:"number"`
    Title          string `json:"title"`
    Author         string `json:"author"`
    CreatedAt      string `json:"created_at"`
    AgeDays        int    `json:"age_days"`
    ReviewDecision string `json:"review_decision"`
}

func openPRsTool() mcp.Tool {
    return mcp.NewTool("list_open_prs",
        mcp.WithDescription("List open pull requests for a GitHub repository, optionally filtered by minimum age in days."),
        mcp.WithString("owner", mcp.Required(), mcp.Description("Repository owner (user or organization).")),
        mcp.WithString("repo", mcp.Required(), mcp.Description("Repository name.")),
        mcp.WithNumber("min_age_days", mcp.Description("Only include PRs at least this many days old. Defaults to 0.")),
    )
}

func openPRsHandler(ctx context.Context, req mcp.CallToolRequest) (*mcp.CallToolResult, error) {
    owner, err := req.RequireString("owner")
    if err != nil {
        return mcp.NewToolResultError("owner is required"), nil
    }
    repo, err := req.RequireString("repo")
    if err != nil {
        return mcp.NewToolResultError("repo is required"), nil
    }
    minAge := req.GetInt("min_age_days", 0)

    client, err := newClient(ctx)
    if err != nil {
        return mcp.NewToolResultError(err.Error()), nil
    }

    prs, _, err := client.PullRequests.List(ctx, owner, repo, &github.PullRequestListOptions{
        State:       "open",
        ListOptions: github.ListOptions{PerPage: 100},
    })
    if err != nil {
        return mcp.NewToolResultError(ghError("list open pull requests", err)), nil
    }

    out := make([]openPR, 0, len(prs))
    for _, pr := range prs {
        age := int(time.Since(pr.GetCreatedAt().Time).Hours() / 24)
        if age < minAge {
            continue
        }
        out = append(out, openPR{
            Number:         pr.GetNumber(),
            Title:          pr.GetTitle(),
            Author:         pr.GetUser().GetLogin(),
            CreatedAt:      pr.GetCreatedAt().Format(time.RFC3339),
            AgeDays:        age,
            ReviewDecision: reviewDecision(ctx, client, owner, repo, pr.GetNumber()),
        })
    }

    return jsonResult(out)
}

// reviewDecision derives an aggregate review state from a PR's reviews.
// Best-effort: on any error it returns "unknown" rather than failing the call.
func reviewDecision(ctx context.Context, client *github.Client, owner, repo string, number int) string {
    reviews, _, err := client.PullRequests.ListReviews(ctx, owner, repo, number, &github.ListOptions{PerPage: 100})
    if err != nil || len(reviews) == 0 {
        return "unknown"
    }
    latest := map[string]string{}
    for _, r := range reviews {
        switch r.GetState() {
        case "APPROVED", "CHANGES_REQUESTED":
            latest[r.GetUser().GetLogin()] = r.GetState()
        }
    }
    if len(latest) == 0 {
        return "pending"
    }
    for _, state := range latest {
        if state == "CHANGES_REQUESTED" {
            return "changes_requested"
        }
    }
    return "approved"
}

The GitHub API has no native "minimum age" filter on pull requests, so minAge is applied client-side, after fetching up to 100 open PRs per page. reviewDecision is its own function for a reason: reviews are a separate API call per pull request, so it is isolated on purpose, both to keep openPRsHandler readable and so that a failure fetching reviews for one PR degrades to "unknown" instead of failing the entire tool call. The filtering matters more in practice than it looks on paper. Against unikraft/kraftkit, the tool returned 6 open pull requests with min_age_days at 0, and 2 with min_age_days at 180, which is the difference between everything that is open and the pull requests that are actually stuck.

search_code takes an owner, a repo, and a query, and searches GitHub's code search API scoped to that repository, returning matching file paths with line snippets:

package tools

import (
    "context"
    "fmt"
    "strings"

    "github.com/google/go-github/v68/github"
    "github.com/mark3labs/mcp-go/mcp"
)

type codeMatch struct {
    Path        string `json:"path"`
    LineSnippet string `json:"line_snippet"`
}

func searchCodeTool() mcp.Tool {
    return mcp.NewTool("search_code",
        mcp.WithDescription("Search code within a single GitHub repository and return matching file paths with snippets."),
        mcp.WithString("owner", mcp.Required(), mcp.Description("Repository owner (user or organization).")),
        mcp.WithString("repo", mcp.Required(), mcp.Description("Repository name.")),
        mcp.WithString("query", mcp.Required(), mcp.Description("Code search query.")),
    )
}

func searchCodeHandler(ctx context.Context, req mcp.CallToolRequest) (*mcp.CallToolResult, error) {
    owner, err := req.RequireString("owner")
    if err != nil {
        return mcp.NewToolResultError("owner is required"), nil
    }
    repo, err := req.RequireString("repo")
    if err != nil {
        return mcp.NewToolResultError("repo is required"), nil
    }
    query, err := req.RequireString("query")
    if err != nil {
        return mcp.NewToolResultError("query is required"), nil
    }

    client, err := newClient(ctx)
    if err != nil {
        return mcp.NewToolResultError(err.Error()), nil
    }

    q := fmt.Sprintf("%s repo:%s/%s", query, owner, repo)
    res, _, err := client.Search.Code(ctx, q, &github.SearchOptions{
        TextMatch:   true,
        ListOptions: github.ListOptions{PerPage: 30},
    })
    if err != nil {
        // Code search has a stricter rate-limit tier; ghError reports it cleanly.
        return mcp.NewToolResultError(ghError("search code", err)), nil
    }

    out := make([]codeMatch, 0, len(res.CodeResults))
    budget := 10 // cap fallback content fetches to bound latency/rate-limit cost
    for _, cr := range res.CodeResults {
        snippet := ""
        if len(cr.TextMatches) > 0 {
            snippet = cr.TextMatches[0].GetFragment()
        }
        if snippet == "" && budget > 0 {
            budget--
            snippet = matchedLine(ctx, client, owner, repo, cr.GetPath(), query)
        }
        out = append(out, codeMatch{Path: cr.GetPath(), LineSnippet: snippet})
    }

    return jsonResult(out)
}

// matchedLine fetches a file and returns the first line containing the query,
// used as a fallback when GitHub's code search omits the text-match fragment.
func matchedLine(ctx context.Context, client *github.Client, owner, repo, path, query string) string {
    file, _, _, err := client.Repositories.GetContents(ctx, owner, repo, path, nil)
    if err != nil || file == nil {
        return ""
    }
    content, err := file.GetContent()
    if err != nil || content == "" {
        return ""
    }
    needle := strings.ToLower(query)
    for _, line := range strings.Split(content, "\n") {
        if strings.Contains(strings.ToLower(line), needle) {
            return strings.TrimSpace(line)
        }
    }
    return ""
}

This one needed the most defensive handling of the three. GitHub's code search API sometimes omits the text-match fragment it is supposed to return alongside a hit, so matchedLine is a fallback that fetches the actual file content and finds the matching line itself, but that fallback costs a full API call per file, which is why budget caps it at 10 fetches per search rather than letting a broad query trigger dozens of extra requests. And code search has its own, tighter rate-limit tier than the rest of the REST API, so a 403 from client.Search.Code needs to come back through ghError as a clean, specific MCP error rather than crash the tool call.

Building the container image

Unikraft's base runtime loads a plain ELF binary directly, without a container runtime underneath it, and its loader requires that binary to be position-independent. A default Go build does not produce one, so the build needs -buildmode=pie at minimum. The detail that matters beyond that is how the PIE gets linked. Go's internal PIE linker still emits a PT_INTERP header, which marks the binary as dynamically linked and expects a real loader to be present at boot, which does not exist on an empty FROM scratch image. The way around that is external linking with -static-pie, which needs a real C toolchain (CGO_ENABLED=1) and -tags netgo so DNS resolution stays in pure Go instead of reaching for libc. The result is a binary with no PT_INTERP header at all, no loader to find, and nothing left for scratch to be missing:

FROM --platform=linux/amd64 golang:1.25-bookworm AS build
WORKDIR /src
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=1 GOOS=linux GOARCH=amd64 go build \
      -buildmode=pie \
      -ldflags "-linkmode external -extldflags -static-pie -s -w" \
      -tags netgo \
      -o /mcp-server .

FROM scratch
COPY --from=build /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/
COPY --from=build /mcp-server /mcp-server
ENTRYPOINT ["/mcp-server"]

Two details in that final stage are not optional. The CA certificate bundle is copied in explicitly, since the server makes outbound HTTPS calls to the GitHub API and there is no CA trust store on a bare image otherwise. And GOARCH=amd64 has to be explicit if you are building from an Apple Silicon machine, since Unikraft Cloud's metros run on x86_64: the build cross-compiles and runs under emulation on an arm64 dev machine, which makes the build itself slower, but the metro needs amd64 regardless of what you build on.

The payoff for the static-PIE approach over a more conventional Alpine-based build is that there is no userspace left to load at all, just the binary and a certificate file, which shows up directly in the boot time (more on that in the testing section below). With this Dockerfile, the boot log is clean:

Powered by Unikraft Ijiraq (0.21.0~a653e50)
2026/07/05 00:18:59 MCP GitHub Insights server listening on 0.0.0.0:8080 (endpoint: /mcp)

Writing the Kraftfile

The Kraftfile that ties the Dockerfile to a deployable Unikraft Cloud image is small:

spec: v0.6
runtime: base:latest
rootfs: ./Dockerfile
cmd: ['/mcp-server']
env:
  PORT: '8080'

Notice GITHUB_TOKEN is not in there. Secrets should not live in a file that gets committed to version control, so it is passed at deploy time as a runtime environment variable instead, which the Unikraft CLI masks as asterisks in its own instance summary output.

Deploying to Unikraft Cloud

With the Dockerfile and Kraftfile in place, building and running the instance is two commands:

unikraft build . --output <your-org>/mcp-github-insights:latest
unikraft run \
  --metro fra \
  --image <your-org>/mcp-github-insights:latest \
  -p 443:8080/http+tls \
  -e GITHUB_TOKEN=<your-github-token> \
  --scale-to-zero policy=on,cooldown-time=300000 \
  --follow

--metro fra pins the instance to Unikraft Cloud's Frankfurt metro. Other metros available at the time of writing are dal, sin, was, and sfo. --scale-to-zero policy=on,cooldown-time=300000 tells the instance to suspend itself after 300 seconds of no traffic (cooldown-time is specified in milliseconds), which is the whole point of running an MCP server this way instead of on a container that has to stay warm. The command's output includes the instance's assigned FQDN, which for this deployment came back as broken-snowflake-r572gbfj.fra.unikraft.app.

Connecting a real MCP client

A running server is not proof of anything on its own, so the last step is pointing an actual MCP client at it. For VS Code with GitHub Copilot Chat, that is a .vscode/mcp.json file:

{
  "servers": {
    "github-insights": {
      "type": "http",
      "url": "https://<your-fqdn>.fra.unikraft.app/mcp"
    }
  }
}

Claude Code's MCP configuration follows the same shape with its own config file. Once connected, a prompt like "using the github insight mcp, how many open PRs on unikraft are older than 90 days" triggers a live list_open_prs call against the deployed instance.

Testing and troubleshooting

Before wiring in a client, it is worth confirming the server itself over curl, since MCP's Streamable HTTP transport requires an initialize handshake before any other call will work:

# 1. initialize — capture the Mcp-Session-Id response header
curl -si -X POST https://<your-fqdn>.fra.unikraft.app/mcp \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-03-26","capabilities":{},"clientInfo":{"name":"curl","version":"0"}}}'

# 2. list tools — pass the session id from step 1
curl -s -X POST https://<your-fqdn>.fra.unikraft.app/mcp \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -H 'Mcp-Session-Id: <id-from-step-1>' \
  -d '{"jsonrpc":"2.0","id":2,"method":"tools/list"}'

A missing session ID on the second call is the most common mistake here, and it fails with a plain 400 rather than anything that points you toward the actual cause.

The platform-reported boot time for this deployment lands in 24 milliseconds — a fraction of a second, and still orders of magnitude below a typical container cold start measured in whole seconds. Scale-to-zero resume behaves the same way: a non-stateful wake is just a fresh boot, so it comes up in that same range after the instance has gone fully idle. Treat the exact figure as a ballpark rather than a fixed number, since it varies run to run with conditions in the metro.

The end-to-end wall clock for that first request after waking, measured from outside the Frankfurt metro, was 0.512 seconds, with the TLS handshake alone accounting for 0.143 seconds, so the request is dominated by network and TLS overhead, not the VM coming up.

Conclusion

What is running now is a Go MCP server that answers real questions about real GitHub repositories, packaged as a microVM that costs nothing while nobody is asking it anything, and answers in about 24 milliseconds the moment someone does. The full source, including the Dockerfile, the Kraftfile, and the three tool implementations, is available at this repository.

From here, the natural next step is wiring in more tools against a real internal API instead of GitHub's, or looking at how the same pattern applies to an MCP server that needs persistent state between calls, which is where Unikraft Cloud's volume support comes in.

If you want to try this yourself, Unikraft Cloud offers a free account to deploy your own microVMs at unikraft.com, and its docs cover the Kraftfile spec, scale-to-zero, and other integrations in more depth than this post has room for.

Copilot vs. Cody: All you need to know

Desmond Obisi — Wed, 11 Dec 2024 21:23:50 +0000

The advancement of artificial intelligence (AI) has impacted the software industry, especially with the introduction of AI coding assistants. A McKinsey study showed that developers using AI tools perform 20%-50% faster on average than those not using it. There has also been a debate about whether these AI coding assistant tools can truly increase or decrease developer's performance, function, productivity ratio, and overall experience.

As a programmer, I want to be productive and accomplish tasks faster with the help of these AI tools. I also want to use the one that provides the overall best experience regarding integrations, how secure it is, if the code suggestions are of great quality, and how easily I can extend its features and capabilities. This article will look at two of the most used AI coding tools from a developer's point of view.

While this article isn’t part of this debate, it will highlight the core features, strengths, weaknesses, benchmarks, etc., of these widely used AI coding assistant tools—Sourcegraph Cody and GitHub Copilot—to lead us to an objective conclusion on which is more reliable. Let’s get into the breakdown and comparison of these tools.

Overview of Copilot vs. Cody

In this section, you’ll learn the background of both tools, highlighting their core features and functionalities to help you understand them and their uses.

What is GitHub Copilot?
GitHub Copilot was officially launched in June 2021, resulting from a collaboration between GitHub and OpenAI. Powered by OpenAI’s Codex model, Copilot was designed to help developers write code faster by providing real-time suggestions and auto-completions.

It was released as a plugin on the JetBrains marketplace on October 29, 2021. On June 21, 2022, GitHub announced that Copilot was out of "technical preview" and is available as a subscription-based service for individual developers after one year of beta testing from developers who got early access.

Core features of Copilot

Real-time code suggestions: Copilot offers contextual code suggestions as developers type, including entire functions and complex code snippets.
GitHub Copilot chat: Copilot now offers a chat interface where you can run prompts and generate things like unit tests, code snippets, etc.
Multi-language support: It supports many programming languages, from popular ones like Python, JavaScript, and TypeScript to less common languages.
Natural language to code: Copilot can convert natural language comments into actual code, which is particularly useful for prototyping and quick development tasks.
Learning from open source: The AI-powered tool is trained on billions of lines of code from public repositories, making it adept at generating relevant code snippets.

What is Sourcegraph Cody?
Cody, introduced by Sourcegraph, is an AI-powered coding assistant designed to use advanced search and codebase context to help you understand, write, and fix code faster. Launched in 2023, Cody aims to provide deeper context and more accurate code suggestions, particularly for complex and large-scale projects.

Unlike Copilot, which is heavily geared toward individual developers, Cody is built with a focus on team collaboration and enterprise-level projects.

Core features of Cody

Contextual code intelligence: Cody is designed to understand the broader context of the codebase, making it more effective than many AI coding assistants for large projects with interconnected code files.
Multi-file awareness: Cody can analyze and provide suggestions based on multiple files within a project, ensuring its suggestions align with the entire codebase's structure.
Code search integration: Cody integrates with Sourcegraph's powerful code search capabilities, allowing you to quickly navigate and find relevant code snippets within their projects.
Custom commands: Cody has an option for creating custom commands that you can use to write large language model (LLM)- powered instructions. These instructions automate boring or repetitive tasks in their day-to-day work, such as documentation, comment writing, etc.
Multi LLM support: Cody is designed to use different LLMs for code generation, error fixing, optimization, etc. Cody also allows developers to add their LLM keys, and the usage will be on their account.
Multi-language support: Cody supports many programming languages, from the popular ones like Python, Javascript, Rust, C, and C++ to the less common ones like Julia or Zig.
Enterprise-grade security: Cody is tailored for enterprise environments, with enhanced security and privacy features, making it suitable for organizations with strict data protection requirements.

Now that we’ve explored the histories and the core features of the two AI assistant tools, let’s compare them in terms of functions, integrations, security, and developer experience.

Comparison between Sourcegraph Cody and GitHub Copilot

This comparison will evaluate how Sourcegraph Cody and GitHub Copilot perform against the chosen criteria, reflecting the expectations developers have when using these tools. The table below will provide an overview, helping to determine which tool stands out as the best option.

Cost comparison
Cody: Cody is also available on a subscription basis, with pricing significantly better than its counterpart, Copilot. It also has a forever free tier, unlike the 30-day free trial from Copilot, allowing individual developers to have a thorough experience before purchasing.

Copilot: Copilot is available on a subscription basis, with individual and team plans. The pricing is generally affordable for individual developers, but the costs can add up for larger teams.

Ease of setup and use
Cody: Setting up Cody requires developers to install the extension from the supported IDEs marketplace, log in with their Sourcegraph account, and start using the tool. Cody can also be accessed on the web. The user interface is clean and integrates seamlessly with supported IDEs, providing an additional chat window interface and shortcut keys for handy commands.

Copilot: Setting up Copilot is relatively straightforward, especially for developers already using Visual Studio Code or JetBrains IDEs. The process involves:

Installing the Copilot extension from the marketplace.
Logging in with a GitHub account.
Enabling the tool.

Once set up, Copilot provides real-time suggestions as the developer writes code. The user interface is intuitive, with suggestions appearing as semi-transparent text within the IDE, allowing developers to accept, modify, or reject them easily.

Supported IDEs and environment
Cody: Cody is designed to work best with IDEs that integrate with Sourcegraph’s ecosystem. It supports popular IDEs like the VS Code editor, some JetBrains IDEs like IntelliJ IDEA, PyCharm, etc., and Neovim, which is still in the experimental phase.

Copilot: Copilot is primarily designed for Visual Studio Code editor and Visual Studio IDE, but it also supports others like Neovim and JetBrains IDEs like IntelliJ IDEA, PyCharm, etc. This wide IDE support makes it accessible to a broad range of developers.

Compatibility with programming languages
Cody: Cody supports a wide range of programming languages, including JavaScript, TypeScript, PHP, Python, Java, C/C++, C#, Ruby, Go, SQL, Swift, Objective-C, Perl, Rust, Kotlin, Dart, etc., and shell scripting languages (like Bash, PowerShell).

Copilot: Copilot boasts compatibility with various programming languages, from mainstream languages like Python, JavaScript, and Ruby to more niche languages. This versatility makes it a go-to tool for developers working across different projects and languages.

LLM Integrations
Cody: Cody defaults to the Claude 3 model from Anthropic for its code generation, autocomplete, and chat features, but its strengths lie in its diverse LLM integration(Claude, Mistral, GPT, and Gemini), unlike Copilot, which solely relies on the GPT models. It also allows users to bring their own API key for the supported LLMs.

Copilot: Copilot stems from a joint effort between GitHub and OpenAI, so Copilot is limited to only the GPT models for its code generation, chat, and autocomplete feature.

Quality of code suggestions
Cody: Cody shines in providing high-quality code suggestions that consider the broader context of the project. Its multi-file awareness and deep codebase understanding enable it to offer more precise and contextually appropriate suggestions, particularly in large projects. It also works well with popular code hosting platforms like GitLab, Bitbucket, etc., with respect to code generation and context awareness.

Copilot: Copilot’s suggestions are generally accurate and contextually relevant, especially for common coding patterns and standard libraries. However, its effectiveness can diminish in more complex scenarios or when dealing with highly customized codebases or codebases whose host is not GitHub.

Context understanding and accuracy
Cody: Cody’s ability to analyze and understand the entire codebase gives it an edge in providing accurate suggestions that align with the project’s overall structure. This makes Cody particularly valuable in enterprise environments where code complexity and scale are significant considerations.

Copilot: While Copilot is good at understanding the immediate context, the difference here is that its suggestions can sometimes lack the depth needed for complex codebases, particularly when the code spans multiple files or involves intricate dependencies.

Speed and efficiency improvements
Cody: While Cody may not generate suggestions as instantaneously as Copilot, its focus on accuracy and context often results in fewer errors and less time spent correcting code. This can translate into significant efficiency gains for developers working on large, complex projects.

Copilot: Copilot is designed to boost developer productivity by providing quick suggestions and auto-completions. This is particularly beneficial in rapid development environments. One of its strengths is its speed in generating suggestions.

Data handling policies
Cody: Cody is built with enterprise users in mind and, as such, places a strong emphasis on security and privacy. Sourcegraph offers more control over how data is handled, including options for on-premises deployment, which can alleviate concerns about data exposure in cloud environments.

Copilot: Copilot has faced scrutiny regarding its data handling practices, particularly concerning the training data derived from public repositories. While GitHub has implemented measures to protect user privacy, concerns remain about how user data is used and whether Copilot’s suggestions might inadvertently reproduce copyrighted code.

Intellectual Property(IP) concerns and business implications
Cody: Cody’s approach to code suggestions, which focuses on understanding the developer’s existing codebase rather than drawing from a broad corpus of public code, reduces the risk of IP issues. This makes Cody a safer option for businesses concerned about the legal implications of AI-generated code.

Copilot: The potential for Copilot to suggest code that closely mirrors existing open-source code has raised IP concerns. Developers and organizations need to be cautious about the legal implications of using code suggestions that might be derived from copyrighted material.

Value for money
Cody: Cody offers better value for money because it supports free users with a good feature list. Paid users even get more value and access to a wider range of features like flexible LLM choice, tight security, and context filters, which prevent LLMs from reading sensitive files in the codebase.

Copilot: For individual developers or small teams working on diverse projects, Copilot offers great value for money, especially given its fast autocomplete, broad language support, and ease of use.

From comparing features, functions, and differences, Cody emerges at least in my opinion, the clear favorite and a better option. The next section outlines how we reached this conclusion.

Sourcegraph Cody's strengths over GitHub Copilot

The comparison table above considers the differences and similarities between GitHub Copilot and Sourcegraph Cody. Undoubtedly, Cody shows to be a better tool when we examine all the criteria. Here are some of the strengths of Cody over Copilot that are worthy of highlighting:

Superior code suggestions: Cody’s ability to use Code Search, another Sourcegraph tool under the hood, allows it to provide more accurate and contextually relevant code suggestions. It also has a feature for prompts and custom commands where you can tailor it to a particular prompt and reuse it in the codebase for code suggestions or related tasks.
Better context understanding: Cody’s multi-file awareness gives it a significant advantage in understanding the broader context of the project. It scans through open files in the editor and files in the same folder and can link a file anywhere in the codebase when using the chat feature.
Enhanced security and privacy: Cody’s focus on enterprise-grade security and privacy makes it a superior choice for organizations with strict data protection requirements. Admins on the Sourcegraph Enterprise instance can use the Cody Context Filters to determine which repositories Cody can use as the context in its requests to third-party LLMs. Other users can also use the Cody Ignore File, an experimental feature yet to set files they want Cody to ignore when picking context in the codebase.
Data handling and IP protection: Cody generates its suggestions by relying on the existing codebase and general LLM knowledge. It does not scan or use open-source codes or other people’s codes. This is a significant advantage for enterprises that must ensure compliance with IP laws and avoid potential legal disputes.
Cost-effectiveness: While Cody’s pricing is fairly lower than Copilot, it offers substantial value for large teams and enterprises and that is a good advantage for the tool.

Addressing common questions and concerns about Copilot

Users have asked these common questions, to know which is better for them between Copilot and other AI coding tools. This section will answer some of these questions from a user perspective to help you understand if Copilot is worth the bargain for your development workflow. Some of these questions are:

Is Copilot worth buying?
Copilot is worth considering for individual developers or small teams looking for an affordable AI-assisted coding tool. It provides quick suggestions and supports various programming languages, making it a versatile tool for various projects. However, its effectiveness can vary depending on the complexity of the codebase and the developer’s specific needs.

What are the disadvantages of Copilot?
The main disadvantages of Copilot include:

Limited context awareness: Copilot’s suggestions are primarily based on the immediate written code, which can lead to less accurate suggestions in complex projects.
IP concerns: The potential for Copilot to suggest code derived from open-source repositories raises legal and ethical concerns, particularly for businesses.
Security and privacy: As a cloud-based tool, Copilot may not meet the security requirements of all organizations, especially those handling sensitive data.

Is it OK to use Copilot?
Copilot is generally safe to use for individual developers and small teams, provided they know the potential IP risks and limitations in context understanding. However, organizations should carefully consider these factors, especially if they work with proprietary or sensitive code.

Conclusion

Both Cody and Copilot are powerful AI-assisted coding tools, each with pros and cons. Copilot is an excellent choice for individual developers and small teams looking for an affordable, easy-to-use tool with broad language support, while Cody goes above and beyond in context flexibility, better security and data compliance, access to different LLMs, etc.

I have explored both GitHub Copilot and Sourcegraph Cody and have seen that each tool has its strengths. After diving into both, I found Cody’s deeper context understanding, access to different LLMs, and a strong focus on security to be game-changers for projects of any size. If you’re curious, I’d recommend signing up for Cody and seeing how it fits into your workflow. However, if Copilot aligns better with your needs, it’s also a solid option. Both tools offer valuable features, so exploring what works best for you is worth exploring.

Faster Postgres Queries with Cloudflare Hyperdrive and Neon

Desmond Obisi — Wed, 07 Feb 2024 14:36:14 +0000

If you have a database that gets queried from multiple regions (e.g. via edge functions) and you want to improve overall performance, this guide may help. To demonstrate, we’ll use Neon, a fully managed serverless PostgreSQL, and Cloudflare Hyperdrive, a lightning-fast globally distributed database acceleration platform. When you put Hyperdrive between your database and globally distributed applications and functions that query it, Cloudflare will route and cache queries to reduce latency and improve overall performance.

This guide will walk you through each step of the process, from setting up Neon Postgres and Cloudflare Hyperdrive to writing custom API services and deploying your application. We'll also cover essential topics such as utilizing Wrangler CLI for Hyperdrive setup, learning how Hyperdrive makes queries faster, and benchmarking native Postgres queries against the Hyperdrive accelerated queries.

Prerequisites

A Cloudflare account.
Wrangler CLI installed on your local machine.
Your local machine should have Node.js and npm installed. Wrangler CLI requires a Node version of 16.13.0 or later to avoid permission issues.
A basic knowledge of SQL.

Setting up Neon Postgres

Setting up your first Neon Postgres project is straightforward—follow the steps below to get started!

Visit Neon to sign up for an account.

After a successful registration, the system will redirect you to create a new project. Here, you can fill in what Postgres version you want to use, the project name, the database name, and the region you want the database instance to run on.

A pop-up with the connection link to your Neon Postgres database will appear when your project is successfully created. Select the psql option from the dropdown list, copy the string, and save it somewhere. You will use it to connect to Hyperdrive in your demo application later.

Finally, create a table and insert some data into your database using the Neon SQL Editor. From the side menu, locate the SQL Editor option, click on it, replace the command with the one below, and run it.

    CREATE TABLE users(id SERIAL PRIMARY KEY, name TEXT NOT NULL, email TEXT NOT NULL, phone TEXT NOT NULL);
    INSERT INTO users (name, email, phone) VALUES
      ('Kehinde', 'kh@nmail.com', '1209867574'),
      ('Desmond', 'des@nmail.com', '4584930999'),
      ('Franklin', 'frk@nmail.com', '3458976048'),
      ('Aisha', 'as@nmail.com', '0987954890'),
      ('Adaeze', 'az@nmial.com', '1234567890');
    SELECT * FROM users;

This SQL command does three things specifically:

The first command, CREATE TABLE users, creates a table in your database called "users” with columns: id, name, email, and phone. The id is set to be the primary key and should follow a series, while the other three are text strings and should not be null; that is to say, they shouldn’t be empty when creating a user record.
The second command, INSERT INTO users, inserts data into each column of the table as specified in the VALUES section.
The last one, SELECT * FROM users, returns all the data in the users table.

Upon successfully running the query above, you’ll get a screen like this one below. This screen is found in the Tables Menu. Click on Tables from the side menu and select users to see the new content created.

Setting up Cloudflare Hyperdrive and Workers

In this section, you will learn how to set up a Cloudflare Worker project with the Wrangler CLI, bind your Hyperdrive proxied database, and use it in your application. You will be creating the application from scratch.

If you already have Wrangler CLI installed, you don’t need to worry about this first step. If you don’t have Wrangler CLI installed, run this command in a new terminal to install it globally:

    npm install wrangler@latest

Next, navigate to the directory where you want to store your project on your machine and run this command to set up a Cloudflare Workers application.

    npm create cloudflare@latest

Workers is a Cloudflare service that provides an execution environment that allows you to create new applications or augment existing ones without configuring or maintaining infrastructure.
Workers run on Cloudflare’s global network in hundreds of cities worldwide.

The above command will prompt you to install the create-cloudflare package and lead you through the setup steps.

For this guide, set up a basic Workers application by:

Naming your new Worker directory by specifying where you want to create your application.
Selecting the "Hello World" script as the type of application you want to create.
Answering "yes" to using TypeScript.
You will be asked if you want to deploy the project to Cloudflare. Choose not to deploy and go to the newly created project directory to begin writing code. You will do the deployment later.

When the setup is done and before creating your Hyperdrive binding, log in with your Cloudflare account for authentication by running the command below:

    cd <your-worker-project> && npx wrangler login

This command will open your browser to log into Cloudflare and acquire access to your terminal. Upon a successful connection, you will get a screen like the one below:

Let’s connect to Hyperdrive now that you have configured Wrangler CLI and have logged in to your Cloudflare account. Run the command below to connect your Neon Postgres to Hyperdrive:

    npx wrangler hyperdrive create pg-hyperdrive --connection-string="your-neon-db-connecion-string"

A few things to note in the above command:

The wrangler hyperdrive create command initializes the Hyperdrive creation.
The pg-hyperdrive is the name of your Hyperdrive. It can be any name of your choice.
The --connection-string flag="your-neon-db-connection-string" is for passing your database connection string as a parameter to the create command.

You will get a response in your terminal like the one below upon a successful connection.

The final step for this section is to set the generated Hyperdrive ID to your wrangler.toml file, which you will use to connect to Neon Postgres in the next section, as shown below. You must remove the initial content from the package and update your wrangler.toml file like the one below. Remember to replace the placeholder with your Hyperdrive ID!

Writing the API services

If you did everything above, you should have a folder structure like the one below. In this section, you will set up the database connection, create custom query functions, and update the /src/index.ts file to match your configurations. Also, since you are deploying to Workers, you will use the Hono framework instead of Express.

Hono is an Ultrafast web framework for Cloudflare Workers, Fastly Compute, Deno, Bun, Vercel, Lagon, Node.js, and others. You can learn more about Hono here.

First, install two key packages: the Postgres driver and Hono. Also, you’ll need to install the Postgres driver types as a dev dependency since you are using Typescript.

    npm i pg hono
    npm i --save-dev @types/pg

Create a dbconnect.ts file in the src folder and paste the code below.

    // src/dbconnect.ts
    import { Context } from 'hono';
    import { Client } from 'pg';

    export const db = async (c: Context) => {
        const client = new Client({ connectionString: c.env.HYPERDRIVE.connectionString });
        // Connect to your database
        await client.connect();
        return client
    };

In the above code, you set up a database client from the Postgres driver to use the link generated by Hyperdrive as a proxy to your database and return the client instance for your app to use in reading and writing to the database.

Next, you will write some helper functions that will be used to perform read and write operations to your database through Hyperdrive proxy. You will create a queries.ts file in the src directory and paste the code below.

    // src/queries.ts
    import { Context } from "hono";
    import { db } from "./dbconnect";

    type User = {
        name: string;
        email: string;
        phone: string;
    }
    export const getUsers = async (c: Context) => {
        const limit = c.req.query('limit') || 10;
        const offset = c.req.query('offset') || 0;
        const dbClient = await db(c);
        let result = await dbClient.query
            (`SELECT * FROM users LIMIT ${limit} OFFSET ${offset}`);
        return result;
    };

    export const getUser = async (c: Context) => {
        const id = parseInt(c.req.param('id'))
        const dbClient = await db(c);
        let result = await dbClient.query
            (`SELECT * FROM users WHERE id = ${id}`);
        return result;
    }
    export const createUser = async (c: Context) => {
        const user = await c.req.json<User>()
        const dbClient = await db(c);
        let result = await dbClient.query
            (`INSERT INTO users (name, email, phone) VALUES ('${user.name}', '${user.email}', '${user.phone}')`);
        return result;
    }

Here, you are writing three different functions that get all the users, get a single user, and create a user in the database. For each function, you are passing the context parameter, which contains the request body or parameters, to the database client. The database client will instantiate with these parameters. After that, you can use the database client to make your queries or insertion. After a successful query or insertion, it returns the result to be read in the application.

Finally, update the contents of the index.ts file in the src folder to match the code below.

    // src/index.ts
    import { Hono } from 'hono';
    import { cors } from 'hono/cors'
    import { prettyJSON } from 'hono/pretty-json'
    import { getUsers, getUser, createUser } from './queries'
    import { db } from './dbconnect';


    type Env = {
        HYPERDRIVE: Hyperdrive;
    };
    const app = new Hono();
    app.get('/', (c) => c.text('Pretty Users API'))
    app.use('*', prettyJSON())
    app.notFound((c) => c.json({ message: 'Route Not Found', ok: false }, 404))

    const api = new Hono<{ Bindings: Env }>()
    api.use('/users/*', cors())
    api.get('/users', async (c) => {
        const users = await getUsers(c)
        return c.json({ users })
    })
    api.get('/users/:id', async (c) => {
        const user = await getUser(c)
        return c.json({ user })
    })
    api.post('/users', async (c) => {
        const ok = createUser(c)
        return c.json({ ok })
    })
    app.route('/api', api)

    export default app;

In the code above, you obtained the Hyperdrive data from wrangler.toml. You first created an app instance with Hono and set the basic endpoint that you can use to check your routing works fine and make the JSON response formatted with the prettyJSON() method.

After that, you created another instance of Hono called API, which has the Env binding. This is so that you can read the value of the Hyperdrive ID from the context anywhere in the app. Hopefully, it now makes sense why you passed the context to your query functions and database connection function too.

Finally, you defined each route to call their respective query functions and pass the context down to them. The API route is now defined so that your endpoint calls will be to api/users/…

Remember, this is a Cloudflare Worker application using Hono, so in the index, you can read the data in your .toml file as a type of Env.

Deploying to Cloudflare Workers

Now that everything is set up, the next step is to deploy your application to Cloudflare Workers, the serverless execution environment. To deploy your application, run

    npx wrangler deploy

This will deploy your application to Workers. If you are not logged in to the Wrangler CLI, the command will prompt you to log in for authentication; your application will then be deployed. You will get a response upon a successful deployment, as shown in the image below.

Testing and benchmarking with vs without Hyperdrive

The core reason for using Hyperdrive to proxy the database instead of using the Neon connection URL directly in your application is the optimization for speed and performance when making queries. This section compares the response time for a large query from across the world, first using our new API on Hyperdrive and then using a traditional single-region API server. As you can see below, the Hyperdrive route is significantly faster.

The link to the applications used for the demo can be found here on GitHub.

Here’s a query to fetch all users in the database for Neon Postgres and Cloudflare Hyperdrive proxy. It responded at 780ms on the first query and between 300ms and 450ms on subsequent queries.

Here’s a similar query to fetch all users in the database that’s routing through a single API server. It responded at 1888ms at the first query and between 600ms and 3s on subsequent queries.

This video demonstrates the speed test between Neon Postgres connected through Hyperdrive and Neon Postgres connected through an API App in a single region.

Speed Benchmarking For Databases Queries | Opentape

Desmond Obisi - Feb 7th, 2:21pm

app.opentape.io

Why was the Workers + Hyperdrive approach faster?

A few reasons:

Workers are deployed globally, close to users - for most of the world, the network latency between local device and worker function is lower than when using a single API server.
Hyperdrive keeps a connection to the database alive - Hyperdrive keeps a “warm” connection to the database alive across function calls. This eliminates the multiple round trips usually required to establish a new connection.
Hyperdrive caches certain responses - For SELECT queries, Hyperdrive caches responses for 60 seconds by default, so repetitive queries will never even hit the database.

Conclusion

Congratulations! If you followed along, you learned to use Neon Serverless Postgres with Cloudflare Hyperdrive to achieve faster database queries. You also learned about Workers, Wrangler CLI for interfacing with Cloudflare's products, and Hono for writing Node.js APIs that can be deployed to Workers.

Other things that can be explored on this subject leveraging Hyperdrive for intensive database operations are transactions and query caching. You can check the reference section for a feel of other things Cloudflare offers with the Hyperdrive developer tool.

References

Implement OTP Verification using Redis and Node.js

Desmond Obisi — Tue, 30 May 2023 11:11:38 +0000

Introduction

In today's digital space, user authentication and verification are crucial components of any application's security measure. One-time password (OTP) systems provide an extra layer of security by generating unique codes that can be used once and are valid for a short period.

This article will guide you through the process of building an OTP and verification feature using Redis and Node.js. Redis, a powerful in-memory data structure store, will be utilized to store and manage the OTPs efficiently.

Overview of OTP-based Authentication

In this section, we will go through an overview of OTP-based authentication and discuss its advantages over traditional password-based systems.

What is OTP-based Authentication?

One-time password (OTP) authentication is a mechanism that provides an additional layer of security during an authentication process.

Unlike traditional password-based authentication, which relies on fixed passwords, OTP-based authentications generate random and unique codes that are valid for a short period (typically a few minutes). Users are required to provide the OTP along with their username or email to gain access to the system.

Advantages of OTP-based Authentication:

OTP-based authentication offers several advantages over traditional password-based systems, a few of which are:

Increased Security
Mitigation of Password-related Risks
Two-factor Authentication (2FA)

By implementing OTP-based authentication and verification in your applications, you can significantly enhance the security of user authentication while providing a seamless, user-friendly experience.

Let's move on to the next section, where we will set up the development environment for our project.

Setting Up the Development Environment

In this section, we will go through the process of setting up the development environment for building the OTP and verification feature with Redis and Node.js. We will first cover the installation of Node.js, setting up Redis, and creating a new Node.js project.

Setting Up Node.js:

To begin, you need to install Node.js on your system. Node.js is available for multiple operating systems and can be downloaded from the official Node.js website. Follow these steps to install Node.js:

Visit the Node.js website using your web browser.
Download the appropriate Node.js installer for your operating system (Windows, macOS, or Linux).
Run the installer and follow the on-screen instructions to complete the installation process.

To verify that Node.js is installed correctly, open a command prompt or terminal and run the following command:

    node --version

You should see the version number of Node.js printed in the console.

Setting Up Redis

Next, you need to set up Redis, the in-memory data structure store that will be used to store and manage the OTPs. Follow these steps to install and configure Redis:

Visit the Redis website using your web browser.
Download the Redis distribution package for your operating system. Since Redis does not run directly on Windows, you can either run it through WSL2 (Windows Subsystem for Linux) or by downloading this port of Redis for Windows here and installing it. In this tutorial, we will be using the latter.
Open a command prompt or terminal and run the Redis server by executing the following command:

    redis-cli

This will start the Redis server on the default port 6379.

Creating a New Node.js Project

Now that you have Node.js and Redis all setup, let's create a new Node.js project for building the OTP and verification feature.

Follow these steps:

Open a command prompt or terminal and create or navigate to the directory where you want to create your project.

    mkdir tutorials && cd tutorials

Run the following command to clone the template that I made for this project in my GitHub repository and after that, run it.

    git clone https://github.com/DesmondSanctity/node-redis-otp.git && npm install

This will give you most of the project setup except the various logic for the OTP generation, Redis caching and data retrieval, which we will be implementing in the next section.

Generating and Caching OTPs with Redis

In this section, we will explore the implementation details of generating OTPs and caching the data with Redis. We will use a user signup/login system to demonstrate this concept. We would also use a Node.js client library redis and otp-generator to interact with the local Redis instance and generate unique OTPs respectively.

Connecting to the Local Redis Instance

To utilize the caching capabilities of Redis, set up and connect to the local Redis instance you installed on your machine. In the server.js file, set up the connection as shown below and export it for use in other files.

    ...
    // create a client connection
    export const client = redis.createClient();

    // on the connection
    client.on("connect", () => console.log("Connected to Redis"));

    await client.connect();
    ...

Generating OTP for User and Storing to Redis

Now that you have established a connection with your local Redis installation, you can test generating OTPs and storing them in Redis. In the userController.js file where the user logic is, add a method to generate OTP and store OTP using the packages we installed earlier.

    ...
    export async function register(req, res) {

        try {
            const { username, password, email, firstName, lastName } = req.body;

            // Generate a random OTP using the otp-generator package
            const otp = otpGenerator.generate(4, {
                lowerCaseAlphabets: false,
                upperCaseAlphabets: false,
                specialChars: false
            });

            // check the existing user
            const existUsername = new Promise((resolve, reject) => {
                UserModel.findOne({ username: username }, function (err, user) {
                    if (err) reject(new Error(err))
                    if (user) reject({ error: "Please use unique username" });

                    resolve();
                })
            });

            // check for existing email
            const existEmail = new Promise((resolve, reject) => {
                UserModel.findOne({ email: email }, function (err, email) {
                    if (err) reject(new Error(err))
                    if (email) reject({ error: "Please use unique Email" });

                    resolve();
                })
            });

            await Promise.all([existUsername, existEmail])
                .then(() => {
                    if (password) {
                        bcrypt.hash(password, 10)
                            .then(hashedPassword => {

                                const user = new UserModel({
                                    username,
                                    password: hashedPassword,
                                    email,
                                    firstName,
                                    lastName
                                });

                                // Store the OTP in Redis, with the user's email as the key
                                client.set(email, otp);

                                const { password, ...responseUser } = user._doc;
                                // return save result as a response
                                user.save()
                                    .then(result => res.status(201).send({
                                        msg: "User Register Successfully",
                                        OTP: otp, User: responseUser
                                    }))
                                    .catch(error => res.status(500).send({ error }))

                            }).catch(error => {
                                return res.status(500).send({
                                    error: "Enable to hashed password"
                                })
                            })
                    }
                }).catch(error => {
                    return res.status(500).send({ error })
                })

        } catch (error) {
            return res.status(500).send(error);
        }

    }
    ...

From the above code, the otpGenerator function from otp-generator package was used to generate four unique integers for the OTP and to store them in the Redis client using client.set(key, value); where value is the OTP we are storing and key is a unique identifier we will use to identify each stored value. In this case, the email of the user will be used as the key because it is unique per user.

You can check your local instance to see if the OTP is saved by querying Redis with the key/identifier. Run the command below to see the resulting OTP for a user with email example@gmail.com

    redis-cli
    GET example@gmail.com

Verifying OTP for User

So far, a unique OTP has been generated on user registration, now we need to verify the user by writing another block of code. The logic here is to check the OTP to be supplied to the code block with the one in the local Redis instance, if they match, the user will be verified. If there is no match, the user will be notified that the OTP is incorrect.

    ...
    export async function verifyUser(req, res, next) {
        try {

            const { username, email, otp } = req.body;

            // check the user existance
            let exist = await UserModel.findOne({ username: username });
            if (!exist) return res.status(404).send({ error: "Can't find User!" });

            // Retrieve the stored OTP from Redis, using the user's email as the key
            const storedOTP = await client.get(email);

            if (storedOTP === otp) {
                // If the OTPs match, delete the stored OTP from Redis
                client.del(email);

                // Update the user's isVerified property in the database
                await UserModel.findOneAndUpdate({ username }, { isVerified: true });

                // Send a success response
                res.status(200).send('OTP verified successfully');
            } else {
                // If the OTPs do not match, send an error response
                res.status(400).send('Invalid OTP');
            }
            next();

        } catch (error) {
            return res.status(500).send({ error });
        }
    }
    ...

As you can see from the code, the client.get(key) method was used to get the stored OTP and to compare it with the one input by the user. If there is a match, the OTP will be deleted using client.del(key) method to avoid any vulnerabilities and the user info isVerified will be updated to true.

Detecting Missed Verification

Sometimes, a user might register successfully but will fail to complete OTP verification. In such a case, the database will not record them as verified users yet, any attempt by such a user to log in will initiate a response with a notification for them to complete OTP verification. Also, a new code will be generated for them to use. An example code is below:

    ...
    export async function login(req, res) {

        const { email, password } = req.body;

        try {

            UserModel.findOne({ email })
                .then(user => {
                    bcrypt.compare(password, user.password)
                        .then(passwordCheck => {

                            if (!passwordCheck) return res.status(400).send({
                                error: "Don't have Password"
                            });

                            if (!user.isVerified) {
                                // Generate a random OTP using the otp-generator package
                                const otp = otpGenerator.generate(4, {
                                    lowerCaseAlphabets: false,
                                    upperCaseAlphabets: false,
                                    specialChars: false
                                });

                                // Store the OTP in Redis, with the user's email as the key
                                client.set(email, otp);

                                return res.status(400).send({
                                    error: "User is not verified, please finish verification using this OTP",
                                    OTP: otp
                                })
                            }

                            // create jwt token
                            const token = jwt.sign({
                                userId: user._id,
                                username: user.username
                            }, process.env.JWT_SECRET, { expiresIn: "24h" });

                            return res.status(200).send({
                                msg: "Login Successful...!",
                                user: user,
                                token
                            });

                        })
                        .catch(error => {
                            return res.status(400).send({ error: "Password does not Match" })
                        })
                })
                .catch(error => {
                    return res.status(404).send({ error: "Username not Found" });
                })

        } catch (error) {
            return res.status(500).send({ error });
        }
    }
    ...

In the code block above, after the login credentials has been checked and ascertained correct, the isVerified parameter will also be checked to see if the user is verified. If they are not verified, a new OTP is generated for them with a notification to complete the verification using the verify endpoint that was done initially. Once they are verified, they can successfully log in to the system.

This is a short video demonstrating how the whole code put together works.

Conclusion

Implementing OTP-based authentication and verification is an effective way to strengthen the security of your applications. By using Redis as a data store and Node.js as the backend, you can easily build a robust OTP system.

Throughout this article, we went through step-by-step instructions and code examples to guide you in building this feature. With the knowledge gained from this tutorial, you are now equipped with adequate knowledge to implement OTP-based authentication and verification in your own projects, ensuring a safer user experience.

Resources

Setting up Node.js Email Server with Nodemailer and Mailtrap

Desmond Obisi — Wed, 22 Mar 2023 01:15:27 +0000

Introduction

The email service is one of the services common to every software application. Emails are used to communicate pieces of information mostly about downtime, updates and verification of activities by the user in a software application.
In this tutorial, we will be demonstrating how to set up an email server in a Node.js application using Nodemailer and Mailtrap. First of all, let us learn the basics!

Nodemailer

Nodemailer is a module for Node.js applications that allows easy-as-cake email sending. The project started back in 2010 when there was no better option for sending email messages, today it is still the solution most Node.js users turn to by default. Underneath the hood, Nodemailer uses the Node.js core module net to create a connection to the SMTP server specified in the transport object. Once a connection is established, Nodemailer uses the SMTP protocol to send email messages by sending various commands and responses over the connection.

Here's a simplified example of how Nodemailer sends an email message:

Create a transport object that defines the SMTP server, authentication credentials, and other options.
Create a message object that defines the email message, including the sender, recipient, subject, and body.
Use the transporter.sendMail() method to send the message, passing in the message object and a callback function to handle any errors or responses.
Nodemailer uses the transport object to establish a connection to the SMTP server and send the message using the SMTP protocol. If the message is sent successfully, Nodemailer returns a response object containing information about the message, like the message ID and the response from the SMTP server.

Overall, Nodemailer provides a simple and powerful interface for sending email messages in Node.js, taking away the complexities of the SMTP protocol and allowing developers to focus on the content and delivery of their messages.

Mailtrap

Mailtrap is a service that provides a mock SMTP server for testing and development purposes. It allows developers to test their email-sending functionality without actually sending emails to real recipients. Mailtrap works by creating a temporary SMTP server that is accessible through a unique hostname and port number. When an email is sent to the Mailtrap server, it is intercepted and stored in your Mailtrap inbox instead of being sent to the intended recipient. Mailtrap also provides a web interface that allows you to view and manage your test email messages, as well as features like email forwarding and spam testing.

Here are the following steps to enable Mailtrap to work with Nodemailer:

Sign up for a Mailtrap account and create a new inbox.
Retrieve your SMTP credentials from the Mailtrap inbox settings.
Configure Nodemailer to use the Mailtrap SMTP server by creating a transport object with the SMTP settings from Mailtrap.
Use the transporter.sendMail() method to send email messages, just like you would with any other SMTP server.
Check your Mailtrap inbox to see the test email message. The message will be displayed in the inbox with its headers and content, allowing you to verify that it was sent correctly.

Overall, Mailtrap is a useful tool for testing and debugging email functionality in a safe and controlled environment. By using Mailtrap with Nodemailer, developers can test their email-sending functionality without the risk of accidentally sending test emails to real recipients or getting blocked by spam filters.

Setting up the Email Server

Now that we’ve had the basics out of the way, let us delve into a more interesting part: we will be setting up the email server using Node.js. The process follows this form;

Creating Mailtrap Account

Go to the Mailtrap website and sign up. When the sign up is completed, you will see a screen like the one below.
Click on Email Testing to get your secret credentials. Select Nodemailer as an integration option and you will get a screen like the one below.
At this point, you’d have to save the keys, it would be needed to set up the application later.

Setup Node.js Project

To set up our Node.js server, we need to create a project folder that will contain our application. For this tutorial, we will call the folder node-email-server.

To begin, we will run the following commands from our terminal.

    cd desktop && mkdir node-email-server
    cd node-email-server
    code .    /** this is to open the folder in our code editor (VSCode) */

In the root folder, run the following command to install the packages we will be using

    npm install nodemon nodemailer dotenv cors express mailgen

Nodemon—automatically restarts the node application when file changes in the directory are detected.
Cors—for providing an Express middleware that can be used to enable CORS with various options.
Express—Node.js web application framework that provides a robust set of features for web and mobile applications.
Mailgen—Node.js package that generates clean, responsive HTML e-mails for sending transactional mail.

Create a .env file in the root folder—this is where we will store the Mailtrap keys we generated earlier.

    EMAIL=<sender's email address>
    USER=<mailtrap user key>
    PASSWORD=<mailtrap password>

We will proceed to create the server file, in our case, it is the index.js file. Add the following code to the server file

    import express from 'express';
    import cors from 'cors';
    import dotenv from 'dotenv';
    import nodemailer from 'nodemailer';
    import Mailgen from 'mailgen';

    dotenv.config()   // configure our app to use env variables
    const app = express();
    /** middlewares */
    app.use(express.json());
    app.use(cors());
    app.disable('x-powered-by'); // less hackers know about our stack

    const port = process.env.PORT || 8080;
    /** HTTP GET Request */
    app.get('/', (req, res) => {
        res.status(201).json("Health Check PASS");
    });


    // create reusable transporter object using the default SMTP transport
    const transporter = nodemailer.createTransport({
        host: 'smtp.mailtrap.io',
        port: 2525,
        auth: {
            user: process.env.USER, // generated mailtrap user
            pass: process.env.PASSWORD, // generated mailtrap password
        }
    });
    // generate email body using Mailgen
    const MailGenerator = new Mailgen({
        theme: "default",
        product : {
            name: "Test Email",
            link: 'https://mailgen.js/'
        }
    })
    // define a route for sending emails
    app.post('/send-email', (req, res) => {
        // get the recipient's email address, name and message from the request body
        const { to, name, message } = req.body;
        // body of the email
        const email = {
            body : {
                name: name,
                intro : message || 'Welcome to Test Mail! We\'re very excited to have you on board.',
                outro: 'Need help, or have questions? Just reply to this email, we\'d love to help.'
            }
        }
        const emailBody = MailGenerator.generate(email);
        // send mail with defined transport object
        const mailOptions = {
            from: process.env.EMAIL,
            to: to,
            subject: 'Test Email',
            html: emailBody
        };
        transporter.sendMail(mailOptions, (error, info) => {
            if (error) {
                console.log(error);
                res.status(500).send('Error sending email');
            } else {
                console.log('Email sent: ' + info.response);
                res.send('Email sent successfully');
            }
        });
    });
    // start the server
    app.listen(port, () => {
        console.log(`Server started on port ${port}`);
    });

Firstly, we imported the packages we will be needing and created an app instance using express. We defined our middleware and port. The interesting parts are:

The email transport instance was created with nodemailer and using the SMTP details that mailtrap provided us
The function MailGenerator which we used to generate clean, responsive HTML e-mails.
The route which houses those logics we need for sending email requests to the server whenever the send-email endpoint is called.
Finally, we started the server and let the app listen to the defined port which we will use to access and test our email API.

Testing our Email Server

This is my favourite part of the whole process, testing our endpoint to see if our application actually works. For this tutorial, we will be using Postman a HTTP client used to test, debug or document API. You can set up Postman as a desktop application or use it as a web app without installing it on your local machine. Check here for more details on how to set it up with any option you want.

Making a request

Our app is running on http://localhost:8080 so our endpoint is exposed to this url: http://localhost:8080/send-email We will send a POST request to the endpoint with three parameters in the body of the request which are: to, the email address of the recipient of the mail, name, the name of the recipient and message, which is optional if we do not want to overwrite the default message in our application. Here is what our Postman request and response will look like.

If we check our Mailtrap account, we will see the mail we just sent and viola! our app works as expected. Here is what mine looks like.

Conclusion

We have learnt how to use Nodemailer and Mailtrap to set up a Node.js email server and also how these technologies work behind the scene. The code repository for this project can be found here.
Note that Nodemailer works with other SMTP providers like Gmail, Hotmail, MailGun, SendGrid, SendinBlue, etc. The list of supported services can be found here too.

If you enjoyed the article, feel free to leave a comment, give it a shout-out and share it with others. Bueno!

Documenting Node.js API using Swagger

Desmond Obisi — Mon, 20 Mar 2023 09:56:43 +0000

Introduction

API documentation is an integral part of developing software. It is an instruction manual that explains how to use an API and its services. This manual might contain tutorials, code examples, screenshots, and anything else that helps users better understand how to work with the API.

In this article, we will be learning how to document API written in Node.js using a tool called Swagger. Swagger allows you to describe the structure of your APIs so that machines can read them. The ability of APIs to describe their own structure is the root of all awesomeness in Swagger. Why is it so great? Well, by reading our API’s structure, swagger can automatically build beautiful and interactive API documentation. It can also automatically generate client libraries for your API in many languages and explore other possibilities like automated testing. Swagger does this by asking our API to return a YAML or JSON that contains a detailed description of your entire API. This file is essentially a resource listing of our API which adheres to OpenAPI Specification s.

Building our API with Node.js and Express

To start writing the API specs, we will build our API with Node.js which is a back-end JavaScript runtime environment that runs on the V8 JavaScript Engine and executes JavaScript code outside a web browser. For the purpose of simplicity, I have set up the project and it can be cloned from this GitH ub repository. To get the backend running on our local machine, we will follow these steps:

Create a new folder for the project and run this command in the root folder to clone the repository

git clone https://github.com/DesmondSanctity/node-js-swagger.git

To successfully run the code, we will need a database connection. I used a MongoDB Atlas cluster for the database and we can follow this tutorial to set up one, it is quite simple to set up. After the set up, we will get our URL and that is all we need to connect to our database from our app.
We are using JSON Web Token (JWT) to authenticate access to our API, so we will generate a secret key that will be used by our app to send and verify requests. To generate that, we will run this command anywhere in our terminal. This script will generate a random 64-bit ASCII string, that can be used for encrypting JWT tokens.

node -e "console.log(require('crypto').randomBytes(32).toString('hex'))"

We will now create a file named .env where we will store our MongoDB Atlas cluster URL and JWT secret as an environment variable. The file should look like this:

    JWT_SECRET=<your JWT secret>
    ATLAS_URI=<your MongoDB Atlas cluster URL>

Now, we are ready to run the application but first, we will install some packages and then start the application. If you cloned the GitH ub repository earlier, you just need to run these commands below:

    npm install   // To install the neccessary packages
    npm start    //  To start the application

If you are successful at this point, you will see the following message in your terminal

    > mini-blog@1.0.0 start
    > nodemon server.js

    [nodemon] 2.0.20
    [nodemon] to restart at any time, enter `rs`
    [nodemon] watching path(s): *.*
    [nodemon] watching extensions: js,mjs,json
    [nodemon] starting `node server.js`
    Database Connected
    Server connected to http://localhost:8080

Adding Swagger UI and Configurations

Now that we have our API ready, we will start defining the Swagger specs for them. There are two ways we can build Swagger documentation for our API:

Manually write the specs inside the router files or a dedicated json or yaml file in our application.
Using existing developer’s tools or packages to generate the documentation automatically.

In this tutorial, we will use the manual approach to ensure accuracy in our definitions and specifications. First, we will install two packages called "swagger-jsdoc" and "swagger-ui-express" as dependencies using this command:

npm install swagger-jsdoc swagger-ui-express --save-dev

After the installation, we will create a new file called swagger.js in the root directory of our application and paste the following code into it

    import swaggerJsdoc from 'swagger-jsdoc'
    import swaggerUi from 'swagger-ui-express'
    const options = {
      definition: {
        openapi: '3.0.0',
        info: {
          title: 'Mini Blog API',
          description: "API endpoints for a mini blog services documented on swagger",
          contact: {
            name: "Desmond Obisi",
            email: "info@miniblog.com",
            url: "https://github.com/DesmondSanctity/node-js-swagger"
          },
          version: '1.0.0',
        },
        servers: [
          {
            url: "http://localhost:8080/",
            description: "Local server"
          },
          {
            url: "<your live url here>",
            description: "Live server"
          },
        ]
      },
      // looks for configuration in specified directories
      apis: ['./router/*.js'],
    }
    const swaggerSpec = swaggerJsdoc(options)
    function swaggerDocs(app, port) {
      // Swagger Page
      app.use('/docs', swaggerUi.serve, swaggerUi.setup(swaggerSpec))
      // Documentation in JSON format
      app.get('/docs.json', (req, res) => {
        res.setHeader('Content-Type', 'application/json')
        res.send(swaggerSpec)
      })
    }
    export default swaggerDocs

We can see from the code where we defined the Open API Specification (OAS) that we will be using for our documentation: the information or details about the API, the servers we will expose it to and the routes in our app where Swagger should look for specifications for each of our API.

We can also see our swaggerDocs function that allows the app instance and port to be able to generate the documentation for using the swaggerUi and swaggerJsdoc package we installed earlier and serve it at /docs route. We can also get the JSON format using /docs.json. Lastly, we will update our server.js file to include our swaggerDocs function to always generate and update our docs whenever we run the project.

The final step before writing out the specification for each endpoint is to add the swaggerDocs function to our server.js file so we initiate swagger whenever our app starts.

    import express from 'express';
    import cors from 'cors';
    import morgan from 'morgan';
    import dotenv from 'dotenv';
    import connect from './database/conn.js';
    import userRouter from './router/user.js';
    import postRouter from './router/post.js';
    import swaggerDocs from './swagger.js'

    dotenv.config()
    const app = express();
    /** middlewares */
    app.use(express.json());
    app.use(cors());
    app.use(morgan('tiny'));
    app.disable('x-powered-by'); // less hackers know about our stack

    const port = process.env.PORT || 8080;
    /** HTTP GET Request */
    app.get('/', (req, res) => {
        res.status(201).json("Home GET Request");
    });

    /** api routes */
    app.use('/api/user', userRouter)
    app.use('/api/post', postRouter)
    /** start server only when we have valid connection */
    connect().then(() => {
        try {
            app.listen(port, () => {
                console.log(`Server connected to http://localhost:${port}`);
            })
            swaggerDocs(app, port)
        } catch (error) {
            console.log('Cannot connect to the server')
        }
    }).catch(error => {
        console.log("Invalid database connection...!");
    })

Writing our API Specifications

Now to the main task, we will write the specifications for our API that Swagger will use to generate the documentation for us. We currently have two controllers and router files in our app for user and post. Our controllers contain logic for the app while the router carries the endpoint and payload to the controller in form of requests. Let’s start defining the spec!

For User router, we will first import the packages we will be needing in the router file user.js:

    import { Router } from "express";
    const userRouter = Router();
    /** import all controllers */
    import * as controller from '../controllers/userController.js';
    import Auth from '../middleware/auth.js';

    /** All the API routes comes here*/

    export default userRouter;

Then we will write the spec for each request type viz GET, POST, PUT and DELETE. The specification is a yaml file embedded at the beginning of the route we want to document. Some key points to note are:

Open API specification instance—written at the beginning of the yaml file.
The API endpoint—the URL we will use for the request.
Request Type—indicates if it is a GET, POST, PUT or DELETE request.
Request Body—for passing our payload to the API.
Parameters—data we pass through the URL or params to the backend
Content Type—the type of content we are sending. It is passed to the HTTP header.
Schema—it contains the type of our request body, the required fields and the properties that the request body can accept.
Response—the result of the API call we made, it tells us if it failed or succeded and reports errors as well.

POST:

    /** POST Methods */
    /**
     * @openapi
     * '/api/user/register':
     *  post:
     *     tags:
     *     - User Controller
     *     summary: Create a user
     *     requestBody:
     *      required: true
     *      content:
     *        application/json:
     *           schema:
     *            type: object
     *            required:
     *              - username
     *              - email
     *              - password
     *            properties:
     *              username:
     *                type: string
     *                default: johndoe 
     *              email:
     *                type: string
     *                default: johndoe@mail.com
     *              password:
     *                type: string
     *                default: johnDoe20!@
     *     responses:
     *      201:
     *        description: Created
     *      409:
     *        description: Conflict
     *      404:
     *        description: Not Found
     *      500:
     *        description: Server Error
     */
    userRouter.route('/register').post(controller.register); // register user

    /**
     * @openapi
     * '/api/user/login':
     *  post:
     *     tags:
     *     - User Controller
     *     summary: Login as a user
     *     requestBody:
     *      required: true
     *      content:
     *        application/json:
     *           schema:
     *            type: object
     *            required:
     *              - username
     *              - password
     *            properties:
     *              username:
     *                type: string
     *                default: johndoe
     *              password:
     *                type: string
     *                default: johnDoe20!@
     *     responses:
     *      201:
     *        description: Created
     *      409:
     *        description: Conflict
     *      404:
     *        description: Not Found
     *      500:
     *        description: Server Error
     */
    userRouter.route('/login').post(controller.verifyUser,controller.login); // login in app

    /**
     * @openapi
     * '/api/user/verify':
     *  post:
     *     tags:
     *     - User Controller
     *     summary: Verify a user
     *     requestBody:
     *      required: true
     *      content:
     *        application/json:
     *           schema:
     *            type: object
     *            required:
     *              - username
     *            properties:
     *              username:
     *                type: string
     *                default: johndoe
     *     responses:
     *      201:
     *        description: Created
     *      409:
     *        description: Conflict
     *      404:
     *        description: Not Found
     *      500:
     *        desccription: Server Error
     */
    userRouter.route('/verify').post(controller.verifyUser, (req, res) => res.end()); // authenticate user

GET:

    /** GET Methods */
    /**
     * @openapi
     * '/api/user/{username}':
     *  get:
     *     tags:
     *     - User Controller
     *     summary: Get a user by username
     *     parameters:
     *      - name: username
     *        in: path
     *        description: The username of the user
     *        required: true
     *     responses:
     *      200:
     *        description: Fetched Successfully
     *      400:
     *        description: Bad Request
     *      404:
     *        description: Not Found
     *      500:
     *        description: Server Error
     */
    userRouter.route('/:username').get(controller.getUser) // user with username

PUT:

/** PUT Methods */
    /**
     * @openapi
     * '/api/user/update':
     *  put:
     *     tags:
     *     - User Controller
     *     summary: Modify a user
     *     requestBody:
     *      required: true
     *      content:
     *        application/json:
     *           schema:
     *            type: object
     *            required:
     *              - userId
     *            properties:
     *              userId:
     *                type: string
     *                default: ''
     *              firstName:
     *                type: string
     *                default: ''
     *              lastName:
     *                type: string
     *                default: ''
     *     responses:
     *      200:
     *        description: Modified
     *      400:
     *        description: Bad Request
     *      404:
     *        description: Not Found
     *      500:
     *        description: Server Error
     */
    userRouter.route('/update').put(controller.updateUser); // is use to update the user profile

DELETE:

/** DELETE Methods */
    /**
     * @openapi
     * '/api/user/{userId}':
     *  delete:
     *     tags:
     *     - User Controller
     *     summary: Delete user by Id
     *     parameters:
     *      - name: userId
     *        in: path
     *        description: The unique Id of the user
     *        required: true
     *     responses:
     *      200:
     *        description: Removed
     *      400:
     *        description: Bad request
     *      404:
     *        description: Not Found
     *      500:
     *        description: Server Error
     */
    userRouter.route('/:userId').delete(controller.deleteUser);

Testing our APIs on Swagger

After finishing our API documentation, we should be able to view our Swagger documentation and test our API using it as well. If you followed till this point, you should have a view like the one below. Our documentation is served on the /docs route.

We will make some requests using the Swagger documentation UI and see the results.

To create a User:

To create a Post:

As we have seen from the examples above, we can use the Swagger documentation to test our API, to create, read and modify data in our database. This helps to make the API understandable and easy to integrate by others. Following these examples, we can go ahead and test for other request methods like PUT to update a user or post, GET to read a user or post and DELETE to delete them from the database.

Conclusions

We can finally conclude that API documentation is a very important part of the software development cycle and that it aids collaboration and makes user experience seamless. Some of the advantages of Swagger include but are not limited to:

Synchronizes the API documentation with the server and client at the same pace.
Allows us to generate REST API documentation and interact with the REST API. The interaction with the REST API using the Swagger UI Framework gives clear insight into how the API responds to parameters.
Provides responses in the format of JSON and XML.
Implementations are available for various technologies.

Account Abstraction in Ethereum Blockchain

Desmond Obisi — Thu, 16 Mar 2023 22:41:49 +0000

Introduction

In this article, we will be learning about a recent paradigm in the Ethereum and web3 ecosystem called Account Abstraction. Account Abstraction changes how users use their account wallets in terms of blockchain interactions on the Ethereum network. We will learn about the origin, implications, pros and cons and what providers or products are already using it.

Account Types

Accounts on the Ethereum blockchain can send transactions using their ether (ETH) balances. Depending on the deployment, these accounts are either user-controlled (human) or smart contracts (code-dependent). Therefore, there are two types of accounts that a user can use to interact with the blockchain.

The Externally Owned Accounts (EOAs)
Smart Contract Accounts

The Externally Owned Accounts

The Externally Owned Accounts are made up of a cryptographic pair of keys: public and private. They help prove that a transaction was signed by the sender and prevent forgeries. Your private key is what you use to sign transactions, so it grants you custody over the funds associated with your account. You never really hold cryptocurrency, you hold private keys – the funds are always on Ethereum's ledger. This prevents malicious actors from broadcasting fake transactions because you can always verify the sender of a transaction.

EOAs are much like normal bank accounts. They have an address (IBAN) and a balance (in Ether). Essentially, the EOAs owner possesses a public key pair, of which only he knows the private key. The matching public key is the EOAs "address" - the "IBAN". Now, only the EOAs owner can transfer Ether (ie "withdraw or wire money") from that account - by using the private key in the process. In summary, EOAs are "directly owned and controlled" by their respective owners. These types of accounts are usually provided by wallet providers like Metamask, TrustWallet, SafePal etc. and they are the most in-use type of accounts by blockchain products consumers.

Contract Accounts

Contract Accounts are controlled by code executed by the Ethereum Virtual Machine. They are also referred to as smart contracts. Contract accounts have associated code and data storage, but not private keys. They “control themselves”. These accounts do so in the way determined by their smart contract code.

A contract address hosts a collection of code on Ethereum that executes functions. The functions are executed when a transaction with associated input data (contract interaction) is made. Such addresses are created when a contract is deployed to the blockchain.

Implications to the Ecosystem

In the attempt to spread the adoption of blockchain technologies and products, not just to the technically educated but also the non-technical folks, onboarding to these products and usage has been characterized by poor user experiences because blockchain technologies are associated with a lot of technicalities from setting up accounts, connecting to wallets, using dApps, transactions and recovery of funds.

Externally Owned Accounts Limitations

The use of EOAs does not help much with regards to a seamless experience as one can experience difficulties like:

Not being able to do multi-transaction (eg: swap, send etc at the same time), leads to paying gas fees for every single transaction.
No guarantee for account recovery when one loses the private keys and thereby resulting in the loss of accounts and funds as the private key is the only means to approve transactions.
Ultimately, there is little wiggle room for customization, as users can’t create custom logic to include more signers or authorize different keys to sign on to their accounts. This creates a very limiting scope for transactions.

How does Account Abstraction Improve the User's Experience?

With the advent of account abstraction and the introduction of smart contract addresses, there are lots of benefits that will improve user experience in blockchain products. These benefits include and are not limited to:

Account abstraction unifies contract accounts and EOAs. It makes user accounts more "programmable". You remove the logic of signing transactions from the account, and you “abstract” it out, hence account abstraction.
It unlocks much more flexibility, you could make batch transaction operations at the same time.
It also allows for enhanced security as you can code the conditions to be met before a transaction could be signed, set transfer limits and also perform multi-factor authentications.
Social recovery is one of the UX improvements account abstraction provides by avoiding the issue of a single point of failure with the private key.
It allows the non-custodial blockchain UX to scale.

The State of Account Abstraction

Smart contract wallets exist today but are challenging to implement because the Ethereum virtual machine (EVM) does not support them. Instead, they rely on wrapping relatively complex code around standard Ethereum transactions. Ethereum can change this by allowing smart contracts to initiate transactions, handling the necessary logic in Ethereum smart contracts instead of off-chain. Putting logic into smart contracts also increases Ethereum's decentralization since it removes the need for relayers run by wallet developers to translate messages signed by the user to regular Ethereum transactions.

Currently, there are two major proposals for implementing account abstraction to the Ethereum network:

EIP-4337

EIP-4337 is the first step towards native smart contract wallet support in a decentralized way without requiring changes to the Ethereum protocol. Instead of modifying the consensus layer to support smart contract wallets, a new system is added separately to the normal transaction gossip protocol. The way wallets work would also change under EIP-4337. Instead of each wallet re-implementing common but complex safety logic, those functions would be outsourced to a global wallet contract known as the entry point. This would handle operations such as paying fees and executing EVM code so that wallet developers can focus on providing excellent user experiences. Note that the EIP-4337 entry point contract was deployed to Ethereum Mainnet on 1st March 2023.

EIP-2938

EIP-2938 aims to update the Ethereum protocol by introducing a new transaction type, AA_TX_TYPE that includes three fields: nonce, target and data, where nonce is a transaction counter, target is the entry point contract address and data is EVM bytecode. To execute these transactions, two new instructions (known as opcodes) have to be added to the EVM: NONCE and PAYGAS. The NONCE opcode tracks the transaction sequence and PAYGAS calculates and withdraws the gas required to execute the transaction from the contract's balance. These new features allow Ethereum to support smart contract wallets natively as the necessary infrastructure is built into Ethereum's protocol. Note that EIP-2938 is currently not active. The community is currently favoring EIP-4337 because it does not require changes to the protocol.

Smart contract wallets are already available, but more upgrades are required to make them as decentralized and permissionless as possible. EIP-4337 is a mature proposal that does not require any changes to Ethereum's protocol, so it is possible that this could be implemented quickly. However, upgrades that alter Ethereum's protocol are currently not in active development, so those changes may take much longer to ship. It is also possible that account abstraction is achieved well enough by EIP-4337 that no protocol changes are ever required.

Conclusion

To onboard more blockchain users and provide a very seamless user experience to them, account abstraction has a major role to play in the way blockchain products are built and utilized. Blockchain technologies keep improving every day and we will get to see more innovations around account abstraction not only in the Ethereum ecosystem but also in other blockchain ecosystems as well.

References

Build a Jamstack Blog with Xata and Cloudinary

Desmond Obisi — Wed, 23 Nov 2022 10:55:03 +0000

Blogging as a technical expertise or professional is one way to validate our skills, share knowledge with others, and also grow ourself in any technical field. Most times setting up a blog might be so burdensome, especially when considering the tech stacks to use so as to keep it simple.

What we will be building

In this article, we will be learning how to set up a simple Jamstack blog using Xata, Cloudinary, react-markdown, and Netlify. We will be utilizing the power of Jamstack and some serverless technologies to achieve our goal.

Here is the source code for the working application.

Prerequisites and what to do

Set up our Xata account.
Set up our Cloudinary account.
Set up our application using Next.js and Chakra UI.
Basic Knowledge of JavaScript, React, or Next.js.

Setting up Xata and creating our first database table

Xata is a Serverless Data Platform. We can think of it as the combination of a serverless relational database, a search engine, and an analytics engine, all behind a single consistent API. It has first-class support for branches, a workflow for zero-downtime schema migrations, as well as support for edge caching.

To set up Xata, we first need an account. We can either use the SDK for our development or the REST API generated for our table to interact with Xata. For the purpose of this article, we will be using the Xata SDK for our development.

Go to Xata and signup to get access.
We login to our account and create a workspace. We can create as many workspaces as we want depending on our subscription plan.
Create a database inside the workspace as shown below:
Proceed to create a table and add our table items or data. We can specify data types for each item in our table depending on what we will store in them.

Our table items for the blog post are:

    title - string
    body - string
    image - string (we will be storing the image url here from cloudinary)
    tags - multiselect (this accepts array of data)

Creating Cloudinary account for our image transformation

Cloudinary is a tool that helps with the transformation of images and videos to load faster with no visual degradation, automatically generates an image and video variants, and delivers high-quality responsive experiences to increase conversions. Whatever media optimizations we need for better performance in our applications can be achieved with this tool.

To set up our Cloudinary, we also have to create an account and get our cloud space on Cloudinary. We can access Cloudinary in many ways too using APIs or SDKs. Cloudinary offers its SDKs in different languages so feel free to explore it outside Jamstack as well. For the purpose of this article, we will be using the API from our Cloudinary cloud to generate social cards for our blog posts. No need to open Figma or other design tools every time, Cloudinary got you!

Go to Cloudinary and sign up to get access to a cloud.
We will login and confirm we can see our dashboard with information like cloudname, API Keys etc. We will be needing them later.

Create Next JS app and connect Xata SDK

To set up a Next.js App, we run either of the following commands depending on our preference

    npx create-next-app@latest
     or
    yarn create next-app
     or
    pnpm create next-app

After the setup, we will run this command to start the application.

    npm run dev

We should get a screen like this:

Now we have our application up and running, let's get to the real deal. We will be initializing the Xata SDK and writing a function that uses our cloudname and image public id on Cloudinary to generate a social card for our blog posts.

Setting up APIs to interact with our Xata DB

Firstly we open our terminal and run these commands in our root directory and project directory respectively

    - Install the Xata CLI

    npm install @xata.io/cli -g

     or

    npm install @xata.io/client@latest

    - Initialize your project locally with the Xata CLI

    xata init --db https://<your workspace name>-cktogf.us-east-1.xata.sh/db/<database name>

These commands can easily be copied from our database UI in Xata. See an example below:
The last command will ask for some configurations according to our preference before it goes ahead to install the SDK. Also, it will trigger a window so we can connect our API key automatically to our project. See the example here:

Now we are all set to start using Xata in our project!

Social Image Generation for our Blog with Cloudinary

Now, let's set up our serverless function for image transformation using Cloudinary.

First, we need our cloudname, a card design that contains either our brand or whatever we want to use and identify with as our social card, and a space where we will overlay text automatically using Cloudinary function. In other words, once anybody sees this social card, they know the owner of the articles.
We can get design inspiration from this article or this Figma design. Below is my default social card and the upload to Cloudinary. The image can be our logo, brand image, or anything we want to be our brand.
Go to our project directory, create a directory component and create a file GenerateImage.js
Paste the following code inside the file

    function cleanText(text) {
        return encodeURIComponent(text).replace(/%(23|2C|2F|3F|5C)/g, '%25$1');
    }

    /**
     * Generates a social sharing image with custom text using Cloudinary’s APIs.
     *
     * @see https://cloudinary.com/documentation/image_transformations#adding_text_captions
     *
     */
    export default function generateSocialImage({
        title,
        tagline,
        cloudName,
        imagePublicID,
        cloudinaryUrlBase = 'https://res.cloudinary.com',
        titleFont = 'righteous',
        titleExtraConfig = '',
        taglineExtraConfig = '',
        taglineFont = 'caveat',
        imageWidth = 1280,
        imageHeight = 669,
        textAreaWidth = 760,
        textLeftOffset = 480,
        titleGravity = 'south_west',
        taglineGravity = 'north_west',
        titleLeftOffset = null,
        taglineLeftOffset = null,
        titleBottomOffset = 254,
        taglineTopOffset = 445,
        textColor = 'FFFFFF',
        titleColor,
        taglineColor,
        titleFontSize = 64,
        taglineFontSize = 48,
        version = null,
    }) {
        // configure social media image dimensions, quality, and format
        const imageConfig = [
            `w_${imageWidth}`,
            `h_${imageHeight}`,
            'c_fill',
            'q_auto',
            'f_auto',
        ].join(',');

        // configure the title text
        const titleConfig = [
            `w_${textAreaWidth}`,
            'c_fit',
            `co_rgb:${titleColor || textColor}`,
            `g_${titleGravity}`,
            `x_${titleLeftOffset || textLeftOffset}`,
            `y_${titleBottomOffset}`,
            `l_text:${titleFont}_${titleFontSize}${titleExtraConfig}:${cleanText(
                title,
            )}`,
        ].join(',');

        // configure the tagline text
        const taglineConfig = tagline
            ? [
                `w_${textAreaWidth}`,
                'c_fit',
                `co_rgb:${taglineColor || textColor}`,
                `g_${taglineGravity}`,
                `x_${taglineLeftOffset || textLeftOffset}`,
                `y_${taglineTopOffset}`,
                `l_text:${taglineFont}_${taglineFontSize}${taglineExtraConfig}:${cleanText(
                    tagline,
                )}`,
            ].join(',')
            : undefined;

        // combine all the pieces required to generate a Cloudinary URL
        const urlParts = [
            cloudinaryUrlBase,
            cloudName,
            'image',
            'upload',
            imageConfig,
            titleConfig,
            taglineConfig,
            version,
            imagePublicID,
        ];

        // remove any falsy sections of the URL (e.g. an undefined version)
        const validParts = urlParts.filter(Boolean);

        // join all the parts into a valid URL to the generated image
        return validParts.join('/');
    }

So from this code sample, we will be needing our cloudname and our custom image public id (we will upload it from our account on Cloudinary. It's quite straightforward to generate our social cover image. Other optional config items are fonts for our blog title and taglines. There are defaults for them in the function but we can override them wherever we call the function by passing it as a parameter. We will see this in our CreateModal component later, how we will automatically overlay text on our design image and transform it each time we create a blog post.

We are all set for our Cloudinary image transformation set-up!

Building our CRUD APIs and Interfaces using Next.js and Chakra UI

We are getting closer to our final product. Next, we will be writing CRUD (Create, Read, Update, Delete) functions we will use to interact with our Xata DB and then present the data on the user interface.

For our user interface, we will be using Next.js and Chakra UI, our APIs will be stored in the Next.js api directory, and our dynamic pages in the pages directory.

Our APIs for Interacting with Xata are as follows:

    import { getXataClient } from '../../src/xata.js'

    const xata = getXataClient()

    // allpost.js. API to get/read all our blog posts
    export default async function getAllXata(req, res) {
        const records = await xata.db.posts.getAll();
        return res.json({
            ok: true,
            posts: records
        })
    }

    // create.js. API to get create our blog posts
    export default async function createToXata(req, res) {
        let posts = req.body
        await xata.db.posts.create(posts)
        res.json({
            ok: true,
        })
    }

    // update.js. API to update a blog post
    export default async function updateToXata(req, res) {
        let id = req.body.id
        let post = {
            title: req.body.post.title,
            body: req.body.post.body,
            image: req.body.post.image,
            tags: req.body.post.tags
        }
        console.log(id, post)
        await xata.db.posts.update(id, post);
        res.json({
            ok: true,
        })
    }

    //post.js API to read one post
    export default async function getOneXata(req, res) {
        let id = req.query
        console.log(id)
        const record = await xata.db.posts.read(id);
        return res.json({
            ok: true,
            post: record
        })

    }

    //delete.js API to delete a blog post
    const deleteItem = async (id) => {
      return await xata.db.posts.delete(id)
    }
    export default async function deleteFromXata(req,res) {
      const { id } = req.body
      await deleteItem(id)
      res.json({
        ok: true,
      })
    }

We can also get these codes from our Xata workspace according to the image below:

To start designing our user interface, we will install chakra-ui, chakra-ui/icons, react-icons, react-markdown and react-tostify. We will use Chakra UI and React Icons libraries to build the user interfaces of our application, React Markdown to allow markdown in our blog textarea field and React Toastify to show updates to user when they make any API call.

    - Using NPM
    npm i @chakra-ui/react @chakra-ui/icons @emotion/react @emotion/styled framer-motion react-icons react-markdown react-toastify

    - Using Yarn
    yarn add @chakra-ui/react @chakra-ui/icons @emotion/react @emotion/styled framer-motion react-icons react-markdown react-toastify

Then we will wrap our App with providers from chakra-ui and also pass react-toastify to our App body as shown below:

    import { ChakraProvider } from '@chakra-ui/react'
    import {ToastContainer} from 'react-toastify'
    import "react-toastify/dist/ReactToastify.min.css";


    function MyApp({ Component, pageProps }) {
      return (
        <ChakraProvider>
          <Component {...pageProps} />
          <ToastContainer />
        </ChakraProvider>
      )
    }

    export default MyApp

We will proceed to create our pages inside the pages directory. We will be updating the index.js page and creating two dynamic routed pages: one in the pages/[id].js directory and another in the page/update/[id].js directory which is a sub directory to pages as shown in the previous application tree.

So we can access https://appurl/id and https://appurl/update/id when we want to view a single blog post and update a blog post respectively. Read more about dynamic routing in Next.js here
For our pages/index.js file, we will use this code below:

    import { useState, useEffect } from 'react'
    import CreatePost from '../components/CreateModal'
    import { FaGithub } from 'react-icons/fa'
    import { Icon, ButtonGroup, Text, Spacer, Link } from '@chakra-ui/react'
    import AllPosts from '../components/AllPost'

    export default function Home() {
      const [posts, setPosts] = useState([])
      useEffect(() => {
        const getData = async () => {
          await fetch('/api/allposts', {
            method: 'GET',
          }).then((response) => response.json())
            .then((data) => setPosts(data.posts));
        }
        getData();
      }, [])

      return (
        <>
          <main className='main'>
              <div className='grid'>
                <Text as='b' fontSize='20px' color='black' >
                  Blog with Xata and Cloudinary
                </Text>
                <Spacer />
                <ButtonGroup gap={3} ml={5}>
                  <CreatePost />
                  <Link href='https://github.com/DesmondSanctity/xata-cloudinary-blog' isExternal><Icon as={FaGithub} w={10} h={10} /></Link>
                </ButtonGroup>
              </div>
              <AllPosts posts={posts} />
          </main>
          <footer className='footer'>
            <a href="https://dexcode.xyz" target="_blank" rel="noopener noreferrer">
              Created by&nbsp;<b>Anon</b>&nbsp;⚡️
            </a>
          </footer>
        </>
      )
    }

For our pages/[id].js file, we will use this code below:

    import { useRouter } from 'next/router'
    import { Box, Image, Text, Icon, Link, Container, Spinner, Alert, AlertDescription, AlertIcon, AlertTitle } from '@chakra-ui/react'
    import { FaGithub } from 'react-icons/fa'
    import ReactMarkdown from 'react-markdown'
    import remarkGfm from 'remark-gfm'
    import rehypeHighlight from 'rehype-highlight'
    import rehypeRaw from 'rehype-raw'
    import rehypeSanitize from 'rehype-sanitize'
    import useSWR from 'swr'
    const fetcher = (...args) => fetch(...args).then((res) => res.json())


    const PostDetails = () => {
        const router = useRouter();
        const { id } = router.query;
        console.log({ router });
        //Getting data from xata using swr
        const { data, error } = useSWR(`/api/post?id=${id}`, fetcher)
        if (error) return (
            <div><Alert status='error'>
                <AlertIcon />
                <AlertTitle>Error!</AlertTitle>
                <AlertDescription>Failed to Load.</AlertDescription>
            </Alert></div>
        )
        if (!data) return <div><Spinner color='red.500' /></div>
        const post = data.post;

        return (
            <main className='main'>
                <div className='grid'>
                    <Text as='b' fontSize='20px' color='black' mt={5}>
                        Blog with Xata and Cloudinary
                    </Text>
                    <Link href='https://github.com/DesmondSanctity/xata-cloudinary-blog' isExternal><Icon as={FaGithub} w={10} h={10} mt={7} ml={5} /></Link>
                </div>
                <Container maxW='container.sm'>
                    <Image src={post.image} alt='blog-image' />
                    <Box p='6'>
                        <Box
                            mt='1'
                            fontWeight='light'
                            lineHeight='tight'
                            ml={5}
                        >
                            <ReactMarkdown remarkPlugins={[remarkGfm]} rehypePlugins={[rehypeHighlight, rehypeRaw, rehypeSanitize]}>{post.body}</ReactMarkdown>
                        </Box>
                    </Box>
                </Container>
            </main>
        )
    }


    export default PostDetails

We used SWR (stale-while-revalidate) to fetch our data because it is an easier way to handle fetching data at the request time in Next.js. The team behind Next.js has created a React hook for data fetching called SWR. It is highly recommended if you’re fetching data on the client side. It handles caching, revalidation, focus tracking, refetching at intervals, and more. Read more about it here.

For our pages/update/[id].js file, we will use this code below:

    import { useState, useEffect } from 'react'
    import { useRouter } from 'next/router'
    import {
        Button,
        Textarea,
        Input,
        FormControl,
        FormLabel,
        Container,
        Text,
        Spacer,
        Icon,
        Link,
        Spinner,
        Alert,
        AlertDescription,
        AlertIcon,
        AlertTitle
    } from '@chakra-ui/react'
    import { FaGithub } from 'react-icons/fa'
    import { toast } from 'react-toastify'
    import generateSocialImage from '../../components/GenerateImg'
    import useSWR from 'swr'
    const fetcher = (...args) => fetch(...args).then((res) => res.json())
    const UpdatePost = () => {
        const [title, setTitle] = useState('');
        const [body, setBody] = useState('');
        const [tags, setTags] = useState('');
        const router = useRouter();
        const { id } = router.query;
        //Get data from xata db
        const { data, error } = useSWR(`/api/post?id=${id}`, fetcher)
        if (error) return (
            <div><Alert status='error'>
                <AlertIcon />
                <AlertTitle>Error!</AlertTitle>
                <AlertDescription>Failed to Load.</AlertDescription>
            </Alert></div>
        )
        if (!data) return <div><Spinner color='red.500' /></div>
        // store data in state
        const res = data.post;

        // handle form submit
        const handleSubmit = async () => {
            //Convert string tags to array
            const newTags = tags || res.tags.toString();
            console.log(newTags)
            // Reducing number of accepted tags to 4 if user inputs more
            const tagArr = newTags.split(/[, ]+/);
            let tags_new;
            if (tagArr.length >= 4) {
                tags_new = tagArr.slice(0, 4)
            } else tags_new = tagArr;
            console.log(tags_new);
            //Generate social card with cloudinary
            const socialImage = generateSocialImage({
                title: title || res.title,
                tagline: tags_new.map(tag => `#${tag}`).join(' '),
                cloudName: 'dqwrnan7f',
                imagePublicID: 'dex/example-black_iifqhm',
            });
            console.log(socialImage);
            //Make add create request
            let post = {
                title: title || res.title,
                body: body || res.body,
                image: socialImage,
                tags: tags_new,
            }
            const response = await fetch('/api/update', {
                method: 'POST',
                headers: {
                    "Content-Type": "application/json",
                },
                body: JSON.stringify({ post, id })
            })
            if (response.ok) {
                toast.success("post updated successfully", {
                    theme: "dark",
                    autoClose: 8000
                })
                window?.location.replace('/');
            }
        }
        return (
            <main className='main'>
                <div className='grid'>
                    <Text as='b' fontSize='20px' color='black' mt={5} >
                        Blog with Xata and Cloudinary
                    </Text>
                    <Spacer />
                    <Link href='https://github.com/DesmondSanctity/xata-cloudinary-blog' isExternal><Icon as={FaGithub} w={10} h={10} mt={7} ml={5} /></Link>
                </div>
                <Container maxW='4xl' centerContent>
                    <FormControl >
                        <FormLabel>Post Title</FormLabel>
                        <Input placeholder='Title' defaultValue={res.title} onChange={e => { setTitle(e.target.value) }} />
                    </FormControl>
                    <FormControl mt={4}>
                        <FormLabel>Post Tags</FormLabel>
                        <Input placeholder='add tags separated by commas' defaultValue={res.tags} onChange={e => { setTags(e.target.value) }} />
                    </FormControl>
                    <FormControl mt={4}>
                        <FormLabel>Post Body</FormLabel>
                        <Textarea placeholder='you can use markdown here' size='sm' defaultValue={res.body} onChange={e => { setBody(e.target.value) }} />
                    </FormControl>
                    <Button colorScheme='black' variant='outline' type='submit' mt={5} onClick={() => handleSubmit()}>Submit</Button>
                </Container>
            </main>
        )
    }


    export default UpdatePost

For our other reusable components AllPosts.js and CreateModal.js, we have:

AllPost.js

    import NextLink from 'next/link'
    import { Box, Image, Badge, Flex, Spacer, ButtonGroup, Link } from '@chakra-ui/react';
    import { DeleteIcon, EditIcon, ExternalLinkIcon } from '@chakra-ui/icons'
    import { toast } from 'react-toastify'
    import ReactMarkdown from 'react-markdown'
    import remarkGfm from 'remark-gfm'
    const AllPosts = ({ posts }) => {
      const deleteData = async (id) => {
        const { status } = await fetch('/api/delete', {
          method: 'POST',
          headers: {
            'Content-Type': 'application/json',
          },
          body: JSON.stringify({ id }),
        })
        if (status === 200) {
          toast.success("post deleted successfully", {
            theme: "dark",
            autoClose: 5000
          })
        }
        window?.location.reload()
      }
      return (
        <div className='grid'>
          {
            posts && posts.map((post, index) => {
              return (
                <div className='card' key={index}>
                  <Box maxW='sm' borderWidth='1px' borderRadius='lg' overflow='hidden' mt={5} mb={2}>
                    <Image src={post.image} alt='blog-image' />
                    <Box p='6'>
                      <Flex>
                        <Badge borderRadius='full' px='2' colorScheme='teal'>
                          Tags:
                        </Badge>
                        {post.tags.length > 0 && post.tags.map((tag, index) => {
                          return (
                            <Box key={index}
                              color='gray.500'
                              fontWeight='semibold'
                              letterSpacing='wide'
                              fontSize='xs'
                              textTransform='lowercase'
                              ml='2'
                            >
                              {(index ? ',' : '') + ' ' + tag}
                            </Box>
                          )
                        })}
                        <Spacer />
                        <ButtonGroup gap={2}>
                          <NextLink href={`/update/${post.id}`} legacyBehavior passHref>
                            <Link><EditIcon /></Link>
                          </NextLink>
                          <DeleteIcon onClick={() => deleteData(post.id)} mt={1} />
                        </ButtonGroup>
                      </Flex>
                      <Box
                        mt='1'
                        fontWeight='semibold'
                        lineHeight='tight'
                        noOfLines={3}
                      >
                        <NextLink href={`/${post.id}`} legacyBehavior passHref>
                          <Link>{post.title}<ExternalLinkIcon mx='2px' /></Link>
                        </NextLink>
                      </Box>
                      <Box
                        mt='1'
                        fontWeight='light'
                        lineHeight='tight'
                        noOfLines={5}
                      >
                        <ReactMarkdown remarkPlugins={[remarkGfm]}>{post.body}</ReactMarkdown>
                      </Box>
                    </Box>
                  </Box>
                </div>
              )
            })
          }
        </div>
      )
    }

    export default AllPosts

CreateModal.js

    import { useState } from 'react'
    import {
        useDisclosure,
        Modal,
        ModalOverlay,
        ModalContent,
        ModalHeader,
        ModalBody,
        ModalCloseButton,
        Button,
        Textarea,
        Input,
        FormControl,
        FormLabel,
    } from '@chakra-ui/react'
    import { toast } from 'react-toastify'
    import generateSocialImage from './GenerateImg'

    const PostForm = () => {
        const [title, setTitle] = useState("");
        const [body, setBody] = useState("");
        const [tags, setTags] = useState("");
        //Convert string tags to array
        const newTags = tags;

        const handleSubmit = async () => {
            if (title == '' || body == '' || tags == '') {
                toast.warn("post cannot be empty", {
                    theme: "dark",
                    autoClose: 8000
                })
            } else {
                const tagArr = newTags.split(/[, ]+/);
                let tags_new;
                if (tagArr.length >= 4) {
                    tags_new = tagArr.slice(0, 4)
                } else tags_new = tagArr;
                console.log(tags_new);
                //Generate social card
                const socialImage = generateSocialImage({
                    title: title,
                    tagline: tags_new.map(tag => `#${tag}`).join(' '),
                    cloudName: 'dqwrnan7f',
                    imagePublicID: 'dex/example-black_iifqhm',
                });
                console.log(socialImage);
                //Make add create request
                let posts = {
                    title: title,
                    body: body,
                    image: socialImage,
                    tags: tags_new,
                }
                const response = await fetch('/api/create', {
                    method: 'POST',
                    headers: {
                        "Content-Type": "application/json",
                    },
                    body: JSON.stringify(posts)
                })
                if (response.ok) {
                    toast.success("post created successfully", {
                        theme: "dark",
                        autoClose: 8000
                    })
                    window?.location.reload()
                }
            }
        }
        return (
            <>
                <FormControl >
                    <FormLabel>Post Title</FormLabel>
                    <Input placeholder='Title' onChange={e => { setTitle(e.target.value) }} required />
                </FormControl>
                <FormControl mt={4}>
                    <FormLabel>Post Tags</FormLabel>
                    <Input placeholder='add tags separated by commas' onChange={e => { setTags(e.target.value) }} required />
                </FormControl>
                <FormControl mt={4}>
                    <FormLabel>Post Body</FormLabel>
                    <Textarea placeholder='you can use markdown here' size={'lg'} onChange={e => { setBody(e.target.value) }} required />
                </FormControl>
                <Button colorScheme='black' variant='outline' mt={5} onClick={() => handleSubmit()}>Submit</Button>
            </>
        )
    }

    const CreatePost = () => {
        const { isOpen, onOpen, onClose } = useDisclosure()
        return (
            <>
                <Button colorScheme='black' variant='outline' onClick={onOpen} mt={2} size={'sm'}>Create Post</Button>
                <Modal isOpen={isOpen} onClose={onClose} size={'5xl'}>
                    <ModalOverlay />
                    <ModalContent>
                        <ModalHeader>Modal Title</ModalHeader>
                        <ModalCloseButton />
                        <ModalBody>
                            <PostForm />
                        </ModalBody>
                    </ModalContent>
                </Modal>
            </>
        )
    }
    export default CreatePost

We used our generateSocialImage Cloudinary function inside the createModal component and update page to generate a social card. Here is an isolated version:

    //Generate social card
    const socialImage = generateSocialImage({
      title: title,
      tagline: tags_new.map(tag => `#${tag}`).join(' '),
      cloudName: 'dqwrnan7f',
      imagePublicID: 'dex/example-black_iifqhm',
    });
    console.log(socialImage);

We can see how we passed dynamic data to the function, our public image id, cloudname, title from our blog, and taglines from our blogpost too. Our social card will look like this when the function is executed:

If you followed up till this point, our application is almost ready! Finally, we will go ahead and add some CSS styles to the default stylesheet file in our project globals.css:

    html,
    body {
      padding: 0;
      margin: 0;
      font-family: -apple-system, BlinkMacSystemFont, Segoe UI, Roboto, Oxygen,
        Ubuntu, Cantarell, Fira Sans, Droid Sans, Helvetica Neue, sans-serif;
    }
    a {
      color: inherit;
      text-decoration: none;
    }
    * {
      box-sizing: border-box;
    }
    @media (prefers-color-scheme: dark) {
      html {
        color-scheme: dark;
      }
      body {
        color: white;
        background: black;
      }
    }
    .main {
      padding: 5rem 0;
      flex: 1;
      display: flex;
      flex-direction: column;
      justify-content: center;
      align-items: center;
    }
    .footer {
      width: 100%;
      height: 100px;
      border-top: 1px solid #eaeaea;
      display: flex;
      justify-content: center;
      align-items: center;
    }
    .footer img {
      margin-left: 0.5rem;
    }
    .footer a {
      display: flex;
      justify-content: center;
      align-items: center;
    }
    .grid {
      display: flex;
      flex-direction: row;
      align-items: center;
      justify-content: center;
      flex-wrap: wrap;
      max-width: 80%;
      margin-top: 3rem;
      margin: auto;
    }
    .card:hover,
    .card:focus,
    .card:active {
      color: #0070f3;
      border-color: #0070f3;
    }
    @media (max-width: 600px) {
      .grid {
        max-width: 100%;
        flex-direction: column;
      }
    }

We will then run our application using any of these commands to see the finished product.

   # NPM
    npm run dev

    # Yarn
    yarn run dev

Now we have our blog running on Xata and Cloudinary serverless provisions. We can go ahead and improve the user interface, make it more responsive and even add some animations too. We can also host it on services like Netlify, Vercel, and any other client-side hosting platforms we can think of. For this article, we will be deploying to Netlify.

screen-capture.mp4 - Google Drive

drive.google.com

One easy way to deploy to Netlify is to push our code to Github, connect our Github to Netlify and select the repository that contains our project. We will select the Next.js preset build command and everything will run and deploy automatically with fewer or no configurations. Check this article for more insight on deploying to Netlify.

Our live link on Netlify is ready.

Conclusion

So we were able to learn from this article how we can use Jamstack through Next.js, Cloudinary, Xata, and Chakra UI to build a blog application with CRUD functions without setting up any server. Feel free to comment on what you learned, what we did not cover, possible improvements, and also any questions you might have. I will be glad to take your feedback and answer your questions.

Resources

Here are some resources that might be helpful:

DEV Community: Desmond Obisi

Testing Risky Postgres Migrations Safely with Volume Cloning on Unikraft Cloud

Prerequisites

Building the app

Setting up the project

The schema and the API

Deploying Postgres with a persistent volume

Seeding realistic, uneven data

The risky migration, and its fix

The volume-cloning workflow

The rest of the my experiences with volume cloning

Quality checks and costs

Rounding up

Building & Deploying a Go MCP Server on Unikraft

Prerequisites

Why this is a good fit for microVMs specifically

Setting up the project

Wiring up the MCP server

The three tools

Building the container image

Writing the Kraftfile

Deploying to Unikraft Cloud

Connecting a real MCP client

Testing and troubleshooting

Conclusion

Copilot vs. Cody: All you need to know

Overview of Copilot vs. Cody

Comparison between Sourcegraph Cody and GitHub Copilot

Sourcegraph Cody's strengths over GitHub Copilot

Addressing common questions and concerns about Copilot

Conclusion

Faster Postgres Queries with Cloudflare Hyperdrive and Neon

Prerequisites

Setting up Neon Postgres

Setting up Cloudflare Hyperdrive and Workers

Writing the API services

Deploying to Cloudflare Workers

Testing and benchmarking with vs without Hyperdrive

Speed Benchmarking For Databases Queries | Opentape

Why was the Workers + Hyperdrive approach faster?

Conclusion

References

Implement OTP Verification using Redis and Node.js

Introduction

Overview of OTP-based Authentication

What is OTP-based Authentication?

Advantages of OTP-based Authentication:

Setting Up the Development Environment

Setting Up Node.js:

Setting Up Redis

Creating a New Node.js Project

Generating and Caching OTPs with Redis

Connecting to the Local Redis Instance

Generating OTP for User and Storing to Redis

Verifying OTP for User

Detecting Missed Verification

Conclusion

Resources

Setting up Node.js Email Server with Nodemailer and Mailtrap

Introduction

Nodemailer

Mailtrap

Setting up the Email Server

Creating Mailtrap Account

Setup Node.js Project

Testing our Email Server

Making a request

Conclusion

Documenting Node.js API using Swagger

Introduction

Building our API with Node.js and Express

Adding Swagger UI and Configurations

Writing our API Specifications

Testing our APIs on Swagger

Conclusions

Account Abstraction in Ethereum Blockchain

Introduction

Account Types

The Externally Owned Accounts

Contract Accounts