A .NET Dinosaur in Web3. Day 9–10 — MVP of WishList Chain

#devjournal #nextjs #showdev #web3

"It's alive!!! It's alive!!!"

Days 9 and 10 were about infrastructure — building the bridge between the smart contract and the real world. Supabase, Drizzle, Claude API, a Telegram bot, and a Vercel deploy are classic Web2 tools. But the magic ingredient was Alchemy webhooks — the definitive Web3 piece that connected the blockchain straight into my traditional stack. All of it was new to me.

And honestly… that was the most interesting part.

What Got Built

The full pipeline:

Donation → Sepolia → Alchemy webhook →
Next.js API → Claude AI → Supabase →
Telegram Bot → notification to owner

Live at wish-list-chain.vercel.app

The app is running on Sepolia (testnet). To try it, make sure your wallet is connected to Sepolia and use test ETH only.

How to set up Sepolia correctly and get test funds: github.com/alena-dev-soft/wish-list-chain/blob/main/GETTING_STARTED.md

Supabase + Drizzle

I've worked with .NET EF (Core and Framework) for years. Drizzle is the closest thing to it in the TypeScript ecosystem — and I got familiar with it much faster than I expected.

The schema is just TypeScript:

export const donations = pgTable('donations', {
  id: uuid('id').defaultRandom().primaryKey(),
  goalId: uuid('goal_id').references(() => goals.id).notNull(),
  donorAddress: text('donor_address').notNull(),
  amount: numeric('amount').notNull(),
  txHash: text('tx_hash').notNull().unique(),
  aiComment: text('ai_comment'),
  createdAt: timestamp('created_at').defaultNow().notNull(),
});

Then npx drizzle-kit generate produces a SQL migration file. npx drizzle-kit migrate runs it against the database. That's it. Very simple.

The .NET analogy is exact: dotnet ef migrations add followed by dotnet ef database update. Same mental model, different syntax.

Supabase also has a Schema Visualizer that automatically draws relationships between tables after migration. Small thing — but satisfying.

Alchemy Webhooks — The Blockchain Calls You

This was the conceptual shift of the sprint.

Instead of polling for changes — asking "did something happen?" on a schedule — the system becomes event-driven. With Alchemy webhooks, the blockchain effectively calls you.

Every time a DreamPowerIncreased event fires on the contract, Alchemy sends a POST request to our API route with the raw log data. We decode it with viem's decodeEventLog, extract the donor address, goal index, and amount, and write it to Supabase.

The GraphQL filter in Alchemy is precise — we only listen for logs from our specific contract address. Everything else on Sepolia is ignored.

Testing locally required ngrok. This is a pattern that comes up in any webhook development — your localhost is not publicly accessible. ngrok solves it by giving you a public HTTPS URL that forwards to your local port. One command, done.

One thing worth noting: if the webhook fires and the handler throws an error, the transaction still happened. The ETH moved. The event was emitted. The blockchain doesn't care that your API crashed. Your handler needs to be idempotent — onConflictDoNothing() on the donations insert handles duplicate deliveries.

Claude API — AI Comments on Donations

Each donation triggers a call to Claude with the goal name and amount. It returns a short encouraging comment, which gets saved and later included in the Telegram notification.

The integration itself is straightforward — one API call, structured prompt, short response. At this scale, cost is negligible (around $0.002 per comment), so it's not a concern for MVP.

Telegram Bot — grammY

The bot is intentionally minimal — just outbound notifications for now. When a donation happens, it sends a message with the goal, amount, sender, and the AI-generated comment. grammY is clean and easy to work with.

Vercel — Not Just Hosting

I didn't have much experience with Vercel before this. Coming from an Azure background, I expected another cloud platform with configuration overhead.

It turned out to be much simpler. Connect a GitHub repo, set environment variables, deploy. Vercel detects Next.js automatically, builds it, and gives you a working URL. The whole process took just a few minutes.

One thing that came up during deployment:

Direct Postgres connections can behave unexpectedly in a serverless environment. It's not that they don't work — but they're not designed for short-lived execution. Each function invocation may try to establish a new connection, which doesn't always play well with how serverless functions scale. Using Supabase's transaction pooler solved the issue immediately.

This is less about Vercel specifically and more about the execution model. Instead of a long-running process managing connections, you have short-lived functions that start, execute, and stop. It's a small detail — but one that can be confusing if you approach it with a traditional backend mindset.

The Moment It All Connected

There's a point where things stop feeling like separate pieces and start behaving like a system.

For me, it was surprisingly simple.

Open the app. Connect MetaMask. Click "Donate". Confirm the transaction. Wait a bit.

And then — a Telegram notification arrives.

Just because everything is connected.

It's a strange feeling to see even a small project come alive in the cloud. You can open it, connect your wallet, send a donation to a goal — and it just works. The contract, the frontend, the notifications — all reacting to each other.

Right now everything is still pretty raw. Over the next few days I want to add:

a proper donations list
maybe some simple dashboards
and rethink how DreamPower actually grows as more donations come in

Because if the chain is supposed to reflect collective support, then the way this "power" is calculated should probably evolve as well.

What This Sprint Taught Me

The Web3 part of this project — the contract, wallet connection, on-chain reads and writes — was actually done a few days ago. What followed was everything around it. Infrastructure. Integrations. Small details that make the system usable.

And that's probably the most honest picture of what building a dApp looks like. The contract handles trust and transparency. Everything else — storage, notifications, AI, hosting — is still very much traditional engineering.