Casiana
Private means no route, not just a closed door When a client's security requirements say the database may not be reachable from the internet, the interesting work isn't securing the database, it's reaching it. We were building a serverless application: a Next.js front end rendered on AWS Amplify, with its data in a Postgres database on RDS. The requirement was that the database have no public endpoint at all. Those two facts don't obviously fit together, because the part of our stack that ne…
Three sentences, three bugs The bug report was three sentences long and, as it turned out, described three different bugs. Users on a filterable result list were occasionally seeing the same entry twice as they scrolled. Support had also noticed the total count didn't always match what you could actually scroll through. And once in a while, scrolling simply stopped loading anything, no spinner, no error, no network request, until the page was refreshed. None of it threw. Nothing appeared i…
Why Elastic Beanstalk for a Next.js app Elastic Beanstalk is one of the more pragmatic ways to run a server-rendered Next.js app on AWS. It provisions EC2 instances behind an Application Load Balancer, handles scaling and health checks, and still leaves room to drop in custom nginx config, ALB rules, and CloudWatch monitoring through `.ebextensions` and `.platform`, without having to hand-build all of that from scratch. This isn't the only way to run Next.js on AWS, and it's worth saying th…
Understanding why serverless stopped paying off Serverless is an easy sell at the start of a project. No servers to patch, automatic scaling, and pricing that's billed per request instead of per hour. But as one of our client's Next.js applications grew, that same pricing model quietly turned into its biggest cost driver. Moving the project off serverless cut AWS costs by roughly 63% — with the same traffic and the same codebase. Recognizing when a serverless architecture stops fitting a…
The symptom A content platform, a directory-style site with thousands of dynamically filtered listing pages, was showing serious performance problems in a routine site audit. A full crawl of roughly 6,000 pages, combined with PageSpeed Insights (PSI) API data, turned up two things that looked unrelated at first glance: - Server response times were bad, and occasionally catastrophic. Median time-to-first-byte (TTFB) sat around 0.7 seconds, with over 1,500 pages taking longer than a s…
