DEV Community: HamzaNab-Dev

Building a Full-Stack AI App on Vercel + AWS ECS in One Hackathon — ChatScroll

HamzaNab-Dev — Fri, 26 Jun 2026 23:30:13 +0000

For the AWS H0 Hackathon, I built and deployed ChatScroll
— a full-stack AI knowledge management app — using Next.js
on Vercel for the frontend and ASP.NET Core 9 on AWS ECS
Fargate for the backend. Here's how the deployment
architecture works and what I learned.

The Stack

Frontend: Next.js 14 App Router + TypeScript +
Tailwind CSS deployed on Vercel

Backend: ASP.NET Core 9 API running on AWS ECS Fargate

Containerized with Docker
Images stored in Amazon ECR
Deployed automatically via GitHub Actions

Databases:

Amazon Aurora PostgreSQL (pgvector, ltree, tsvector)
Amazon DynamoDB (chat messages, TTL)

Auth: AWS Cognito with JWT verification

The CI/CD Pipeline

Every push to master triggers this automated pipeline:

git push → GitHub Actions → docker build → ECR push → ECS deploy → ✅ live

The key insight I learned: --force-new-deployment alone
does NOT pick up new Docker images. It just restarts the
service using the existing task definition.

The correct approach:

Fetch current task definition via describe-task-definition
Update the container image to the new SHA-tagged ECR image
Register a NEW task definition revision
Pass the new revision ARN explicitly to update-service

NEW_TASK_DEF=$(echo "$TASK_DEF" | jq \
  --arg IMAGE "$ECR_REPO:${{ github.sha }}" \
  '.containerDefinitions[0].image = $IMAGE | 
   del(.taskDefinitionArn, .revision, .status, 
   .requiresAttributes, .placementConstraints, 
   .compatibilities, .registeredAt, .registeredBy)')

NEW_REVISION=$(aws ecs register-task-definition \
  --cli-input-json "$NEW_TASK_DEF" \
  --query 'taskDefinition.taskDefinitionArn' \
  --output text)

aws ecs update-service \
  --cluster default \
  --service chatscroll-api \
  --task-definition $NEW_REVISION \
  --force-new-deployment

This ensures every deploy runs the exact new image.

Vercel + AWS Together

The combination of Vercel and AWS works beautifully:

Vercel handles frontend deployment, CDN, and edge caching — zero configuration needed
AWS ECS handles the backend with full control over the runtime environment
Environment variables in both Vercel and ECS task definitions keep secrets secure

The frontend on Vercel calls the backend on ECS via
REST API — clean separation of concerns with each
platform doing what it does best.

Anonymous → Authenticated Migration

One interesting challenge: users can chat and save
Scrolls before signing up. When they create an account,
their anonymous data needs to migrate to their new
Cognito identity.

I built a POST /api/users/me/migrate-anonymous endpoint:

Requires valid JWT (authenticated)
Accepts the anonymous UUID from localStorage
Runs 4 UPDATE statements atomically in Aurora
Removes the anonymous user row after migration
Frontend calls it once on first login then never again

This means users never lose their data when they sign up.

What I Built in One Hackathon

Full CI/CD pipeline from git push to live ECS deployment
Dual database architecture (Aurora + DynamoDB)
Semantic search with pgvector and 3072-dim embeddings
AWS Cognito authentication with anonymous migration
Study Mode flashcards, scroll sharing, semantic search

Try it: https://chatscroll.vercel.app
Architecture: https://chatscroll.vercel.app/aws-showcase

I created this content for the purposes of entering
the AWS H0 Hackathon.

H0Hackathon #AWS #ECS #Vercel #Docker #Aurora #DynamoDB #H0Hackathon

Why I Used Both Amazon Aurora AND DynamoDB in the Same App — AWS H0 Hackathon

HamzaNab-Dev — Fri, 26 Jun 2026 23:27:33 +0000

For the AWS H0 Hackathon I built ChatScroll — a personal
AI knowledge library. I made a deliberate architectural
choice to use TWO AWS databases for different reasons,
and I want to explain why.

The Core Insight

Not all data is the same. Different data has different
characteristics that make one database better than another.

Amazon Aurora PostgreSQL — The Knowledge Layer

ChatScroll stores "Scrolls" (saved AI answers) in Aurora
PostgreSQL because they need:

Complex queries — filter by folder, search by similarity, rank by relevance
Relational integrity — scrolls belong to folders, folders belong to users
Vector search — pgvector extension for semantic similarity using 3072-dim embeddings
Full-text search — tsvector for keyword matching
Tree structures — ltree for hierarchical folder paths

Aurora is perfect for this — it's PostgreSQL with
production-scale reliability and three powerful extensions
working together.

Amazon DynamoDB — The Chat Layer

Chat messages have completely different characteristics:

High volume — every message in every conversation
Simple access pattern — always fetched by conversationId
Time-ordered — always read chronologically
Auto-expiring — old messages should disappear after 90 days

This is a perfect DynamoDB use case:

PK: conversationId (String)
SK: {timestamp}#{messageId} (String)
TTL: expiresAt (Unix epoch, 90 days)
Capacity: PAY_PER_REQUEST

The composite sort key enables chronological reads and
time-range queries in a single DynamoDB operation. TTL
auto-expires messages with zero infrastructure — no cron
jobs, no manual deletes.

The Dual Database Pattern

Aurora PostgreSQL          DynamoDB
─────────────────          ────────
scrolls + embeddings  │    chat messages
folder hierarchy      │    composite sort keys  
user accounts         │    90-day TTL
conversation metadata │    pay-per-request scale
complex queries       │    simple key-value access

Aurora owns structure and search.
DynamoDB owns the high-volume message stream.

Each database doing what it's best at.

What I Learned

DynamoDB key design is everything. The
timestamp#messageId sort key pattern unlocks
chronological reads, time-range queries, and uniqueness
in a single attribute. Getting the key design right
upfront saved me from any schema migrations later.

Aurora pgvector at 3072 dimensions has index limits.
Both ivfflat and hnsw indexes cap at 2000 dimensions on
Aurora's pgvector version. For a personal knowledge base,
exact search works perfectly and is simpler to maintain.

Serverless v2 auto-pause is a feature. Aurora
Serverless v2 auto-pauses when idle — zero cost during
development and low-traffic periods. Perfect for a
hackathon prototype.

The Result

A production-grade dual-database architecture where:

Aurora handles all the complex relational and vector search operations
DynamoDB absorbs all the chat message write volume
Each database is used exactly as it was designed to be

Try ChatScroll: https://chatscroll.vercel.app
AWS Architecture deep dive: https://chatscroll.vercel.app/aws-showcase

I created this content for the purposes of entering
the AWS H0 Hackathon.

H0Hackathon #AWS #Aurora #DynamoDB #Vercel #H0Hackathon

How I Built a Personal AI Knowledge Base with Amazon Aurora pgvector and Next.js — AWS H0 Hackathon

HamzaNab-Dev — Fri, 26 Jun 2026 23:25:05 +0000

I built ChatScroll for the AWS H0 Hackathon — an app that
lets you save AI answers as searchable "Scrolls" using
Amazon Aurora PostgreSQL with pgvector for semantic search.

The Problem

Every day people ask AI assistants valuable questions and
get great answers — then lose them forever. Chat history
is linear, unsearchable, and ephemeral. I kept re-Googling
the same questions knowing I had already found the answer
somewhere but couldn't find it again.

The Solution

ChatScroll transforms AI conversations into a personal
knowledge library. Save any AI answer as a "Scroll",
organize it automatically, and find it later with
semantic search.

The Core Technical Challenge

Making search understand MEANING not just keywords. When
you search "blood thinner medication" it should find your
warfarin scroll even though "blood thinner" doesn't appear
in the title.

How pgvector on Aurora Solves This

Amazon Aurora PostgreSQL with the pgvector extension stores
3072-dimensional vector embeddings for every saved Scroll.

When a user saves a Scroll:

The answer text is sent to Google's gemini-embedding-001
The model returns a 3072-dimensional vector
The vector is stored in Aurora alongside the content

When a user searches:

The search query is converted to a vector
Aurora finds the most similar vectors using cosine distance
Results are ranked by semantic similarity

-- Semantic search with threshold
WHERE 1 - (embedding <=> $queryVec) > 0.5
ORDER BY embedding <=> $queryVec
LIMIT 5

Three PostgreSQL Extensions Working Together

What makes Aurora special for this use case is three
extensions working together:

pgvector — stores 3072-dim embeddings, enables cosine
similarity search between vectors

ltree — stores folder paths as dot-separated label trees
(programming.containers), enables subtree queries without
recursive CTEs

tsvector — powers full-text search with ranking via
ts_rank, combined with pgvector for hybrid search

The Dual Database Architecture

I made a deliberate choice to use TWO AWS databases:

Amazon Aurora PostgreSQL for structured data:

Scrolls with embeddings
Folder hierarchy (ltree)
User accounts (Cognito sub)
Conversation metadata

Amazon DynamoDB for chat messages:

PK: conversationId
SK: timestamp#messageId
TTL: 90-day auto-expiry
PAY_PER_REQUEST billing

This separation keeps Aurora lean for complex queries
while DynamoDB handles the high-volume chat stream.

The Result

Searching "containerization technology" correctly surfaces
the Docker scroll. Searching "blood thinner medication"
finds warfarin — no programming results contaminating it.

Semantic search scoped to the same folder category
ensures results are always relevant.

Try It

Live app: https://chatscroll.vercel.app
AWS Architecture: https://chatscroll.vercel.app/aws-showcase

I created this content for the purposes of entering
the AWS H0 Hackathon.

H0Hackathon #AWS #Aurora #pgvector #Vercel #NextJS #H0Hackathon