Aldform - How It's Built Under the Hood (Alpha)
Table of Contents▼
If reading docs isn't your thing, watch the explainer video below first.
Aldform Architecture & Submission Flow Explainer
Aldform is a form-building and submission-management platform still in alpha. You create forms visually, publish them with a short link, collect submissions with file uploads, and manage everything from a dashboard. Billing is usage-based via Polar, emails go through AWS SES, and new features roll out through a 4-tier system powered by AWS AppConfig.
Here's the core stack:
| Layer | Technology |
|---|---|
| Frontend | React 19, React Router 7, Tailwind CSS v4, Vite |
| Backend | AWS Lambda (Node.js 20), API Gateway v2 HTTP API |
| Database | PostgreSQL Supabase via Prisma ORM |
| Auth | Supabase Auth API key middleware |
| Billing | Polar SDK usage-based metering |
| AWS SES v2 | |
| File storage | AWS S3 CloudFront CDN |
| Queue | AWS SQS async post-submission work |
| Rate limiting | AWS DynamoDB distributed, per-IP |
| Feature flags | AWS AppConfig tiered rollout |
| IaC | Serverless Framework |
The backend is entirely stateless — all state lives in external services like Postgres, DynamoDB, S3, and SQS. This lets Lambda scale horizontally during spikes without coordination. A burst of 500 requests spins up 500 instances, but Supavisor (Supabase's pooler) multiplexes the Postgres connections to avoid overwhelming the DB. Prisma limits connections per instance to 5.
The critical path is form submission. When someone hits submit: rate limit via DynamoDB (30 req/min per IP), resolve the form by CUID or short code, check suspension and caps (500 submissions/mo hard cap for free users, 5 GB storage/user), parse multipart/JSON, insert into Submissions table (no transactions), upload files to S3, enqueue SQS async work, and return 201 immediately. Side effects like notifications, metering, and Polar events happen later in a worker processing batches of 10.
SQS acts as a shock absorber. A spike of 1,000 submissions writes to DB instantly and responds to users fast, while the worker handles emails and billing steadily — no thundering herd on SES or Polar. Failures are caught and logged; messages retry up to 3 times before a DLQ. If SQS is down, the handler falls back to inline processing.
Auth uses API keys, not JWTs or cookies. Registration creates a Supabase user and a Postgres User row with a CUID apiKey. Every request validates x-api-key in middleware, updating lastActiveAt non-blocking. Frontend stores it in localStorage. CORS is safe because browsers don't auto-send keys.
Two S3 buckets serve different needs: one private for submission files (pre-signed URLs, 10 MB/file limit, 10 MIME types), one public via CDN for builder media (5 MB images, content-addressed by SHA-256, 1-year cache). Storage caps are enforced via SQL aggregates on upload.
Billing integrates Polar for subscriptions and meters form.submission/file.storage events from the SQS worker. Free tier: 100/mo metered with a 500/mo hard cap. Canceled users get suspended after 7 days via cron, blocking writes but keeping data readable.
Feature rollouts use AppConfig with 4 tiers: Core (admins), Labs (approved), Early Access (India/Japan IP), GA (everyone). Config caches 60s per Lambda; updates deploy gradually (25% every 2 min over 8 min). A feature shows if your tier ≤ minTier.
The monorepo uses npm workspaces: api (Serverless Lambda), dashboard (React Vite SPA), mcp (future AI). Deploy API with serverless deploy (esbuild bundles handlers), dashboard to Vercel. All AWS resources via CloudFormation.
Rate limiting is DynamoDB atomic counters per IP with TTL cleanup — fail-open on outages. Emails sanitize templates (no scripts), render variables safely, and use stage-tracking for reliable drip campaigns. Labs approval flow stores apps in DB, emails confirmations, and unlocks Tier 1 on admin OK.
Full docs in the repo if you want deeper dives. Alpha means things evolve fast — feedback welcome.