By Developers For Developers
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…
Building internal tools often starts with frustration. For our team, it began with two recurring problems: the opaque permissions of our project management system and the sluggish interface that made even small tasks feel like a chore. We needed a tool that could combine project management and operational reporting. Something that allowed us to track work, understand priorities, and maintain context without fighting the tool itself. At first, I tried to bend existing platforms to our will. Ji…
Most business logic ends up hardcoded deep in your app, and it’s slowly killing your codebase. What starts as a clean service grows into a bloated mess of if-else statements, feature flags, and ad-hoc patches no one dares touch. Before long, your services are "absolute units", ORM models do way more than map data, and you’re moving data back and forth like an unpaid intern, not a software engineer. How did we get here? The real problem: Business logic is treated like an afterthought When …
Introduction Astro is a modern static site generator that allows you to build fast, modern websites using a component-based architecture. More details about Astro at https://astro.build Go templates are a powerful tool for creating dynamic content and reusable components in your Go applications. More details about Go templates at https://pkg.go.dev/text/template At the point of writing this article, Astro does not support Golang as a [SSR adapter](https://docs.astro.build/en/guides/server-…
When working with web applications, it is essential to understand how data is stored in the browser. Two commonly used storage mechanisms are localStorage and sessionStorage. While both store data as key-value pairs, they differ in lifespan and scope: - localStorage: Stores data indefinitely, even after the browser is closed and reopened. - sessionStorage: Stores data only for the duration of a page session. Once the tab or browser is closed, the data is lost. A common challeng…
