AWS FOR THE REAL WORLD
⏱️
Reading time: 6 minutes
🎯
Main Learning: One stack, reused for every project. Hono on Lambda, Postgres with Drizzle, a TanStack SPA on
S3 and CloudFront, and Better Auth for login.
Hey 👋🏽
we've build a lot of fullstack applications so far: - client projects
- side projects (this one, shopify apps, etc.)
- example tutorial apps
Over the past few years we switched up tech stacks a lot. That taught us what actually matters in a stack and what is just noise.
Three things I want from mine: - Simplicity. It shouldn't take much to understand it.
- Maintainable. It should still be easy to work on in a year.
- Longevity. I want the stack to live, evolve, and survive out there.
We stopped switching the tech stack. Every project gets almost the same tech stack now. And this is the one.
Sponsored
Four data stores, or one
Oracle AI Database does text extraction, embeddings, and vector search inside the engine
I built a document processor. It takes purchase orders, delivery notes, and invoices, classifies them, and pulls out the fields. Normally that
needs four data stores. S3 for the blobs, DynamoDB for the key/values, Pinecone for the vectors, Postgres for the aggregations. This one runs on
a single database.
Text extraction, summaries, embeddings, and the LLM call that returns structured JSON all run inside Oracle through
DBMS_VECTOR_CHAIN. Classification is a k-NN vote over
VECTOR_DISTANCE, so no LLM call at all. AWS just
provides the compute.
Same stack as this issue. Hono on Lambda, TanStack SPA, CDK • Runs on the Always Free tier
Read the full write-up →
Sponsored by Oracle. I built and ran the demo myself.
📚 This Week's Deep Dive
Every fullstack app needs an answer for six things: backend, database, frontend, deployment, async, and auth. Here is mine, and I give
the same answer every time now.
Backend, Hono on Lambda
One monolithic Lambda function, behind a function URL or a single API Gateway integration. Easy to test, easy to debug. The part people
sleep on is the RPC client: export the route types and your frontend gets a fully type-safe API client for free.
Database, Postgres with Drizzle
I was a big DynamoDB and Single Table Design fan. I changed my mind. NoSQL is not what 95% of applications need. Try explaining to a
stakeholder why counting users named Alex is hard. SQL forces you to think about your data up front, and Drizzle handles migrations,
studio, and queries.
Frontend, a SPA and nothing more
Vite, React, TanStack Start in SPA mode. I went full circle on this one: server rendered, then client only, then SSR, then static, and
back to client only. I don't want server-side rendering. I want a page that logs in, calls an API, and shows a loading state.
Deployment, CDK with CloudFront, S3, Lambda
Nothing fancy. CDK for the infrastructure, S3 and CloudFront for the SPA, Lambda for the API, GitHub Actions to ship it on
git push. When cold starts matter, the API moves to a
container on ECS Fargate.
Async, EventBridge and SQS
Stripe and Shopify push their events natively into EventBridge, and those events are free. Low volume gets a Lambda on the rule. Higher
volume gets an SQS queue in front so it batches.
Auth, Better Auth or Cognito
All in on AWS means Cognito, with its User Pools, Identity Pools, app clients, and hosted pages. Free to choose means Better Auth. It is
opinionated, in a good way, and the plugins cover multi-tenancy, roles and scopes, and admins.
What I dropped
AppSync, because GraphQL overcomplicates things and caching gets hard. tRPC, too much setup. VTL direct integrations, horrible to debug
and nobody on the team knows them. REST is fine.
|
How does your stack look?
I love reusing this one over and over. As devs we do need to keep learning, no argument there. But some things like REST, SQL, Lambda are settled enough that switching costs more than it gives back.
Have a great week ahead and talk to you next week!
Best Sandro & Tobi ✌🏽 |
