<![CDATA[sph.sh Blog]]> https://sph.sh RSS for Node Fri, 14 Aug 2026 13:52:58 GMT Fri, 14 Aug 2026 13:52:58 GMT 60 <![CDATA[Dogwood: Temporal Authorization for AI Agents]]> https://sph.sh/en/posts/dogwood-temporal-policy-language/ https://sph.sh/en/posts/dogwood-temporal-policy-language/ Fri, 07 Aug 2026 00:00:00 GMT Point-in-time authorization answers one question: is this single request allowed? For an autonomous agent that calls tools in sequence, that is necessary but not sufficient. A tool call can be valid on its own and still wrong given what the agent did just before. AWS open-sourced Dogwood on August 6, 2026 under Apache 2.0 to close that gap. Dogwood is a policy language that adds temporal conditions on top of Cedar, then compiles ("lowers") each temporal clause back to ordinary Cedar. A working knowledge of Cedar is assumed here. The focus is what Dogwood adds on top: the temporal operators, how lowering works, how Amazon Bedrock AgentCore enforces temporal policies at the gateway, and where the honest limits sit. For a refresher on Cedar itself, see the Cedar vs Rego vs OpenFGA comparis...

Continue reading...

]]> <![CDATA[Where Should Claude Code Run? Devcontainer, Codespaces, or MicroVM]]> https://sph.sh/en/posts/claude-code-lambda-microvm-dev-sandboxes/ https://sph.sh/en/posts/claude-code-lambda-microvm-dev-sandboxes/ Tue, 04 Aug 2026 00:00:00 GMT Continue reading...

]]> <![CDATA[Prisma vs Drizzle vs Kysely: Choosing a TypeScript Data Layer]]> https://sph.sh/en/posts/prisma-vs-drizzle-vs-kysely/ https://sph.sh/en/posts/prisma-vs-drizzle-vs-kysely/ Mon, 03 Aug 2026 00:00:00 GMT Every new TypeScript service on Postgres forces a decision that is expensive to reverse: how much of the SQL does a library get to own? Prisma, Drizzle, and Kysely answer differently, and the difference is not a feature list. It is about where the types come from and who writes the query. For a new Postgres-backed service on Lambda, the default is Drizzle: it owns the schema and the migrations while still leaving the query shape visible in the code. Two conditions override that default. The serverless objection to Prisma that most comparisons still repeat has expired as well, and the narrower objection that replaced it is easier to miss.

Continue reading...

]]> <![CDATA[Slow Down to Speed Up]]> https://sph.sh/en/posts/slow-down-to-speed-up-sustainable-engineering-pace/ https://sph.sh/en/posts/slow-down-to-speed-up-sustainable-engineering-pace/ Thu, 23 Jul 2026 00:00:00 GMT Skipping the cleanup to hit a date feels fast in the moment, and over a single sprint it often is. The problem is that skipping the test, the small refactor, or the flaky-pipeline fix does not delete that work. It defers the work at interest, and the interest comes back as bugs, rework, and time lost to firefighting. The intuitive read is that maintenance is time not spent shipping, so it must slow you down. Research on delivery performance points the other way: teams that keep their code and pipeline clean tend to ship more often. The recommendation here is to default to a steady, maintenance-inclusive pace, and to treat technical debt as a deliberate, scheduled decision rather than an accident.

Continue reading...

]]> <![CDATA[Who Owns This Code Now: Accountability vs Blame]]> https://sph.sh/en/posts/code-ownership-accountability-vs-blame/ https://sph.sh/en/posts/code-ownership-accountability-vs-blame/ Tue, 21 Jul 2026 00:00:00 GMT "Whoever wrote this was an idiot" is one of the most common sentences in software, and one of the least useful. It feels like analysis; it answers a question that does not matter. The moment you open a file and change one line, you own its behavior in production, no matter who typed the original code. Authorship is history. Ownership is present tense. For most engineering teams, the durable answer is team-level service ownership backed by a machine-readable registry, a CODEOWNERS file plus a service catalog, and a real on-call rotation. What makes it work is three words teams wrongly treat as synonyms: responsibility, accountability, and blame.

Continue reading...

]]> <![CDATA[Thinking in Events: A Beginner's Guide to Commands vs Events]]> https://sph.sh/en/posts/thinking-in-events-beginner-guide/ https://sph.sh/en/posts/thinking-in-events-beginner-guide/ Fri, 17 Jul 2026 00:00:00 GMT Many teams adopt a message broker, rename their RPC calls to "events," and keep thinking in commands. The rename changes the label, not the mindset. A command still says "do this now," addressed to one known worker, so nothing is actually decoupled. You pay the operational cost of messaging and get none of the benefit.

If you are comfortable with request/response HTTP and CRUD but have never built an event-driven system, one small shift makes it click. Announce facts that already happened (events) instead of issuing instructions (commands). Because that shift is a way of thinking, you can get it right before you touch any broker.

Command, Event, or Message

Three words get used as if they mean the same thing. They do not.

Continue reading...

]]> <![CDATA[Choosing a Serverless Internal Service Layer]]> https://sph.sh/en/posts/serverless-internal-service-layer-101-choosing-the-layer/ https://sph.sh/en/posts/serverless-internal-service-layer-101-choosing-the-layer/ Tue, 14 Jul 2026 00:00:00 GMT When a serverless estate grows past one team, services start calling each other. The usual answer is a cross-team grant of lambda:InvokeFunction on someone else's function ARN. That grant turns a function name into a public contract. The callee can no longer rename, split, or replace the function without breaking a consumer that lives in a repository they cannot see. The naive fix, wrapping the callee in an SDK client library, does not help: the coupling lives in the IAM policy, where no client library can reach it.

Continue reading...

]]> <![CDATA[gRPC, Protobuf, and the Wire Format Your Gateway Allows]]> https://sph.sh/en/posts/serverless-internal-service-layer-102-protocols-payloads/ https://sph.sh/en/posts/serverless-internal-service-layer-102-protocols-payloads/ Tue, 14 Jul 2026 00:00:00 GMT You have chosen this layer over the alternatives. The next question is what it can actually carry, and anyone arriving from the service-mesh world asks it within a minute of seeing the layer from part 101: why not gRPC? It is the default east-west transport there, and the question is fair.

The answer is structural. A private REST API enforces requests down to HTTP/1.1, and gRPC is carried over HTTP/2 framing. Worse, every AWS surface that does speak gRPC excludes Lambda functions as targets, so switching gateways does not rescue you. But the thing teams actually want from gRPC survives all of this, because it was never the transport. It was the schema.

Why gRPC is not on the table

Continue reading...

]]> <![CDATA[Building the Layer with a Private API Gateway]]> https://sph.sh/en/posts/serverless-internal-service-layer-103-building-the-layer/ https://sph.sh/en/posts/serverless-internal-service-layer-103-building-the-layer/ Tue, 14 Jul 2026 00:00:00 GMT You have chosen the layer (part 101) and settled what it carries (part 102). This part is the build: the private REST API, the resource policy that makes it reachable, AWS_IAM grants scoped per route, the two CDK stacks split on the ownership boundary, the SigV4 call from a Node 22 Lambda, and the operational facts about VPC-attached callers that decide whether any of it works. The substitution at its heart stays small: the caller's execution role holds execute-api:Invoke on a route ARN instead of lambda:InvokeFunction on a function ARN, and the callee's function ARN never leaves the callee's stack. The private endpoint constraint comes first, because it settles the API type before anything else.

Private endpoints are REST-only

Continue reading...

]]> <![CDATA[Identity and Encryption Between Serverless Services]]> https://sph.sh/en/posts/serverless-internal-service-layer-104-identity-encryption/ https://sph.sh/en/posts/serverless-internal-service-layer-104-identity-encryption/ Tue, 14 Jul 2026 00:00:00 GMT Part 103 built the layer: a private REST API reached over a shared execute-api interface endpoint, with every call signed with SigV4 and authorized per route. That layer answers one question well and leaves a second one wide open.

SigV4 proves which service is calling. It proves nothing about which user the call is for. Those are different questions, and a layer that only answers the first is a layer where any service can act as any user. This part closes that gap, then states precisely what the transport does and does not encrypt.

Propagating a verified subject

Continue reading...

]]> <![CDATA[Multi-Account: Cross-Account Calls and the Data Perimeter]]> https://sph.sh/en/posts/serverless-internal-service-layer-105-multi-account/ https://sph.sh/en/posts/serverless-internal-service-layer-105-multi-account/ Tue, 14 Jul 2026 00:00:00 GMT Parts 101 through 104 chose this layer, settled its protocols, built it, and secured it, all inside a single AWS account. Multi-team estates do not stay there. The team boundary tends to land on an account boundary, and that one move rewrites the authorization rules underneath the layer. Same-account, the API's resource policy and the caller's identity policy are an OR: either one can allow the call. Cross-account they become an AND: both must explicitly allow it, and silence denies. Everything else in this part follows from that flip, including the two network topologies you can choose between, the policies that carry the data perimeter, and the one guardrail you cannot write at the organization level. Every rule below is pinned to AWS documentation.

Continue reading...

]]> <![CDATA[How the Layer Fails: Throttles, Retries, and Loops]]> https://sph.sh/en/posts/serverless-internal-service-layer-106-failure-modes/ https://sph.sh/en/posts/serverless-internal-service-layer-106-failure-modes/ Tue, 14 Jul 2026 00:00:00 GMT The layer is built, its identity is settled both ways, and it spans accounts. Now the honest part: how it fails. Putting a gateway between every internal call does more than add a per-call price. It changes what failure looks like, and it quietly removes two things the direct invoke gave you for nothing: Lambda's recursive-loop circuit breaker, and any retry at all. The layer from part 103 is still worth building. The point of this part is that you now own what it took away, and the missing pieces are not the ones most write-ups warn about.

Continue reading...

]]> <![CDATA[Observability, and Where Service Meshes Are Heading]]> https://sph.sh/en/posts/serverless-internal-service-layer-107-observability/ https://sph.sh/en/posts/serverless-internal-service-layer-107-observability/ Tue, 14 Jul 2026 00:00:00 GMT A service mesh sells three things: identity, resilience, and observability. This series composed the first two out of primitives that were already in the account: identity in part 104, resilience in part 106. Observability is the third, and it is the one people assume arrives for free. Half of it does. Without a line of application code, every call writes one JSON line naming the calling service, the route, the status, and the latency. No sidecar anywhere.

Continue reading...

]]> <![CDATA[CDK TypeScript Lambda: Choosing a Bundler and cdk synth Runner]]> https://sph.sh/en/posts/cdk-lambda-bundler-runner-benchmark/ https://sph.sh/en/posts/cdk-lambda-bundler-runner-benchmark/ Sat, 11 Jul 2026 00:00:00 GMT A CDK TypeScript Lambda project looks like one tooling decision and is really three: the runtime that runs your handler, the bundler that packs it, and the runner that executes cdk synth. These layers are loosely coupled, so each has a different winner. For a greenfield project the defaults are stock nodejs22.x, esbuild through NodejsFunction, and tsx for synth; the rule behind all three is that the closer a layer sits to production runtime, the more boring its tool should be. Nine bundlers and three synth runners, measured on eight realistic handlers, justify each default and mark where you override it. Numbers come from one Linux arm64 sandbox (Node v22.22.3, aws-cdk-lib 2.261.0, medians of two or three runs), so the ratios travel while the absolute milliseconds do not.

Continue reading...

]]> <![CDATA[Nub vs Vite+: Two Rust Toolchains for Opposite Ends of the JS Stack]]> https://sph.sh/en/posts/nub-vs-vite-plus-javascript-toolchain/ https://sph.sh/en/posts/nub-vs-vite-plus-javascript-toolchain/ Sat, 11 Jul 2026 00:00:00 GMT The JavaScript toolchain is still a stack of separate parts: a package manager, a runtime, a TypeScript runner, a bundler, a test runner, a linter, and a formatter, each with its own config file and its own version drift. Two 2026 projects promise to collapse that pile into one fast Rust binary: Nub and Vite+. Both are oxc-powered, single-binary, and shipped weeks apart, so engineers keep filing them as rivals. They are not. Vite+ owns the browser-facing application pipeline; Nub owns the stock-Node process. The rule is that simple: if your build output loads in a browser, standardize on Vite+; if it runs as a Node process, reach for Nub. All the numbers below come from vendor micro-benchmarks on specific scenarios.

What Vite+ owns

Continue reading...

]]> <![CDATA[Should Stateful Resources Live in a Separate CDK Stack?]]> https://sph.sh/en/posts/cdk-stateful-stack-named-contracts/ https://sph.sh/en/posts/cdk-stateful-stack-named-contracts/ Fri, 03 Jul 2026 00:00:00 GMT A CDK app answers one layout question over and over: does this resource share a stack with the Lambda functions that use it, or get a stack of its own? The usual advice, "keep the database separate," reaches the right answer through the wrong test. State is not the criterion. A shared EventBridge bus holds no data, yet deleting it breaks every domain at once, so asking "does it hold state" misclassifies it. The criterion that predicts placement is lifecycle: a resource earns its own long-lived stack when its lifecycle outlives any single deployer, and other stacks then reach it by a well-known name. That name is a contract, and the contract sits on a coupling spectrum you can tune.

The lifecycle test

Continue reading...

]]> <![CDATA[Managing IAM Policies and Roles at Scale Without Hitting AWS Limits]]> https://sph.sh/en/posts/iam-policies-roles-at-scale-aws-limits/ https://sph.sh/en/posts/iam-policies-roles-at-scale-aws-limits/ Wed, 01 Jul 2026 00:00:00 GMT IAM has hard, quiet ceilings. A managed policy can hold only so many characters. A role can carry only so many attached policies. Inline policies share a per-entity size budget that fills up without warning. Accounts have a default role quota. Teams that lean on one shared mega-role and paste permissions through the console drift toward these ceilings, then get blocked mid-deployment with a cryptic error. The way out is structural: least privilege as the default, one policy per responsibility, scoped roles instead of a shared mega-role, and permission boundaries plus SCPs as guardrail layers.

Continue reading...

]]> <![CDATA[Backstage Build vs Buy: The Real Cost of Running Your Own IDP]]> https://sph.sh/en/posts/backstage-build-vs-buy/ https://sph.sh/en/posts/backstage-build-vs-buy/ Tue, 30 Jun 2026 00:00:00 GMT Service sprawl is the problem leaders reach for Backstage to solve: dozens or hundreds of services, and nobody can say what runs where or who owns it. The trap is that the tool demos as a quick install, so the budget gets written against the install rather than the thing that keeps it alive. The honest framing is this: Backstage is a framework you staff, not a product you buy, and the real recurring line item is a standing platform team. The decision that follows is whether to run Backstage yourself or adopt a hosted internal developer platform; without a funded platform team already in place, hosted is the default.

Continue reading...

]]> <![CDATA[Bruno API Collections in Git: A Workflow Shift, Not Free Postman]]> https://sph.sh/en/posts/bruno-api-collections-in-git/ https://sph.sh/en/posts/bruno-api-collections-in-git/ Mon, 29 Jun 2026 00:00:00 GMT Continue reading...

]]> <![CDATA[AWS Kinesis Explained: Data Streams vs Firehose vs Managed Flink]]> https://sph.sh/en/posts/aws-kinesis-family-deep-dive/ https://sph.sh/en/posts/aws-kinesis-family-deep-dive/ Sun, 28 Jun 2026 00:00:00 GMT "Kinesis" is one of the most overloaded names in AWS. The name covers four separate services that solve different problems, so a team that picks "Kinesis" from a console dropdown often discovers later that it cannot do what they assumed. When an engineer says "we'll put it on Kinesis," they almost always mean Data Streams: the raw, shard-based, ordered, replayable log. The other three are a delivery pipe, a stream-processing engine, and a video service. What follows disambiguates the four, then goes deep on the Data Streams mechanics, cost shape, and decision boundaries you need before you commit.

The four services, disambiguated

Continue reading...

]]> <![CDATA[Blameless Postmortems: A Model and a Copy-Paste Template]]> https://sph.sh/en/posts/blameless-culture-postmortem-thinking/ https://sph.sh/en/posts/blameless-culture-postmortem-thinking/ Sun, 21 Jun 2026 00:00:00 GMT The same outage keeps coming back because your incident review found a culprit instead of a cause. That is the failure mode to fix. An organization does not get safer by naming the person who typed the wrong command. It gets safer when the same wrong command can no longer take the system down. "Who did it" feels like an answer, so it closes the review. "What allowed it" stays open and forces a system change. The model that follows targets controls instead of people, with a copy-paste template and a clear line for where individual accountability still applies.

The operating model holds up across teams, but "blameless" is a culture change. The metrics that prove it landed take a few quarters to move.

Two Question Sets, Two Outcomes

Continue reading...

]]> <![CDATA[Engineering Team Documentation: Working Agreements, Definition of Done, and On-Call Docs]]> https://sph.sh/en/posts/team-documentation-ways-of-working/ https://sph.sh/en/posts/team-documentation-ways-of-working/ Sat, 20 Jun 2026 00:00:00 GMT A team's ways of working usually live in people's heads. The result is predictable: every new joiner gets a different, lossy version of "how we do things," on-call is stressful because the expectations were never written, and a key person leaving takes months of context with them. The fix is not "write more docs"; it is to treat ways-of-working as a small, named set of living documents, each with a single owner, stored next to the work, with onboarding delivered as a tracked, checklisted program rather than a buddy ritual. What follows is a taxonomy of the specific documents a healthy team owns, with a stance on what makes each one good versus its common failure mode.

Continue reading...

]]> <![CDATA[Triggering AppSync Subscriptions From Outside AppSync]]> https://sph.sh/en/posts/appsync-graphql-bff-subscriptions/ https://sph.sh/en/posts/appsync-graphql-bff-subscriptions/ Fri, 19 Jun 2026 00:00:00 GMT AWS AppSync gives you managed WebSocket subscriptions, but they fire only as a response to an AppSync GraphQL mutation. In a multi-service Backend-for-Frontend (BFF), the truth lives downstream in the order, inventory, and payments services, and those state changes never pass through an AppSync mutation. So "managing subscriptions" in a BFF is really one problem: bridging downstream events into an internal mutation backed by a NONE data source, then letting AppSync fan the payload out. The wiring below is an exploration in AWS CDK; none of it has been deployed or measured yet.

Continue reading...

]]> <![CDATA[GitHub Actions Triggers: push vs pull_request vs Merge Queue vs Release]]> https://sph.sh/en/posts/ci-steps-by-trigger/ https://sph.sh/en/posts/ci-steps-by-trigger/ Fri, 19 Jun 2026 00:00:00 GMT Push a feature commit, open a pull request, or cut a release, and many pipelines respond the same way: the full test matrix, the integration suite, and the deploy logic all fire. That uniformity is the problem. Each git event arrives at a different point in the lifecycle and carries a different security context, so a check that belongs at one trigger is either wasteful or dangerous at another. Treat the on: block as a routing table instead: match the check to the trigger so PR feedback stays fast, main stays deployable, and releases stay reproducible.

The through-line is the same one in Compressing Time to Production: protecting lead time. Running everything on every push does not make delivery safer; it slows feedback and leaks privilege into code you have not reviewed yet.

Continue reading...

]]> <![CDATA[Server-Driven UI for Native Mobile Apps]]> https://sph.sh/en/posts/server-driven-ui-mobile/ https://sph.sh/en/posts/server-driven-ui-mobile/ Fri, 19 Jun 2026 00:00:00 GMT You ship a native app, then need to change a merchandising screen, a promo banner, or a checkout step every week. Each change waits on app-store review and on users updating, and the app versions already installed stay in users' pockets for months, so you cannot roll the client back the way you redeploy a server. Server-Driven UI (SDUI) answers this by shipping a UI description instead of new native code: the recommendation here is to treat it as a scalpel for content-shaped surfaces and design the contract so old clients degrade gracefully.

The Web Analog and Mobile's Extra Constraint

Continue reading...

]]> <![CDATA[How to Reduce Lead Time from Commit to Production]]> https://sph.sh/en/posts/compressing-time-to-production/ https://sph.sh/en/posts/compressing-time-to-production/ Thu, 18 Jun 2026 00:00:00 GMT In many organizations a feature can be code-complete for days before it is live, stuck behind a review queue, a release train, or a deploy slot it missed. The metric that captures this is lead time for changes: the span from a change being committed to running in production, and most of that clock is process, not programming. The most useful move a tech lead can make is to treat lead time as the primary delivery metric and attack its biggest wait-state structurally. The order is fixed: shrink batch size, decouple deploy from release, then turn the security gate and the cross-team gate into self-service guardrails.

The Lead-Time Clock

Continue reading...

]]> <![CDATA[Shift-Left Security: Removing the Review-Queue Bottleneck]]> https://sph.sh/en/posts/security-without-the-review-queue/ https://sph.sh/en/posts/security-without-the-review-queue/ Thu, 18 Jun 2026 00:00:00 GMT In many organizations a finished change waits days in a review queue before it can ship. The queue exists because security review is treated as a uniform manual gate: every change, regardless of risk, lines up behind a human before it reaches production. The fix is to stop treating review as a per-change gate: convert it into automated, risk-based guardrails so the common case never waits on a person. The queue then disappears without weakening security, and the gate stays only where the risk earns it.

Continue reading...

]]> <![CDATA[Mobile API Versioning with a BFF: Shipping When You Can't Roll Back the Client]]> https://sph.sh/en/posts/the-client-you-cannot-roll-back/ https://sph.sh/en/posts/the-client-you-cannot-roll-back/ Thu, 18 Jun 2026 00:00:00 GMT On the server, a bad deploy is reversible in seconds; on mobile, a shipped binary is permanent, app-store review sits outside your control, and old client versions stay in use for months. That asymmetry is the design constraint that should drive your release strategy: the client is the one part of the system you cannot roll back, so both safety and speed have to move to the side you can change. The levers that follow from that constraint are a backend-for-frontend seam, consumer-driven contracts for independent deployability, backward-compatible API evolution, and a clear line for where server-driven UI earns its keep.

The Asymmetric Clock

Continue reading...

]]> <![CDATA[Lambda Durable Functions vs Step Functions: When the Orchestrator Belongs in Your Code]]> https://sph.sh/en/posts/lambda-durable-functions-vs-step-functions/ https://sph.sh/en/posts/lambda-durable-functions-vs-step-functions/ Wed, 17 Jun 2026 00:00:00 GMT Problem

Continue reading...

]]> <![CDATA[Golden Paths for a Frontend Platform: Scaffolding, Shared Packages, and a Task CLI]]> https://sph.sh/en/posts/paved-road-frontend-platform/ https://sph.sh/en/posts/paved-road-frontend-platform/ Tue, 16 Jun 2026 00:00:00 GMT When an organization runs many small frontend apps, each team starts from a different scaffold and the build config, lint rules, and deploy shape drift apart within a few sprints. The drift is not laziness: there is no single place where the standard way to start an app is also the fastest way to start one, so every team rebuilds the basics and reimplements observability, i18n, and deployment slightly differently. The fix is a thin paved road built from three primitives (a golden-path skeleton, versioned shared packages, and a task CLI) where the only metric that proves it works is voluntary adoption, not a coverage mandate.

Why Per-Team Drift Accumulates

Continue reading...

]]> <![CDATA[Hexagonal Architecture for a Presentation Service vs BFF]]> https://sph.sh/en/posts/hexagonal-presentation-service/ https://sph.sh/en/posts/hexagonal-presentation-service/ Fri, 12 Jun 2026 00:00:00 GMT A presentation service is the thin backend that sits behind a single UI fragment: it formats money and dates, resolves copy and i18n, shapes session state, and proxies one downstream domain service on the UI's behalf. Teams treat it as a dumping ground for glue code, and that glue rots into a mud-ball. Money formatting gets tangled into HTTP handlers, and the downstream client's quirks leak into business rules. The discipline that keeps this service maintainable is ports-and-adapters (hexagonal architecture), which reduces to one rule: force the domain core to depend on nothing concrete.

The Glue-Code Mud-Ball

The failure mode is predictable. A service that starts as a "thin proxy" quietly accretes responsibilities until no boundary survives:

Continue reading...

]]> <![CDATA[Server-Side Micro-Frontend Composition: One Page, Many Teams]]> https://sph.sh/en/posts/server-side-micro-frontend-composition/ https://sph.sh/en/posts/server-side-micro-frontend-composition/ Tue, 09 Jun 2026 00:00:00 GMT A single high-traffic page, such as a checkout or storefront, often needs contributions from several teams who must ship independently. A frontend monolith forces them onto one release train, so one team's slow build or broken test blocks every other team's deploy. The mechanism that assembles the page is the easy part; the genuinely hard problem is the ownership boundary plus a versioned consistency contract that keeps many teams visually and behaviourally aligned without a coordinated release. For a multi-team, SEO-sensitive page where first paint matters, the default is server-side composition; client-side composition and iframes win narrower cases.

Continue reading...

]]> <![CDATA[Code Architecture by Init Amortization: Lean on Lambda, Heavy Only When Earned]]> https://sph.sh/en/posts/code-architecture-init-amortization/ https://sph.sh/en/posts/code-architecture-init-amortization/ Wed, 03 Jun 2026 00:00:00 GMT Problem

Part 1 answered the topology half of the Lambda question: single responsibility is a code principle, and how many functions to deploy is a separate topology decision. The other half is how much code architecture belongs inside a given runtime: how much OOP, dependency injection, and framework weight. The answer mirrors Part 1's "earn the exception" shape: default to lean functional handlers, then earn heavier structure as each runtime's init-amortization permits. The variable that decides it is how many invocations one initialization serves.

Continue reading...

]]> <![CDATA[Effect on AWS Lambda: Building a URL Shortener with SST and DynamoDB]]> https://sph.sh/en/posts/effect-lambda-link-shortener/ https://sph.sh/en/posts/effect-lambda-link-shortener/ Wed, 03 Jun 2026 00:00:00 GMT A typical TypeScript Lambda handler accretes cross-cutting work inline: JSON.parse(event.body), ad-hoc if (!body.url) checks, URL validation in a try/catch, then business logic wrapped in more try/catch blocks where each catch re-derives an HTTP status and re-serializes an error body. The non-obvious cost is not the boilerplate; it is that statuses and error shapes get chosen at the call site, so they drift. Worse, the only way to test the logic is to either hit real AWS or hand-mock the SDK client. Effect collapses that pile into a thin adapter over a typed program. One buildable artifact, a URL shortener on Lambda and DynamoDB wired with SST v4, shows exactly what each Effect primitive buys you.

Continue reading...

]]> <![CDATA[AWS Lambda: Single-Purpose Functions vs Lambdalith]]> https://sph.sh/en/posts/lambda-function-granularity-responsibility-scope-domain/ https://sph.sh/en/posts/lambda-function-granularity-responsibility-scope-domain/ Wed, 03 Jun 2026 00:00:00 GMT Problem

When teams build an HTTP API on AWS Lambda, an early decision quietly sets the shape of everything that follows: how many functions to deploy. Tutorials map one route to one function, so teams copy that and reach 60 functions per service, each with its own IAM role, bundling config, and a slice of a sprawling template. The consolidation backlash answers with a "Lambdalith": one function per service running an in-process router. My position is the opposite of that backlash. Default to single-purpose functions (one per route, one per event), and treat the single-domain Lambdalith as a consolidation you earn, not a starting point. The spectrum comes first, then the platform forces (cold start, concurrency, IAM, observability) that decide where on it you land...

Continue reading...

]]> <![CDATA[Scrum vs Kanban vs Scrumban for AI-Assisted Teams]]> https://sph.sh/en/posts/scrum-kanban-scrumban-ai-driven-teams/ https://sph.sh/en/posts/scrum-kanban-scrumban-ai-driven-teams/ Tue, 02 Jun 2026 00:00:00 GMT AI assistants now write a growing share of the code. Engineering leaders still burn weeks arguing whether to adopt Scrum, Kanban, or some other agile framework, then copy another company's ceremonies and wonder why nothing flows faster. The trap is treating the framework name as the decision; the name is a wrapper around four feedback loops, and those loops are what actually move work. My stance is that an AI-assisted team almost never needs a branded methodology: it needs to tune how work flows, how often you re-steer, how much work runs in parallel, and how output gets reviewed. That decision lens outlives the next framework fad and accounts for AI moving the bottleneck off typing code.

Continue reading...

]]> <![CDATA[Zod Branded Types for PII Protection: Compile-Time Log Safety]]> https://sph.sh/en/posts/zod-brands-prevent-pii-logging/ https://sph.sh/en/posts/zod-brands-prevent-pii-logging/ Thu, 28 May 2026 00:00:00 GMT Structured logs leak PII through three near-identical call sites: logger.info({ user }), metrics.increment("login", { email }), and tracer.startActiveSpan("auth", { attributes: { ip } }). Most teams add Pino redact.paths or a cloud-side scrubber to catch these. Those defenses are last-line and list-based, and they drift silently as schemas evolve. Effect-TS handles the same problem at runtime, with Redacted wired into its Logger. Pino covers a slice of it at compile time with LogFnFields, banning specific keys via never. Rust's secrecy crate takes a third route: the wrapper never implements Display.

Continue reading...

]]> <![CDATA[The Staff Engineer Solver Archetype: An Operating Model]]> https://sph.sh/en/posts/solver-track-staff-engineer-operating-model/ https://sph.sh/en/posts/solver-track-staff-engineer-operating-model/ Tue, 26 May 2026 00:00:00 GMT The informal fast track most engineering organisations end up with

In most engineering organisations past a certain size, a second track quietly forms next to the standard SDLC: work that is too strategic to wait, too uncertain to schedule, too narrow to staff a full team for. The pattern repeats independently of industry: executive sponsorship, one or two senior engineers, a runway measured in months, and a small set of recognisable outcomes. Most of these tracks fail not because of execution but because nobody wrote the operating model before the first project entered the lane.

Continue reading...

]]> <![CDATA[How Aurora Serverless v2 Works: Architecture Deep Dive]]> https://sph.sh/en/posts/aurora-serverless-v2-architecture/ https://sph.sh/en/posts/aurora-serverless-v2-architecture/ Mon, 25 May 2026 00:00:00 GMT Aurora Serverless v2 is often introduced as if it were a separate database product, distinct from provisioned Aurora. That framing leads engineers to wrong assumptions: that read replicas autoscale by count, that scaling events drop connections, that every scale-up warms a cold cache. None of those hold, though a fourth is partially true since November 2024: scale-to-zero does imply a cold-start path. Underneath, Serverless v2 is a scaling daemon and a billing wrapper over the same Aurora compute and storage that provisioned clusters run on.

A note on the name

Continue reading...

]]> <![CDATA[Phronesis and AI Coding Agents: The Skill the Model Cannot Give You]]> https://sph.sh/en/posts/phronesis-and-ai-coding-agents/ https://sph.sh/en/posts/phronesis-and-ai-coding-agents/ Mon, 25 May 2026 00:00:00 GMT AI coding agents have collapsed the cost of writing code to roughly zero. The cost of knowing when and how much code to write has not moved. Most of the current "AI productivity" debate is people talking past each other because they are mixing those two skills together. One frame, borrowed from Aristotle, separates them cleanly; read Mario Zechner, Addy Osmani, Kent Beck, Simon Willison, METR, and Steve Yegge through it and the apparent contradictions dissolve into a single disagreement. On that disagreement, Zechner is closer to right than Yegge is, but Yegge's foil sharpens the point rather than blunting it.

The Two Skills the Debate Keeps Confusing

Continue reading...

]]> <![CDATA[GitHub Environments: Manual Approval Gates for Deployments]]> https://sph.sh/en/posts/github-environments-approval-gates/ https://sph.sh/en/posts/github-environments-approval-gates/ Tue, 19 May 2026 00:00:00 GMT Production deploys need a human in the loop, and most teams reach for the wrong primitive. The common shapes are a workflow if: condition that checks a label, a marketplace manual-approval action that blocks on issues: write, or a workflow_dispatch button that any contributor can fire. Build the artifact once from main, deploy it to staging automatically, and promote the same artifact to production only after a PM or QA approves at a GitHub Environment gate. Same artifact, two environments, one approval. That gate covers the deploy credential and the human action at once, and it leaves an audit row tied to the run.

The Environment object

Continue reading...

]]> <![CDATA[Build a RAG Agent with AWS Bedrock and CDK]]> https://sph.sh/en/posts/aws-bedrock-rag-cdk-port/ https://sph.sh/en/posts/aws-bedrock-rag-cdk-port/ Tue, 12 May 2026 00:00:00 GMT AWS markets Bedrock Agent plus Knowledge Bases plus OpenSearch Serverless as the managed-RAG path: ship retrieval-grounded chat without owning the retrieval code. I ported the DigitalOcean rag-assistant blueprint shape onto AWS-native services with CDK in TypeScript, then deployed it end-to-end and watched the first run fail. The AWS Bedrock managed-RAG stack works with CDK, but two doc-gap traps will fail your first deploy: a cross-region inference-profile IAM hole, and the absence of an automatic ingestion job.

Architecture mapping

Continue reading...

]]> <![CDATA[Amazon Bedrock Knowledge Bases Explained: Data Sources and Vector Stores]]> https://sph.sh/en/posts/bedrock-knowledge-bases-anatomy/ https://sph.sh/en/posts/bedrock-knowledge-bases-anatomy/ Tue, 12 May 2026 00:00:00 GMT The default behind the console wizard

Amazon Bedrock Knowledge Bases packages a connector, a chunker, an embedding model, a vector store, and a retrieval API into one managed surface. The Confluence connector is a vector-store decision in disguise. AWS documents that Confluence Cloud is "currently" only available with the OpenSearch Serverless vector store, and the same lock-in applies to SharePoint and Salesforce. That single constraint splits the architecture into two paths, and choosing before you wire the connector saves a rewrite.

Continue reading...

]]> <![CDATA[HMAC: What It Is, How It Works, and When It Is the Wrong Tool]]> https://sph.sh/en/posts/hmac-explainer-when-to-use/ https://sph.sh/en/posts/hmac-explainer-when-to-use/ Tue, 12 May 2026 00:00:00 GMT Webhook receivers, signed download URLs, and internal service calls all share one question: did this request actually come from the party we share a secret with, and did it arrive intact? A constant-time string compare, raw-body hashing, and clock-skew handling have to be right at the same time, or the protection is decorative. For symmetric-trust integrity where both sides can hold the same secret, HMAC-SHA-256 with the standard library's constant-time compare is the right default.

HMAC defined

Continue reading...

]]> <![CDATA[Kafka vs SNS/SQS/EventBridge: When to Migrate and How]]> https://sph.sh/en/posts/kafka-or-event-bus-migration-signals/ https://sph.sh/en/posts/kafka-or-event-bus-migration-signals/ Mon, 11 May 2026 00:00:00 GMT Teams running on SNS+SQS, EventBridge, Pub/Sub, or Service Bus eventually hit a wall and ask whether they should move to Kafka. The hard part is that "it depends" answers never enumerate which conditions actually matter, so the decision drifts toward whichever vendor doc was read last. Kafka solves durability, replay, ordering, and sustained throughput. Stay on the managed event bus until two or more concrete signals fire, then migrate incrementally with a transactional outbox rather than a rip-and-replace.

Seven signals justify the move, five counter-signals argue against it, and the migration playbook below moves one event type at a time so rollback stays possible at every step.

Signals That Push You to Kafka

Continue reading...

]]> <![CDATA[Deploying AWS Bedrock AgentCore with CDK: a quickstart]]> https://sph.sh/en/posts/agentcore-cdk-quickstart/ https://sph.sh/en/posts/agentcore-cdk-quickstart/ Tue, 05 May 2026 00:00:00 GMT The setup

A companion post walks through what AgentCore Runtime is at the architecture level: container, identity, memory, gateway. The deployment question starts where that ends: AgentCore is now reachable from CDK through @aws-cdk/aws-bedrock-agentcore-alpha, so what does a working trial look like end-to-end? Short answer: take the alpha L2 and pin its version. The stack code stays short because the construct carries most of the weight, but a few IAM and Marketplace prerequisites need to land before the first invoke returns.

What we are building

A single CDK stack that deploys a minimal Strands agent on AgentCore Runtime in eu-central-1, plus the build script and the boto3 invoke helper. The full layout:

[code block]

Continue reading...

]]> <![CDATA[Set Up Claude as a PR Reviewer with the Official GitHub Action]]> https://sph.sh/en/posts/claude-code-action-pr-reviewer-setup/ https://sph.sh/en/posts/claude-code-action-pr-reviewer-setup/ Mon, 04 May 2026 00:00:00 GMT Adding AI-assisted code review to a GitHub repository starts with one choice: an ad-hoc LLM integration, or a maintained action. The maintained path already handles access control and prompt-injection sanitization; the ad-hoc one leaves both to you. anthropics/claude-code-action v1 is the default worth starting from, configured with a pull_request trigger, a read-only tool allowlist, a pinned model, and a merge gate that stays human.

The workflow file itself is short. The judgment sits in what surrounds it: which trigger fires it, which permissions it gets, which tools the model may call, and what a large PR costs per review.

The recommended setup

Continue reading...

]]> <![CDATA[AWS Lambda Cold Start Optimization in TypeScript: 5 Anti-Patterns]]> https://sph.sh/en/posts/aws-lambda-typescript-anti-patterns/ https://sph.sh/en/posts/aws-lambda-typescript-anti-patterns/ Tue, 28 Apr 2026 00:00:00 GMT Teams move from NestJS, Spring, or .NET monoliths to AWS Lambda and bring patterns that work in long-running services. Bundles bloat, cold starts grow, and the platform's economics fight back. Lambda is a function, not a microservice; monolith OO/DI patterns inflate bundles and tank cold starts.

Five habits cause most of the damage: DI containers, non-modular AWS SDK imports, god-handler service classes, synchronous secret fetches at module top, and heavy ORMs.

Continue reading...

]]> <![CDATA[Deploying a WASM Image-Resize Module to Cloudflare Workers]]> https://sph.sh/en/posts/cloudflare-workers-wasm-image-resize/ https://sph.sh/en/posts/cloudflare-workers-wasm-image-resize/ Wed, 22 Apr 2026 00:00:00 GMT A POST /resize?w=800&q=85 handler that takes a JPEG in the body and returns a resized JPEG is the simplest non-toy test of Cloudflare Workers + WASM as an image pipeline host. The design pushes three edge-platform limits at once: compiled binary size, per-isolate memory, and per-request CPU time. Read in order, the published limits already settle most of the question. The Free tier is out on CPU time alone, and on the Paid tier the design fits for one image per request, inside a bundle budget that leaves little room for a second codec.

Continue reading...

]]> <![CDATA[WebAssembly Use Cases: Browser, WASI Server, and Edge Compute]]> https://sph.sh/en/posts/webassembly-101/ https://sph.sh/en/posts/webassembly-101/ Tue, 21 Apr 2026 00:00:00 GMT WebAssembly conversations keep talking past each other because a single word covers three very different architectural bets. A frontend engineer hears "makes the web fast," a backend engineer hears "replaces containers," a platform engineer hears "powers the edge," and all three are partially right. Match your problem to one of the three before evaluating a single runtime; if none of them describes your architecture, the honest answer is to skip Wasm for now.

WASM in 30 Seconds

One bytecode, three separate bets: performance in the browser, a WASI runtime on the server, compute at the edge. Each bet answers a different question.

Continue reading...

]]> <![CDATA[EventBridge Cross-Account Fan-Out: One Producer, Isolated Consumers]]> https://sph.sh/en/posts/event-fanout-isolated-consumer-accounts/ https://sph.sh/en/posts/event-fanout-isolated-consumer-accounts/ Mon, 20 Apr 2026 00:00:00 GMT A producer service collects new downstream consumers like barnacles. Every new team that wants events adds another if enabled(x) publish(x) branch, and every new consumer needs a producer deploy. The branches are a junction box pretending to be application code, and the blast radius of any mistake sits in the same account as payments.

The default that removes those branches: one event, many consumers, each in its own AWS account with its own SQS and DLQ. Rules on the event bus carry the fan-out, so the producer's code stays out of it. Audit, Customer Center, Marketing and every consumer after them get the same topology. A different backbone earns its place only when ordering, replay, or raw throughput demands it.

Continue reading...

]]> <![CDATA[wasmCloud and NATS: Making the Event Bus Portable]]> https://sph.sh/en/posts/wasmcloud-nats-event-bus-portability/ https://sph.sh/en/posts/wasmcloud-nats-event-bus-portability/ Mon, 20 Apr 2026 00:00:00 GMT In an event-driven system, vendor lock-in lives in the bus topology rather than in the runtime. The runtime is replaceable in weeks; the topology is replaceable in quarters. Serverless lock-in debates mostly skip that split and compare Lambda against Cloud Functions or Workers against Containers, with the event bus filed under plumbing.

Continue reading...

]]> <![CDATA[Handling Long-Running API Requests in Web and Mobile Apps]]> https://sph.sh/en/posts/async-api-patterns-web-mobile/ https://sph.sh/en/posts/async-api-patterns-web-mobile/ Sat, 18 Apr 2026 00:00:00 GMT Where Synchronous Endpoints Break

Most product APIs begin with plain synchronous request and response. It works for login, for reading a user record, for a simple search. Then one endpoint needs to do real work.

Consider a payment authorization that takes six to ten seconds. A spinner that long drops checkout conversion; users retry the button, and without an idempotency layer the backend accepts a duplicate charge.

Continue reading...

]]> <![CDATA[One AI Coding Config for Claude Code, Cursor, Copilot, and Codex]]> https://sph.sh/en/posts/model-agnostic-ai-coding-setup/ https://sph.sh/en/posts/model-agnostic-ai-coding-setup/ Sat, 18 Apr 2026 00:00:00 GMT Teams rarely converge on a single AI coding tool; a repo that only works with one of Claude Code, Codex, Copilot, Cursor, or OpenCode loses every contributor who picked a different tool. The layout below keeps one file authoritative: AGENTS.md as the single source of truth, symlinks or @-imports for every other tool's expected filename, and MCP for cross-tool tooling. It breaks in three places: skills, slash commands, and Windows symlink traps.

The Problem

A team adopts Claude Code, then a new hire prefers Cursor. The CLAUDE.md at the repo root sits quiet while Cursor reads .cursor/rules/, so someone hand-copies the rules. Later the same rule lands in AGENTS.md with slightly different wording. Three files drift, and nobody owns the sync.

Continue reading...

]]> <![CDATA[Optimistic UI vs Decoupled Flows: UX Patterns for Async Backends]]> https://sph.sh/en/posts/ux-event-based-backends-optimistic-to-decoupled/ https://sph.sh/en/posts/ux-event-based-backends-optimistic-to-decoupled/ Sat, 18 Apr 2026 00:00:00 GMT An event-based backend moves work out of the request/response cycle: the client submits, the server accepts and enqueues, and the state change happens some time later. A spinner signals that the system is actively producing the result for this session; but in an event-based flow there is no in-progress work on the client to wait on. The UI conflates two distinct states (the backend has queued the work versus the backend is computing the result right now), and those two states carry different promises to the user.

Continue reading...

]]> <![CDATA[Idempotency: A Beginner's Guide to Safe Retries in APIs]]> https://sph.sh/en/posts/idempotency-beginners-guide/ https://sph.sh/en/posts/idempotency-beginners-guide/ Thu, 09 Apr 2026 00:00:00 GMT Idempotency is the property that makes running the same operation multiple times produce the same result as running it once. It is load-bearing for any API that handles money, side effects, or distributed work. The underlying transport (HTTP, mobile radios, message brokers) retries on failure regardless of intent, and a non-idempotent endpoint turns every retry into a duplicate write: double charges, duplicate orders, jobs fulfilled twice.

Continue reading...

]]> <![CDATA[Mobile Ad Attribution for Subscription Apps: SKAN 4 and AdAttributionKit]]> https://sph.sh/en/posts/mobile-ad-attribution-subscription-conversion/ https://sph.sh/en/posts/mobile-ad-attribution-subscription-conversion/ Thu, 09 Apr 2026 00:00:00 GMT Subscription app attribution has to connect an ad click on Meta, Google, or TikTok to a validated paid subscription event in the data warehouse. The install is only an intermediate signal on the way there, and SKAN 4 together with ATT make the click-to-install link much harder to observe than the install-to-subscription link. A single pipeline has to reconcile three independently clocked sources (SKAN postbacks, mobile app events, payment-provider receipts) so marketing, finance, and product can work off the same numbers.

Continue reading...

]]> <![CDATA[RevenueCat Alternatives in 2026: Choosing a Subscription Platform for Mobile Apps]]> https://sph.sh/en/posts/revenuecat-alternatives-comparison-2026/ https://sph.sh/en/posts/revenuecat-alternatives-comparison-2026/ Thu, 09 Apr 2026 00:00:00 GMT Mobile subscription infrastructure is a layered choice: the SDK and entitlement engine on-device, the billing/catalog/tax layer behind it, and the paywall, experimentation, and analytics tools on top. RevenueCat is the default for the first layer, and it covers the other two well enough for most teams. Its 1% MTR fee on gross revenue changes the math past roughly \$100k MTR, and the 2026 market has alternatives that beat the default on one axis each: Adapty on paywall experimentation, Qonversion on analytics-per-dollar, Apphud on win-back flows, Chargebee and Stripe Billing on cross-platform billing.

Continue reading...

]]> <![CDATA[Zapier MCP Permission Control: Scoping AI Agent API Access]]> https://sph.sh/en/posts/zapier-mcp-api-permission-control/ https://sph.sh/en/posts/zapier-mcp-api-permission-control/ Sun, 05 Apr 2026 00:00:00 GMT Direct MCP server integrations give AI agents broad, often uncontrolled access to APIs. A previous post demonstrated how to build custom scoped proxies to enforce least-privilege access. Zapier MCP offers a managed alternative: action-level whitelisting, centralized credential management, and human-in-the-loop approval, all without writing proxy code.

For a team wiring an agent into three or more apps with standard operations, that managed layer is the better default. A hand-built proxy earns its maintenance cost only when a single integration needs deep customization or a sub-100ms budget.

Uncontrolled API Permissions in MCP

Continue reading...

]]> <![CDATA[Mobile IAP & Paywall Strategies - App Store, Play Store, RevenueCat]]> https://sph.sh/en/posts/mobile-iap-paywall-strategies/ https://sph.sh/en/posts/mobile-iap-paywall-strategies/ Thu, 02 Apr 2026 00:00:00 GMT Mobile in-app purchase implementation spans two incompatible billing systems (Apple App Store and Google Play), each with distinct commission rules, receipt formats, and server-side validation requirements. Gaps in that validation pipeline allow jailbroken or rooted devices to claim entitlements without payment, and a single rejected paywall flow can block a subscription launch. For a cross-platform app, the default that holds is standard store billing behind a RevenueCat abstraction. Grant entitlements from server-verified state; a client-side check is not enough. On the RevenueCat path that validation runs on RevenueCat's servers, and on a direct store integration it runs on yours.

Continue reading...

]]> <![CDATA[Cross-Platform Subscription Entitlements: Syncing Web, iOS, and Android]]> https://sph.sh/en/posts/omnichannel-entitlement-sync/ https://sph.sh/en/posts/omnichannel-entitlement-sync/ Thu, 02 Apr 2026 00:00:00 GMT When a product sells subscriptions across web, iOS, and Android, each platform emits its own subscription events with its own schema, lifecycle, and delivery delay. An entitlement synchronization layer is the piece that turns those heterogeneous events into a single consistent answer to "what can this user access right now?". A naive per-platform handler drifts out of sync within hours; the underlying problem is distributed state, not webhook plumbing.

The design that holds up is a narrow one: normalize every provider event at the ingress point, publish it to an AWS EventBridge bus, and let one idempotent consumer own the DynamoDB entitlement store your application reads. Refunds, family sharing, and grace periods are where that pipeline earns its keep.

Continue reading...

]]> <![CDATA[Payment Providers & Compliance: Stripe, Adyen, Chargebee, Paddle, PayPal Compared]]> https://sph.sh/en/posts/payment-providers-comparison-compliance/ https://sph.sh/en/posts/payment-providers-comparison-compliance/ Thu, 02 Apr 2026 00:00:00 GMT Accepting payments globally involves three layers that do not behave the same way: transaction processing, tax compliance, and legal responsibility for the sale. A SaaS team that picks a provider by transaction fee alone usually discovers the other two layers only when a VAT audit, a PSD2/SCA reject rate, or a chargeback policy exposes them. The choice is really a decision about which layers the team operates and which ones it outsources.

Continue reading...

]]> <![CDATA[Subscription Lifecycle Management: Upgrades, Dunning, and Fraud Detection]]> https://sph.sh/en/posts/subscription-lifecycle-management/ https://sph.sh/en/posts/subscription-lifecycle-management/ Thu, 02 Apr 2026 00:00:00 GMT Subscription billing has a short happy path and a long tail of edge cases that silently cost revenue. A naive proration step double-charges upgrades; a default retry policy burns through cards during dunning; missing fraud signals land as chargebacks. Subscriptions are not single transactions; they are state machines, and every billing event is a transition that can fire, fail, or repeat.

Model the subscription as a state machine first, then hang everything else off it. Proration rules, dunning cadence, fraud checks, and entitlement flips all become transitions with a defined owner. On Stripe that means one webhook handler that verifies, deduplicates, and publishes to EventBridge, with the business logic running in the consumers behind the bus.

Continue reading...

]]> <![CDATA[Claude Code Skills and Context Window Bloat: A Token Budget Guide]]> https://sph.sh/en/posts/why-copying-claude-code-skills-doesnt-work/ https://sph.sh/en/posts/why-copying-claude-code-skills-doesnt-work/ Mon, 23 Mar 2026 00:00:00 GMT The Claude Code ecosystem now includes 500+ community skills, 1,200+ agent skills, and dozens of MCP server directories. Cloning someone's "awesome" setup is tempting, and it is the wrong default. Copied configurations create three compounding problems: context window bloat leaves less room for actual code, tool sprawl degrades the model's ability to pick the right tool, and the copied workflows do not match your codebase.

The setup that works runs the other way. Start with zero MCP servers, add one only when a repeated friction point justifies it, and keep total configuration overhead under 20% of the context window. The token math below shows what a copied setup costs, and the benchmarks show why the model gets worse as the tool list grows.

Continue reading...

]]> <![CDATA[AWS Cognito + Verified Permissions for SaaS Authorization]]> https://sph.sh/en/posts/cognito-avp-saas-authorization/ https://sph.sh/en/posts/cognito-avp-saas-authorization/ Sun, 22 Mar 2026 00:00:00 GMT Authentication is the easy half of a B2B SaaS build on AWS. Cognito signs users in and hands back a JWT, but a valid token says nothing about whether tenant A may read tenant B's documents. AWS Verified Permissions (AVP) is the managed service that answers that second question, and the default worth starting from is the pool model: one Cognito User Pool, one AVP policy store, and a tenant check inside every Cedar policy.

Three decisions carry most of the weight: which claims the Pre Token Generation trigger writes into the access token, whether tenant isolation lives in Cedar policy or in separate infrastructure per tenant, and which AVP API each call path uses. Cedar policy shape, TypeScript wiring, and the monthly bill all follow from those three.

Continue reading...

]]> <![CDATA[OpenFGA vs SpiceDB vs Cerbos vs OPA vs AWS Verified Permissions: Which Authorization Platform to Choose]]> https://sph.sh/en/posts/external-authorization-management-systems/ https://sph.sh/en/posts/external-authorization-management-systems/ Sun, 22 Mar 2026 00:00:00 GMT Building custom authorization works for many applications. Distributed systems increasingly benefit from dedicated authorization infrastructure that handles policy evaluation, relationship management, and fine-grained access control as a service. A reasonable default: keep authorization in an embedded library while it stays inside one service, and adopt an external engine once it crosses a service boundary.

The choice of engine follows from your dominant model. Cedar and AWS Verified Permissions suit attribute-driven decisions on AWS. SpiceDB and OpenFGA suit access that follows relationships between users and resources. Cost, operational overhead, and policy language lock-in decide the rest.

Continue reading...

]]> <![CDATA[Cedar vs Rego vs OpenFGA: Policy Language Comparison]]> https://sph.sh/en/posts/policy-language-comparison-cedar-rego-openfga/ https://sph.sh/en/posts/policy-language-comparison-cedar-rego-openfga/ Sun, 22 Mar 2026 00:00:00 GMT The policy language you choose for authorization shapes the rest of your security architecture: it decides how policies are written, tested, deployed, and audited. Switching later means rewriting all of them, so the choice is worth making deliberately.

Four languages cover most of the field: Cedar, Rego, OpenFGA DSL, and Cerbos YAML/CEL. Two of them work as defaults. When access is fundamentally about relationships ("who has what relationship to what"), OpenFGA DSL is the starting point. When it is about attributes and you want machine-checked guarantees over the whole policy set, Cedar is. Rego and Cerbos answer narrower constraints: one language across infrastructure and application policy, or the shortest path to policies running in production.

Continue reading...

]]> <![CDATA[SpiceDB vs Auth0 FGA: Relationship-Based Authorization Compared]]> https://sph.sh/en/posts/spicedb-vs-auth0-fga/ https://sph.sh/en/posts/spicedb-vs-auth0-fga/ Sun, 22 Mar 2026 00:00:00 GMT SpiceDB and Auth0 FGA are the two leading Zanzibar-inspired authorization systems, but they make fundamentally different trade-offs. SpiceDB offers a gRPC-first, self-hosted (or managed via Authzed) engine with strong consistency guarantees through ZedTokens. Auth0 FGA provides a REST-first, fully managed service built on OpenFGA with a different consistency model.

For most teams the default is Auth0 FGA, or self-hosted OpenFGA when the infrastructure budget is zero. Two requirements flip that default to SpiceDB: permission revocation that must take effect on the very next read, and authorization data that cannot leave infrastructure you control. Schema syntax, API ergonomics, and published scale ceilings matter less than those two.

Continue reading...

]]> <![CDATA[How to Prioritize Customer Feedback: Triage, RICE, and ICE]]> https://sph.sh/en/posts/customer-feedback-product-value/ https://sph.sh/en/posts/customer-feedback-product-value/ Thu, 19 Mar 2026 00:00:00 GMT Customer feedback rarely arrives as a clean problem statement. It lands as Slack threads, support macros, sales notes, star ratings, and one-line feature requests. The hard part is not collecting it. The hard part is turning that stream into decisions without letting the loudest voice or the biggest logo own the roadmap by default.

The loop that survives contact with a real team is short: intake, triage, discovery when the job is unclear, delivery, and a closed loop back to the customer. Each step has to hold up against support SLAs, engineering queues, and metrics that are never as clean as the dashboard suggests.

Why feedback feels overwhelming

Several patterns show up again and again across teams:

Continue reading...

]]> <![CDATA[Authentication vs Authorization: Fundamentals and Why Permissions Break]]> https://sph.sh/en/posts/scalable-permission-systems-101-authorization-fundamentals/ https://sph.sh/en/posts/scalable-permission-systems-101-authorization-fundamentals/ Sun, 15 Mar 2026 00:00:00 GMT Broken access control is the number one vulnerability in the OWASP Top 10 (2021, confirmed in the 2025 update). Most permission bugs trace back to an architecture that makes checks easy to forget and hard to keep consistent. As a codebase grows, so does the number of places where a check can quietly go missing.

The default worth adopting from the first commit is a single permission-aware layer that every data access passes through, one that denies access whenever a check cannot complete. Getting there starts with a distinction that plenty of codebases blur.

Authentication vs Authorization

These two concepts are often bundled under the single word "auth," which leads to confusion. They are fundamentally different concerns.

Continue reading...

]]> <![CDATA[Centralizing Authorization with a Service Layer]]> https://sph.sh/en/posts/scalable-permission-systems-102-service-layer-centralization/ https://sph.sh/en/posts/scalable-permission-systems-102-service-layer-centralization/ Sun, 15 Mar 2026 00:00:00 GMT In Post 101, we diagnosed the root problems with scattered permission checks: inconsistent logic, security gaps, and maintenance overhead. The first fix is the service layer pattern: all authorization logic moves into a single layer between your application code and the database.

Next.js middleware for route protection and guards at several levels build on top of that layer. Together they form a defense-in-depth architecture: a permission rule is written once and enforced on every path to the data.

The Root Cause of Scattered Checks

Continue reading...

]]> <![CDATA[Role-Based Access Control: Type-Safe RBAC in TypeScript]]> https://sph.sh/en/posts/scalable-permission-systems-103-role-based-access-control/ https://sph.sh/en/posts/scalable-permission-systems-103-role-based-access-control/ Sun, 15 Mar 2026 00:00:00 GMT Post 102 centralized authorization in the service layer, solving the architectural question of where permission checks happen. But the permission rules inside the service layer are still hardcoded if/else chains: if (session.role === 'admin') return true. Adding a new role means modifying every helper function across every service file.

RBAC (Role-Based Access Control) replaces those chains. Ferraiolo and Kuhn formalized the model in 1992, and NIST standardized it as INCITS 359-2004. A single, type-safe can() function takes over every hardcoded check. It runs on both server and client, closing the permission logic duplication that Post 102 left open.

What Is RBAC?

The NIST Model

Continue reading...

]]> <![CDATA[Attribute-Based Access Control in TypeScript: Building an ABAC Policy Engine]]> https://sph.sh/en/posts/scalable-permission-systems-104-attribute-based-access-control/ https://sph.sh/en/posts/scalable-permission-systems-104-attribute-based-access-control/ Sun, 15 Mar 2026 00:00:00 GMT Post 103 built type-safe RBAC with a can(role, resource, action) function and a declarative permission matrix. Adding a role stays a one-line change, and server and client share a single source of truth. But contextual decisions (ownership, department scoping, document status) stay outside that matrix as custom helper functions. canModifyDocument, canEditInDepartment, and canPublishInReviewStatus proliferate alongside can(), each an if/else chain the type system cannot verify.

Continue reading...

]]> <![CDATA[Advanced ABAC: Field-Level Permissions and DB Integration]]> https://sph.sh/en/posts/scalable-permission-systems-105-advanced-abac-field-level-db/ https://sph.sh/en/posts/scalable-permission-systems-105-advanced-abac-field-level-db/ Sun, 15 Mar 2026 00:00:00 GMT Post 104 built a type-safe ABAC policy engine with a builder pattern. The can(user, action, resource, data?) function evaluates subject, resource, and action attributes through declarative conditions. Ownership, department scoping, and resource status became policy rules; the scattered helper functions are gone. Two gaps are left, and both close by extending that builder rather than by adding checks around it.

Continue reading...

]]> <![CDATA[Multi-Tenant Authorization in TypeScript: CASL vs Custom ABAC]]> https://sph.sh/en/posts/scalable-permission-systems-106-multi-tenancy-libraries-decisions/ https://sph.sh/en/posts/scalable-permission-systems-106-multi-tenancy-libraries-decisions/ Sun, 15 Mar 2026 00:00:00 GMT Post 101 established seven goals for a permission system and exposed the scattered-check anti-pattern. Post 102 centralized authorization inside a service layer. Post 103 added type-safe RBAC. Post 104 replaced the role-permission matrix with an ABAC policy engine. Post 105 extended ABAC with environment rules, field-level read/write permissions, and database query filtering.

Continue reading...

]]> <![CDATA[MCP vs Direct API Access for AI Agents: When to Skip the MCP Layer]]> https://sph.sh/en/posts/skip-mcp-layer-scoped-api-access/ https://sph.sh/en/posts/skip-mcp-layer-scoped-api-access/ Thu, 12 Mar 2026 00:00:00 GMT Atlassian's Rovo MCP Server connects AI agents to Jira and Confluence in a few minutes, and it hands the agent everything the authenticated user can already see. In an organization with dozens of projects and spaces, that means no server-side project scoping, tool schemas that consume the context window before any work starts, and all-or-nothing exposure of Jira, Confluence, and Compass operations at once.

Continue reading...

]]> <![CDATA[AWS Control Tower Multi-Account Strategy: From Landing Zone to Enterprise Governance]]> https://sph.sh/en/posts/aws-control-tower-multi-account-strategy/ https://sph.sh/en/posts/aws-control-tower-multi-account-strategy/ Fri, 06 Mar 2026 00:00:00 GMT AWS Control Tower provides the foundation for a well-governed, multi-account AWS environment. The setup wizard is the easy part; the decisions after it are not. Once the landing zone is live, the shape of the OU tree, the guardrail rollout order, account provisioning, and cross-account access are all still open.

Four defaults hold for most organizations: align OU boundaries with policy boundaries, enable detective controls before preventive ones, centralize logging on day one, and reach for Account Factory for Terraform only when the team already runs Terraform. Everything that follows is about the trade-offs behind those defaults and the conditions that justify overriding them.

Why a Multi-Account Strategy Matters

Continue reading...

]]> <![CDATA[Salary, Impact, or Satisfaction? The Vocation Question Every Engineer Faces]]> https://sph.sh/en/posts/salary-impact-satisfaction-vocation/ https://sph.sh/en/posts/salary-impact-satisfaction-vocation/ Wed, 04 Mar 2026 00:00:00 GMT The salary-versus-impact-versus-satisfaction debate is a fixture of engineering career forums, and the framing is where the confusion starts. Salary, impact, and satisfaction describe the dominant need at three different stages of vocational development. Treating them as competing priorities turns a sequencing question into a loyalty test, and the decisions that follow tend to misfire.

Organizational psychology has already mapped those stages. Wrzesniewski's work-orientation research, Self-Determination Theory, and Dan Koe's Vocation quadrant converge on the same three-step progression. Knowing which step you occupy tells you which dimension deserves attention now, and which one can wait.

The Three Camps

Continue reading...

]]> <![CDATA[Org-Level Reusable GitHub Actions Workflows: Architecture, Security, and Adoption]]> https://sph.sh/en/posts/github-actions-platform-scale/ https://sph.sh/en/posts/github-actions-platform-scale/ Sun, 01 Mar 2026 00:00:00 GMT GitHub Actions is deceptively simple to get started with. Copy a YAML file, add a few steps, and the pipeline runs. That simplicity stops scaling once dozens of repositories, each maintained by a different team, carry their own flavor of build, test, and deploy. The result is familiar at mid-to-large engineering organizations: hundreds of workflow files with subtle differences, inconsistent security practices, build times that vary wildly, and a support backlog where platform engineers answer "how do I do X in GitHub Actions?" instead of building platform capabilities.

Continue reading...

]]> <![CDATA[Sentry Integration with React Native Expo: A Practical Quick Guide]]> https://sph.sh/en/posts/sentry-react-native-expo-setup/ https://sph.sh/en/posts/sentry-react-native-expo-setup/ Mon, 16 Feb 2026 00:00:00 GMT Sentry's setup wizard handles a React Native Expo project in one command, and for most apps the wizard plus a development build is the whole answer. The parts that cost hours come afterwards: Expo Go quietly drops native crashes and session replay, EAS Update never uploads source maps on its own, and an auth token left in app.json ships to every device that installs the app.

The configuration below targets Expo SDK 50 or later with @sentry/react-native. The older sentry-expo package was deprecated alongside SDK 50, so new projects should skip it.

Prerequisites

Before starting, you need:

Continue reading...

]]> <![CDATA[What Is DevRel? Developer Relations Role, Skills, and Career Path]]> https://sph.sh/en/posts/devrel-role-analysis/ https://sph.sh/en/posts/devrel-role-analysis/ Wed, 04 Feb 2026 00:00:00 GMT Developer Relations (DevRel) is often misunderstood as "marketing for developers" or "getting paid to travel and speak at conferences." That reading misses the strategic value. DevRel captures developer reality and feeds it back into product development. It also scales developer education past what a documentation team can cover alone. Everything else follows from that definition: who thrives in the role, and when a company should fund one.

Continue reading...

]]> <![CDATA[DynamoDB Throttling: Hot Partition Fixes, Write Sharding, and Retry Strategies]]> https://sph.sh/en/posts/dynamodb-rate-limit-strategies/ https://sph.sh/en/posts/dynamodb-rate-limit-strategies/ Wed, 28 Jan 2026 00:00:00 GMT When working with DynamoDB at scale, throttling becomes an inevitable challenge. The ProvisionedThroughputExceededException error often appears despite having adequate table-level capacity, because DynamoDB enforces capacity separately for each partition.

Partition key design is the lever that matters most. Write sharding, capacity modes, DAX, and retry logic each buy headroom on top of that choice, and none of them undoes a low-cardinality key. The practical order in Single Table Design: high-cardinality keys first, sharding for the access patterns that cannot be high-cardinality, then retries and monitoring around what remains.

Understanding DynamoDB's Throttling Mechanism

Continue reading...

]]> <![CDATA[MCP Server RBAC, Tool Composition, and Multi-Agent Workflow Patterns]]> https://sph.sh/en/posts/mcp-advanced-patterns-workflows-rbac/ https://sph.sh/en/posts/mcp-advanced-patterns-workflows-rbac/ Thu, 22 Jan 2026 00:00:00 GMT Most MCP material stops at the first working server: register a few tools, connect a client, done. The failure modes start later, when a second team connects to the same server and one of the registered tools can change production.

Six patterns cover that gap: tool annotations, workflow orchestration, RBAC with attribute conditions, progressive authorization, error recovery, and observability. If you adopt only one, make it RBAC backed by audit logging. Permissions and audit trails are the layers that hurt to retrofit once agents are already calling tools, while orchestration can wait until you have two workflows to compare.

The Scaling Challenge

Organizations successfully deploying basic MCP integrations encounter predictable challenges as they sca...

Continue reading...

]]> <![CDATA[RAG Data Preparation: The Foundation That Makes or Breaks Your AI System]]> https://sph.sh/en/posts/rag-data-preparation/ https://sph.sh/en/posts/rag-data-preparation/ Thu, 22 Jan 2026 00:00:00 GMT Most RAG implementation failures trace back to data preparation, not retrieval architecture. Teams spend weeks tuning retrieval parameters when the real problem is poorly parsed documents or inappropriate chunking. Validated parsing plus recursive splitting at around 512 tokens is the default worth starting from; semantic and parent-child chunking earn their extra cost only once measurements say they do.

The Quality Ceiling of a RAG Pipeline

There is a common pattern in RAG implementations: sophisticated retrieval architectures (hybrid search, reranking, CRAG) that still produce poor results. The root cause is almost always upstream in the data preparation layer.

[code block]

Continue reading...

]]> <![CDATA[What Is a Forward Deployed Engineer? FDE vs Solutions Architect and TAM]]> https://sph.sh/en/posts/forward-deployed-engineer-role-analysis/ https://sph.sh/en/posts/forward-deployed-engineer-role-analysis/ Mon, 19 Jan 2026 00:00:00 GMT A Forward Deployed Engineer (FDE) writes production code inside the customer's infrastructure and stays until that code runs. That is the whole boundary: Solutions Architects, Solutions Engineers, and Technical Account Managers all hand implementation back to the customer, and the FDE keeps it. The title, the compensation band, and the burnout risk all follow from that one difference.

Demand climbed with enterprise AI, because an AI system needs customer context (historical data, workflows, business rules) before it produces anything useful, and a demo environment cannot supply that context. The trade is honest: an FDE-heavy organization buys deep integration at the cost of gross margin, and that trade pays off only while the product category is still new.

Continue reading...

]]> <![CDATA[TypeScript AI SDK Comparison: Vercel AI SDK vs OpenAI Agents SDK for Agent Development]]> https://sph.sh/en/posts/typescript-ai-sdk-agent-tooling/ https://sph.sh/en/posts/typescript-ai-sdk-agent-tooling/ Mon, 19 Jan 2026 00:00:00 GMT Building an AI agent in TypeScript starts with a boring decision: which SDK carries your tool calls, your streaming, and your provider credentials. Three answers dominate, and each optimizes for something different. Vercel AI SDK trades provider-specific surface for portability, OpenAI Agents SDK builds multi-agent orchestration into the runtime, and direct provider SDKs keep every knob exposed.

For most TypeScript and Next.js codebases the default is Vercel AI SDK. The interesting question is where that default stops paying: heavy multi-agent orchestration, and single-provider services that need a feature no abstraction exposes yet.

The TypeScript AI SDK Landscape

Each of the three places the abstraction at a different level:

Continue reading...

]]> <![CDATA[RAG vs Fine-Tuning vs Off-the-Shelf AI: An Enterprise Decision Framework]]> https://sph.sh/en/posts/ai-integration-levels-enterprise-guide/ https://sph.sh/en/posts/ai-integration-levels-enterprise-guide/ Sat, 17 Jan 2026 00:00:00 GMT Enterprise AI adoption follows a predictable pattern: teams reach for sophisticated architectures before validating simpler ones. A six-level ladder, from direct chat at L1 to fine-tuning at L6, lines those options up against the business need behind them. The default sits lower than most roadmaps assume. L2, a system prompt with uploaded knowledge files, covers more internal use cases than it gets credit for, and you climb only when a measured limitation pushes you up.

Continue reading...

]]> <![CDATA[AI/LLM Glossary: 82 Terms Every Developer Should Know]]> https://sph.sh/en/posts/ai-llm-glossary-developer-terms/ https://sph.sh/en/posts/ai-llm-glossary-developer-terms/ Sat, 17 Jan 2026 00:00:00 GMT AI terminology evolves faster than most documentation can keep up with. New terms appear weekly - RAG, RLHF, LoRA, MCP, GGUF - often with inconsistent definitions across different sources. The gap is practical. Vendor materials conflate concepts, and knowing what a term means rarely tells you when to use it.

Every entry pairs a definition with implementation context: what the concept costs in practice, where it is commonly misread, and when to reach for something else. That context is what separates explaining embeddings to a PM from knowing whether embedding your knowledge base is the right call.

Core Concepts

LLM (Large Language Model)

Continue reading...

]]> <![CDATA[Comparing TypeScript Formatting and Linting Tools: Biome, Oxlint, ESLint, and Prettier]]> https://sph.sh/en/posts/compare-typescript-formatting-linting-tools/ https://sph.sh/en/posts/compare-typescript-formatting-linting-tools/ Tue, 13 Jan 2026 00:00:00 GMT The TypeScript tooling landscape has shifted with Rust-based alternatives entering the scene. For a new project, Biome is the sensible default: a single binary covers linting, formatting, and import organization, and it runs 15-25x faster than ESLint + Prettier. For an existing codebase with a working ESLint setup, the first move is adding Oxlint alongside it; that buys measurable speed without touching the configuration you already trust.

That default has a boundary. Rust-based tools gain speed by giving up ecosystem breadth and type-aware rule coverage: Biome's Biotype covers roughly 75-85% of typescript-eslint rules, and Oxlint's tsgolint ships 43 of them. Where those gaps matter, ESLint + Prettier is still the right answer.

What Traditional Tooling Costs

Continue reading...

]]> <![CDATA[The Expectation Gap: When Hiring Promises Meet Workplace Reality]]> https://sph.sh/en/posts/hiring-expectations-workplace-power-dynamics/ https://sph.sh/en/posts/hiring-expectations-workplace-power-dynamics/ Fri, 09 Jan 2026 00:00:00 GMT What employers promise during recruitment and what employees experience after starting often diverge sharply, and survey data puts that gap at a majority of candidates. The cost lands on both sides: early resignations, disengagement and skill atrophy for employees; replacement spend and a damaged employer brand for companies.

The discipline that closes the gap is the same for both parties. Put the promises in writing before the offer is signed, then check the match against reality at fixed intervals after day one. Neither step depends on goodwill from the other side, which is what makes them work.

The Scale of the Problem

Continue reading...

]]> <![CDATA[Post-Acquisition Culture Integration: Why Acquisitions Fail]]> https://sph.sh/en/posts/post-acquisition-cultural-erosion/ https://sph.sh/en/posts/post-acquisition-cultural-erosion/ Wed, 07 Jan 2026 00:00:00 GMT Post-acquisition cultural erosion is the gradual loss of the acquired company's distinct capabilities, talent, and decision patterns after the deal closes. It is the single largest source of unrealized M&A value, and it traces to cultural misalignment far more often than to market, product, or financial causes. Cultural erosion is not random drift; it is a systematic process driven by ethnocentric leadership, in-group versus out-group dynamics, and the unconscious bias that funnels decision authority toward the acquirer's existing norms.

Continue reading...

]]> <![CDATA[Running Bun and Alternative JavaScript Runtimes on AWS Lambda]]> https://sph.sh/en/posts/bun-on-lambda-custom-runtimes/ https://sph.sh/en/posts/bun-on-lambda-custom-runtimes/ Fri, 26 Dec 2025 00:00:00 GMT AWS Lambda officially supports Node.js, but the platform's custom runtime capability opens the door to alternative JavaScript runtimes like Bun and Deno. Two mechanisms make that work: Lambda Layers and container images. Both give up the initialization tuning AWS applies to its own managed runtimes, and that trade lands on cold starts.

For most Lambda workloads the managed Node.js runtime stays the right default. An alternative runtime earns its slot only when a measured constraint justifies it, and in that case a container image with a pre-warmed Deno cache is the more predictable of the two paths.

The Custom Runtime Question

Continue reading...

]]> <![CDATA[Prompt Engineering for Production Systems: A Systematic Engineering Approach]]> https://sph.sh/en/posts/prompt-engineering-production/ https://sph.sh/en/posts/prompt-engineering-production/ Fri, 26 Dec 2025 00:00:00 GMT Prompts that behave in a notebook rarely behave in production. The same template drifts under load, leaks its system instructions to a curious user, and quietly multiplies the token bill. Better wording fixes none of that. The reliable default is to treat a prompt as versioned infrastructure: explicit structure, a stored version with metadata, tracing on every call, layered input and output checks, and a token budget.

Five decisions follow from that default: how to structure a prompt so that user data is marked as data rather than instructions, how to version and roll out changes, what to trace, how to defend against injection, and where the cost actually goes.

The Production Gap

Continue reading...

]]> <![CDATA[SOLID Principles in JavaScript: Practical Guide with TypeScript and React]]> https://sph.sh/en/posts/solid-principles-javascript/ https://sph.sh/en/posts/solid-principles-javascript/ Fri, 26 Dec 2025 00:00:00 GMT SOLID principles were formulated for object-oriented programming, but modern JavaScript development looks different: functional patterns, React hooks, dynamic typing. They still hold, with one adaptation. Anchor each principle to a composition boundary (a function, a module, a hook, a component's prop list) instead of a class hierarchy, and all five survive the move.

Continue reading...

]]> <![CDATA[Edge Computing with AWS: CloudFront Functions vs Lambda@Edge]]> https://sph.sh/en/posts/edge-computing-aws/ https://sph.sh/en/posts/edge-computing-aws/ Thu, 25 Dec 2025 00:00:00 GMT Edge computing moves code execution from centralized data centers to locations near users. AWS CloudFront runs a global edge network and offers two ways to put code on it: CloudFront Functions and Lambda@Edge. Default to CloudFront Functions. They cover header work, redirects, and cache key normalization at a fraction of the price, and Lambda@Edge earns its cost only when a request needs network access, a request body, or origin-side events.

Where Edge Code Runs

Both services cut latency by handling a request at the edge instead of at the origin, but they sit at different points in the request lifecycle and carry different limits.

Continue reading...

]]> <![CDATA[Amazon Cognito Deep Dive: Beyond Basic Authentication]]> https://sph.sh/en/posts/cognito-deep-dive/ https://sph.sh/en/posts/cognito-deep-dive/ Wed, 24 Dec 2025 00:00:00 GMT Amazon Cognito covers sign-up and sign-in with very little configuration. Production systems ask for more: tenant context carried inside the token, corporate SSO, a migration path off an existing provider, and a backup plan for a directory that AWS does not replicate across regions. The service's sharp edges show up at exactly those points.

Continue reading...

]]> <![CDATA[Learning Effect: A Practical Adoption Guide for TypeScript Developers]]> https://sph.sh/en/posts/learning-effect-adoption-guide/ https://sph.sh/en/posts/learning-effect-adoption-guide/ Tue, 23 Dec 2025 00:00:00 GMT Effect brings a functional effect system to TypeScript: typed errors, dependency injection, and structured concurrency, all enforced by the compiler. The ecosystem is rich, but the learning curve is steep. Documentation sits scattered across Discord threads, GitHub issues, and blog posts of varying age, so the path from "Hello World" to code you would put behind a production Lambda is not obvious.

The default worth starting from is incremental adoption: write new features and high-complexity modules in Effect, and leave stable Promise-based code alone until you have a reason to touch it. Twelve weeks is a realistic budget for the full path, with two to four of those weeks spent on the basics before service layers, concurrency, and Lambda patterns make sense.

Continue reading...

]]> <![CDATA[AWS Secrets Manager & Parameter Store: Security Best Practices]]> https://sph.sh/en/posts/secrets-manager/ https://sph.sh/en/posts/secrets-manager/ Tue, 23 Dec 2025 00:00:00 GMT Engineers working with AWS face a common dilemma: choosing between Secrets Manager and Parameter Store for secrets management. Both services store sensitive data, but they serve different purposes and carry different cost structures. The short rule: static config goes to Parameter Store; RDS passwords and anything that has to rotate go to Secrets Manager. Everything after that is a question of cost, cross-account access, and how your workloads read secrets at runtime.

Differences Between the Two Services

Three axes separate the two services: cost, rotation support, and native integrations. Cross-account sharing is a fourth. Secrets Manager resource policies are more flexible there, while Parameter Store goes through RAM (Resource Access Manager).

Continue reading...

]]> <![CDATA[API Versioning Strategies in Practice: From First Release to Sunset]]> https://sph.sh/en/posts/api-versioning/ https://sph.sh/en/posts/api-versioning/ Mon, 22 Dec 2025 00:00:00 GMT API versioning is not a URL convention; it is a contract-management problem. A version is a promise to a specific set of clients about a specific set of breaking changes. The strategy behind that promise (URL path, header, content negotiation, or a versioned resource graph) sets the price of every client migration, the time deprecated surface stays deployed, and the amount of infrastructure duplicated during a transition. Most versioning rewrites start the moment a team notices it has been communicating the contract implicitly and now has to make it explicit.

Continue reading...

]]> <![CDATA[LaunchDarkly vs Unleash vs AWS AppConfig: Feature Flags at Scale]]> https://sph.sh/en/posts/feature-flags-scale/ https://sph.sh/en/posts/feature-flags-scale/ Sun, 21 Dec 2025 00:00:00 GMT Feature flags let you deploy code to production and control feature visibility at runtime. Without that control, deploying features in a distributed system forces a choice between big-bang releases that risk outages and long-lived branches that accumulate merge conflicts. Every deployment becomes an all-or-nothing event tied to a business release schedule.

Continue reading...

]]> <![CDATA[Playwright vs Cypress: E2E Testing Strategies for Modern Web Apps]]> https://sph.sh/en/posts/e2e-testing-strategies/ https://sph.sh/en/posts/e2e-testing-strategies/ Sat, 20 Dec 2025 00:00:00 GMT E2E suites fail for the same handful of reasons in every framework: state shared between tests, selectors tied to markup, and static waits standing in for a real condition. The framework decides how pleasant debugging is. The architecture decides whether the suite still runs six months and one redesign later.

For a new suite, start with Playwright. Free native parallelism, WebKit and Firefox coverage, and the trace viewer remove three recurring sources of pain without a paid tier. Cypress stays a reasonable choice for teams that already work inside its interactive runner. Everything after that decision is architecture: page objects, stable data-testid selectors, API-created test data, and a pyramid that keeps edge cases out of the browser.

Continue reading...

]]> <![CDATA[Caching Strategies: From Local Memory to Distributed Systems]]> https://sph.sh/en/posts/caching-strategies/ https://sph.sh/en/posts/caching-strategies/ Fri, 19 Dec 2025 00:00:00 GMT Effective caching is a multi-level problem. The fastest layer is an in-process LRU, the next is a remote cache (Redis or Memcached), then a CDN at the edge. Each layer carries its own invalidation semantics, consistency guarantees, and failure modes. A Redis cluster with a 15% hit rate usually points at the wrong work happening at the wrong level rather than at a bad choice of tool. A thundering herd on a popular expiring key is a stampede-protection problem, and any single-layer cache has it.

Continue reading...

]]> <![CDATA[AWS Cost Optimization Toolkit - Practical Strategies for Production Workloads]]> https://sph.sh/en/posts/aws-cost-optimization/ https://sph.sh/en/posts/aws-cost-optimization/ Thu, 18 Dec 2025 00:00:00 GMT AWS cost work has a default order: build visibility, then right-size, then commit. Cost Explorer and Budgets show where the money goes, Compute Optimizer flags the capacity nobody uses, and Savings Plans or Reserved Instances discount whatever survives those two steps. Teams that reverse the order buy a discounted rate for capacity they should have deleted.

The symptoms that send teams looking are usually the same across production accounts: monthly bills that move without a matching traffic change, development resources running 24/7 when they are needed only during working hours, and instances billed for full capacity while their CPUs sit idle.

Five Recurring Cost Drivers

Continue reading...

]]> <![CDATA[Mozilla SOPS: Encrypting Secrets in Git for GitOps]]> https://sph.sh/en/posts/mozilla-sops-gitops-secrets/ https://sph.sh/en/posts/mozilla-sops-gitops-secrets/ Thu, 18 Dec 2025 00:00:00 GMT Mozilla SOPS (Secrets OPerationS) answers one question every GitOps setup runs into: how do you keep secrets in version control without publishing them? SOPS encrypts the values inside YAML and JSON files and leaves the keys readable, so the file structure survives code review while passwords and API keys stay ciphertext. Secrets then travel through the same pull request as the code that reads them.

Continue reading...

]]> <![CDATA[Transactional Outbox Pattern: Reliable Event Publishing in Distributed Systems]]> https://sph.sh/en/posts/outbox-pattern/ https://sph.sh/en/posts/outbox-pattern/ Tue, 16 Dec 2025 00:00:00 GMT Every event-driven service eventually has to do two things at once: change its own state and tell the rest of the system about it. Without a distributed transaction, a database write and a broker publish cannot be made atomic, so one can fail while the other succeeds. What is left behind is an order nobody reserved stock for, or reserved stock for an order that does not exist.

Continue reading...

]]> <![CDATA[Understanding Career Levels in Tech - From Entry to Distinguished Engineer]]> https://sph.sh/en/posts/career-levels-tech-companies/ https://sph.sh/en/posts/career-levels-tech-companies/ Mon, 15 Dec 2025 00:00:00 GMT Career level systems differ enough between companies that titles stop being comparable. A Senior at Amazon is an L6 and a Senior at Google is an L5, and a Staff title at a 40-person startup rarely carries the scope a Staff title carries at Meta. The reliable comparison unit is scope, autonomy, and impact; the number and the label are only how each company records the result. Misreading your equivalent level has a price: you accept a lower band in a new role, or you spend a year building a promotion case for the wrong kind of work.

Continue reading...

]]> <![CDATA[RAG Architecture Patterns: Beyond Basic Vector Search]]> https://sph.sh/en/posts/rag-architecture-patterns/ https://sph.sh/en/posts/rag-architecture-patterns/ Mon, 15 Dec 2025 00:00:00 GMT Retrieval-Augmented Generation (RAG) systems usually start with plain vector similarity search. That baseline breaks down on three predictable fronts: exact keyword matches, questions whose answer spans several documents, and retrieved context that nobody checked for relevance.

The default worth reaching for first is hybrid search combined with parent-child chunking. Reranking, self-corrective retrieval (CRAG), and knowledge graphs (GraphRAG) sit above it as escalations, added when measurement shows the default falls short. The patterns below map onto AWS Bedrock Knowledge Bases and OpenSearch, and RAGAS metrics decide whether an escalation paid for itself.

The Problem with Basic RAG

Vector similarity alone leaves three specific gaps in production.<...

Continue reading...

]]> <![CDATA[AWS AppSync & GraphQL: Building Production-Ready Real-time APIs]]> https://sph.sh/en/posts/appsync-graphql/ https://sph.sh/en/posts/appsync-graphql/ Sun, 14 Dec 2025 00:00:00 GMT AWS AppSync gives you a managed GraphQL endpoint with WebSocket subscriptions, conflict resolution, and direct connections to AWS data sources. For most teams the default that holds is a narrow one: wire resolvers straight to DynamoDB with the JavaScript (APPSYNC_JS) runtime, and reach for Lambda only when a field needs async I/O or logic the runtime cannot express.

That single choice moves latency and cost further than any schema decision does. Subscription filtering, caching layers, single-table versus multi-table modeling, and the CDK wiring around them are all tuning on top of it.

The Hard Parts of Real-time APIs

Continue reading...

]]> <![CDATA[AI Agent Security: Guardrails and Defense Patterns for Production Systems]]> https://sph.sh/en/posts/ai-agent-security/ https://sph.sh/en/posts/ai-agent-security/ Sat, 13 Dec 2025 00:00:00 GMT AI agents that autonomously invoke tools and call external APIs introduce attack surfaces that traditional application security models were not designed to handle. A single prompt injection or a misconfigured tool permission can escalate into data exfiltration, unauthorized actions, or runaway cost.

The default that holds up in production is layered enforcement outside the model: a managed guardrail on every invocation, an explicit authorization check on every tool call, validation on every output, and a hard token budget behind all of it. Prompt-level instructions are the weakest of those layers, so nothing that matters should depend on them alone.

The Agent Attack Surface

Continue reading...

]]> <![CDATA[Platform Engineering: Building Internal Developer Platforms That Developers Actually Want to Use]]> https://sph.sh/en/posts/platform-engineering-idp/ https://sph.sh/en/posts/platform-engineering-idp/ Fri, 12 Dec 2025 00:00:00 GMT An Internal Developer Platform earns its keep the day an engineer can ship a service without filing a ticket. The default that gets there is narrower than most platform roadmaps assume: one golden path, built with one pilot team, exposed through an API or CLI before any portal UI, and adopted because it is the fastest route rather than because someone mandated it.

Catalog, self-service actions, IaC orchestration, metrics and tooling all hang off that default. Backstage, Port and the AWS building blocks are decisions you take after the first golden path has earned voluntary adoption.

Understanding Platform Engineering

Continue reading...

]]> <![CDATA[Contract Testing with Pact - Ensuring API Compatibility in Microservices]]> https://sph.sh/en/posts/contract-testing-pact/ https://sph.sh/en/posts/contract-testing-pact/ Thu, 11 Dec 2025 00:00:00 GMT Consumer-driven contract testing closes the gap between a passing unit test and a working integration. Each consumer declares what it needs from a provider API, the provider verifies it can deliver that, and a deployment gate blocks any release that would break a dependent service. For TypeScript microservices owned by separate teams, Pact behind a Pact Broker with a can-i-deploy gate is the default worth reaching for before growing the end-to-end suite again.

Continue reading...

]]> <![CDATA[Building Custom MCP Servers: A Production-Ready Guide]]> https://sph.sh/en/posts/custom-mcp-servers/ https://sph.sh/en/posts/custom-mcp-servers/ Wed, 10 Dec 2025 00:00:00 GMT The Model Context Protocol (MCP) has become a common integration surface across major AI providers. Pre-built servers cover public services like GitHub or Slack well. Internal APIs, proprietary databases, and legacy systems have no such server, and a generic one cannot encode your validation rules, security requirements, or compliance needs. For those systems the default is to build your own, and the build is smaller than it looks: a TypeScript project, a few well-scoped tools, and the same production discipline you already apply to any internal service.

Continue reading...

]]> <![CDATA[SNS/SQS Cross-Account Fan-Out: Building Multi-Account Event Distribution in AWS]]> https://sph.sh/en/posts/sns-sqs-cross-account-fanout/ https://sph.sh/en/posts/sns-sqs-cross-account-fanout/ Wed, 10 Dec 2025 00:00:00 GMT Cross-account SNS/SQS fan-out lets one SNS topic in a publisher account deliver every event to SQS queues owned by other accounts, without either side handing over credentials. Most of the work is permissions: a topic policy, a queue policy, and, once encryption is in play, a KMS key policy that agrees with both.

Three defaults carry the design. Let the queue owner create the subscription, give every encrypted queue a customer-managed KMS key, and filter at the SNS subscription so consumers never pay for messages they would discard. CDK wiring, FIFO ordering, and cross-account dashboards all hang off those three.

What the Pattern Buys

Continue reading...

]]> <![CDATA[FinOps for AI Workloads: Managing LLM Costs in Production]]> https://sph.sh/en/posts/finops-ai-workloads/ https://sph.sh/en/posts/finops-ai-workloads/ Tue, 09 Dec 2025 00:00:00 GMT Running large language models in production breaks the cost model most cloud teams already trust. Compute-hour billing is predictable, and token billing is not. The same feature can cost a fraction of a cent or several dollars per call, depending on how much context the prompt carries, which model answers, and how many tool calls the agent makes before it stops.

Continue reading...

]]> <![CDATA[AI Agent Architecture Patterns: ReAct, Plan-and-Execute, Multi-Agent]]> https://sph.sh/en/posts/chatbots-to-autonomous-agents/ https://sph.sh/en/posts/chatbots-to-autonomous-agents/ Mon, 08 Dec 2025 00:00:00 GMT A chatbot classifies intent and replays a scripted flow. An agent runs a reasoning loop, selects tools at runtime, and carries memory between tasks. The gap between them is not a capability upgrade you can bolt on; it changes how state, control flow, and failure handling are designed.

The default worth starting from is a single ReAct agent with hybrid memory. It handles dynamic tool use without the coordination overhead of a multi-agent system, and it leaves one control loop to debug. Plan-and-Execute earns its place when the task decomposes cleanly and cost per task is the binding constraint. Multiple specialized agents earn theirs only when the domains are genuinely separate and a wrong answer is expensive enough to pay for the coordination layer.

Continue reading...

]]> <![CDATA[Saga Pattern for Distributed Transactions: Maintaining Consistency Without ACID]]> https://sph.sh/en/posts/saga-pattern-distributed-transactions/ https://sph.sh/en/posts/saga-pattern-distributed-transactions/ Sun, 07 Dec 2025 00:00:00 GMT Microservices split a single business transaction across several databases, and ACID guarantees stop at the service boundary. The Saga pattern fills that gap with local transactions plus compensating transactions: each committed step can be undone when a later step fails, and the system settles into eventual consistency.

Orchestration with AWS Step Functions is the safer default for order-shaped flows, because saga state and failure paths stay visible in one place. EventBridge choreography is cheaper and looser, and it earns its slot when three or four autonomous services already exchange domain events. Whichever coordination style you pick, idempotent steps, reverse-order compensation, and semantic locking are what keep the pattern standing under retries.

Continue reading...

]]> <![CDATA[Testing Serverless Applications: A Practical Strategy Guide]]> https://sph.sh/en/posts/testing-serverless-applications/ https://sph.sh/en/posts/testing-serverless-applications/ Sat, 06 Dec 2025 00:00:00 GMT Serverless applications compress the deploy cycle to minutes, which changes the economics of testing: the bug that used to be caught by a long release process now reaches production before a human reviews it. The testing strategy has to catch what the deploy cadence no longer will. Serverless architecture also breaks local-first testing; Lambda cold starts, IAM permissions, event schemas, and the boundaries between managed services all behave differently locally than in a live account.

Continue reading...

]]> <![CDATA[AWS Messaging Services: SQS vs SNS vs EventBridge - A Decision Framework]]> https://sph.sh/en/posts/aws-messaging-comparison/ https://sph.sh/en/posts/aws-messaging-comparison/ Fri, 05 Dec 2025 00:00:00 GMT Choosing between SQS, SNS, and EventBridge is not a feature comparison; it is a communication-model decision. SQS is a point-to-point work queue, SNS is a pub/sub fan-out, and EventBridge is a schema-aware event router with replay. A team that picks by feature list usually discovers the mismatch late: the wrong service model forces a custom layer that rebuilds behaviour the right service provides natively. Most AWS messaging rewrites start there.

Continue reading...

]]> <![CDATA[AWS Step Functions Deep Dive: Building Resilient Workflow Orchestration]]> https://sph.sh/en/posts/step-functions-deep-dive/ https://sph.sh/en/posts/step-functions-deep-dive/ Thu, 04 Dec 2025 00:00:00 GMT AWS Step Functions moves orchestration out of Lambda code and into a state machine, but two decisions shape everything that follows: Standard or Express workflows, and how much error handling to push into the state machine. For high-volume work that finishes in minutes, Express is the right default. Standard earns its higher per-transition price when a workflow runs for days, needs exactly-once semantics, or has to leave an audit trail.

Getting those two decisions right is most of the value. The rest is a small set of patterns that hold up in production: Distributed Map for datasets too large for a regular Map state, Task Token callbacks for human approvals, direct service integrations that skip the Lambda wrapper, and a cost model you can compute before you deploy.

Continue reading...

]]> <![CDATA[LangChain in Production: Patterns That Work and Anti-Patterns That Don't]]> https://sph.sh/en/posts/langchain-production-patterns/ https://sph.sh/en/posts/langchain-production-patterns/ Wed, 03 Dec 2025 00:00:00 GMT The Production Gap

Moving LangChain applications from prototype to production reveals a gap between documentation examples and real-world requirements. What works perfectly in development can become costly, slow, or unreliable under production load.

Prototype workloads hide failure modes that only surface at scale: agents that loop on ambiguous inputs, token spend that climbs with every conversation turn, and silent failures that reach you as user complaints. The framework's abstractions accelerate prototyping but obscure the cost, latency, and reliability levers you need under production load.

Continue reading...

]]> <![CDATA[Building an MCP Server in TypeScript: A Production Guide]]> https://sph.sh/en/posts/mcp-standard-ai-integration/ https://sph.sh/en/posts/mcp-standard-ai-integration/ Tue, 02 Dec 2025 00:00:00 GMT The Integration Problem

AI integrations expose a recurring pattern: every new AI model needs custom connections to every data source and tool. The math is brutal; M models multiplied by N tools means M×N custom implementations. Teams routinely spend weeks building bespoke integrations for Slack, GitHub, and databases, only to repeat the entire process when switching AI providers.

Traditional APIs weren't designed for this. REST endpoints expect predictable request patterns, but AI agents generate hundreds of requests per conversation with wildly different latency requirements. GraphQL helps with flexible queries, but lacks built-in support for dynamic tool discovery or session management across multiple invocations.

Continue reading...

]]> <![CDATA[Building Production-Ready AI Agents with AWS Bedrock AgentCore]]> https://sph.sh/en/posts/bedrock-agentcore-production/ https://sph.sh/en/posts/bedrock-agentcore-production/ Mon, 01 Dec 2025 00:00:00 GMT Deploying LangChain or CrewAI agents to production requires session isolation, credential management, memory persistence, and observability: infrastructure that takes months to build correctly from scratch. Without it, agents lack security boundaries between users and have no durable state across sessions, which makes them unsuitable for real workloads.

Continue reading...

]]> <![CDATA[Aurora vs RDS: When to Choose Amazon Aurora (Architecture and Cost)]]> https://sph.sh/en/posts/amazon-aurora-introduction/ https://sph.sh/en/posts/amazon-aurora-introduction/ Sat, 29 Nov 2025 00:00:00 GMT Choosing between Amazon Aurora and standard RDS isn't straightforward. Aurora promises 5x MySQL and 3x PostgreSQL performance, automatic storage scaling to 128TB, and 99.99% availability. But it comes with additional complexity and cost that can surprise teams unfamiliar with its I/O pricing model.

The decision comes down to workload characteristics, operational requirements, and cost constraints. For a production MySQL or PostgreSQL workload that needs high availability or more than five read replicas, Aurora Standard is the sensible default. Switch to I/O-Optimized once I/O passes roughly a quarter of the bill, and stay on RDS when the engine is something else, or when the workload is small, predictable, and budget-bound.

What is Amazon Aurora?

Continue reading...

]]> <![CDATA[Breaking Through CloudFormation's 500 Resource Barrier: Practical Strategies for Large-Scale Infrastructure]]> https://sph.sh/en/posts/cloudformation-500-resource-limit-strategies/ https://sph.sh/en/posts/cloudformation-500-resource-limit-strategies/ Tue, 18 Nov 2025 00:00:00 GMT CloudFormation caps every stack at 500 resources, and no service quota request raises it. Serverless applications reach that ceiling faster than most teams expect. A single Lambda function with its role, policy, log group, version, and alarms already costs eight to twelve resources, so sixty functions consume the entire budget before a single table or queue is declared.

Continue reading...

]]> <![CDATA[DynamoDB Single-Table Design: A Comprehensive Modeling Guide]]> https://sph.sh/en/posts/dynamodb-single-table-design-comprehensive-guide/ https://sph.sh/en/posts/dynamodb-single-table-design-comprehensive-guide/ Mon, 17 Nov 2025 00:00:00 GMT Thinking in terms of relational tables when using DynamoDB causes more problems than it solves. The typical approach (separate tables for Users, Orders, and Products) leads to multiple round-trips, complex application logic, and unpredictable costs.

Single-table design stores multiple entity types in one table using generic partition and sort keys. Instead of fetching a customer from one table and their orders from another, you retrieve everything in a single request. Make it the default when entities are read together, and keep separate tables when they are not. The pattern pays for itself through data locality, not through a lower table count.

Core Principles

Continue reading...

]]> <![CDATA[AWS CDK Project Structure: Service-Based vs Domain-Based Organization]]> https://sph.sh/en/posts/aws-cdk-code-organization-service-vs-domain-based/ https://sph.sh/en/posts/aws-cdk-code-organization-service-vs-domain-based/ Sun, 16 Nov 2025 00:00:00 GMT An AWS CDK app is a program, so its folder and stack layout is a design decision the framework leaves to you. Skip that decision and the cost shows up later as tight coupling, circular dependencies between stacks, and deploys nobody can run without checking with another team first. The layout that holds up at scale is domain-based organization with a thin foundation layer: everything a business domain owns lives in one folder and one stack, while VPC, security, and monitoring sit in a shared stack beneath them.

Continue reading...

]]> <![CDATA[Reusable AWS CDK Constructs: Factory Functions, Builders, and Aspects]]> https://sph.sh/en/posts/aws-cdk-functional-patterns-reusable-configurations/ https://sph.sh/en/posts/aws-cdk-functional-patterns-reusable-configurations/ Sat, 15 Nov 2025 00:00:00 GMT AWS CDK lets you treat infrastructure as real code. Without shared patterns, though, teams end up with duplicated configurations, inconsistent settings, and deployment failures that a type checker could have caught. Two moves fix most of it: put every recurring resource behind a factory function, and enforce the settings nobody can afford to forget (RemovalPolicy, encryption, log retention) with CDK Aspects. Builders, composers, and custom L3 constructs are extensions of those two, added later.

The trade-off is indirection. Once a Lambda is created by createApiLambda, a reader has to open the factory to see what that function actually gets. That cost is worth paying for resources that repeat and policies that must hold everywhere, and it is not worth paying for a one-off bucket.<...

Continue reading...

]]> <![CDATA[Choosing IoT Messaging Protocols for Logistics: MQTT, AMQP, ZeroMQ, CoAP, and DDS Compared]]> https://sph.sh/en/posts/iot-messaging-protocols-logistics-tracking/ https://sph.sh/en/posts/iot-messaging-protocols-logistics-tracking/ Sun, 09 Nov 2025 00:00:00 GMT Protocol choice in an IoT logistics stack sets the ceiling on delivery guarantees, latency, and the monthly bandwidth bill. MQTT is the right default for fleet tracking and cold chain monitoring: it tolerates unreliable cellular links, ships three QoS levels, and has mature brokers and client libraries in every language you are likely to use. AMQP, ZeroMQ, CoAP, and DDS each beat it on one axis, so the useful question is which axis your deployment is constrained by.

Constraints That Drive the Choice

Continue reading...

]]> <![CDATA[Behavioral Design Patterns in TypeScript: Observer, Strategy, Command, State]]> https://sph.sh/en/posts/behavioral-patterns-reactive-programming/ https://sph.sh/en/posts/behavioral-patterns-reactive-programming/ Thu, 06 Nov 2025 00:00:00 GMT Behavioral patterns define how objects communicate and distribute responsibilities. The Gang of Four documented Observer, Strategy, Command, State, and Mediator for C++ and Smalltalk, languages where each one cost a page of boilerplate before it did anything useful. TypeScript changed that arithmetic. First-class functions, closures, and discriminated unions cover several of these patterns outright, and RxJS, Redux, and XState absorbed most of the rest into framework conventions.

Continue reading...

]]> <![CDATA[Creational Design Patterns in TypeScript: Singleton, Factory, Builder, Prototype]]> https://sph.sh/en/posts/creational-patterns-modern-typescript/ https://sph.sh/en/posts/creational-patterns-modern-typescript/ Thu, 06 Nov 2025 00:00:00 GMT Object instantiation in TypeScript rarely needs a Gang of Four pattern anymore. The default is the language feature: an ES module for a single shared instance, a factory function for conditional construction, object spread or structuredClone() for copies. Wrapping new in a class hierarchy that a module export already handles adds abstraction, harms testability, and obscures intent.

Singleton, Factory, Builder, and Prototype still earn their place, but the trigger is narrower than the textbooks suggest: shared configuration that many objects must apply consistently, or construction that has to be validated in steps. Everything else is better served by what TypeScript already gives you.

The Singleton Pattern: Anti-Pattern or Right Tool

Continue reading...

]]> <![CDATA[Modern React and TypeScript Design Patterns Beyond the Gang of Four]]> https://sph.sh/en/posts/design-patterns-beyond-gof/ https://sph.sh/en/posts/design-patterns-beyond-gof/ Thu, 06 Nov 2025 00:00:00 GMT The Gang of Four documented patterns for C++ and Smalltalk in 1994, before asynchronous programming, component composition, and reactive data flow shaped how applications get written. JavaScript and TypeScript grew their own answers: React Hooks for sharing stateful logic, Compound Components for flexible APIs, the Repository pattern for data access, and ES modules as encapsulation. For TypeScript work on the front end or in Node, one default carries most of the weight: reach for a language or framework feature first, and add a pattern only when it removes a problem you can name.

Continue reading...

]]> <![CDATA[Structural Design Patterns in React and TypeScript]]> https://sph.sh/en/posts/structural-patterns-component-composition/ https://sph.sh/en/posts/structural-patterns-component-composition/ Thu, 06 Nov 2025 00:00:00 GMT Structural patterns organize relationships between objects and classes. The Gang of Four documented Decorator, Adapter, Facade, Composite, and Proxy in 1994 for C++ and Smalltalk. Modern TypeScript and React absorbed all five into framework conventions, hooks, and type-safe wrappers.

The practical question in a React codebase is where a wrapper belongs. Composition stays the default inside code you own: hooks for cross-cutting behavior, plain components for hierarchy. Wrapping earns its place at the edges you do not control, such as third-party APIs, SDK setup, and access rules.

Decorator Pattern: Three Meanings in TypeScript

The term "decorator" means three different things in TypeScript ecosystems:

Continue reading...

]]> <![CDATA[Builder Pattern in TypeScript: Type-Safe Configuration Across Modern Applications]]> https://sph.sh/en/posts/builder-pattern-typescript/ https://sph.sh/en/posts/builder-pattern-typescript/ Wed, 05 Nov 2025 00:00:00 GMT The Builder pattern in TypeScript serves a different purpose than in traditional object-oriented languages. Java and C# use builders mainly to tame long lists of optional parameters. TypeScript can go further: generics and conditional types let a builder enforce constraints at compile time, so a misconfiguration surfaces as a type error in the IDE instead of a deployment failure.

That narrows where the pattern earns its keep. Reach for a builder when a configuration object carries interdependent constraints, which in practice means infrastructure definitions, query builders, and test data factories. Stay with a plain object literal or an options parameter everywhere else.

The Problem with Complex TypeScript Objects

Continue reading...

]]> <![CDATA[Middy and Zod: Type-Safe AWS Lambda Middleware Validation]]> https://sph.sh/en/posts/middy-builder-pattern-zod-validation/ https://sph.sh/en/posts/middy-builder-pattern-zod-validation/ Wed, 05 Nov 2025 00:00:00 GMT Middleware in a Lambda codebase drifts. Once a project has more than a handful of functions, every handler wires its own Middy chain: error handlers land in different positions, some endpoints authenticate and some do not, and a schema that no longer matches the handler signature fails only when traffic hits it.

A thin builder in front of Middy fixes that. It pins the middleware order in one place, carries the context types forward so TypeScript knows what the handler receives, and uses Zod instead of JSON Schema for validation. The cost is a few hundred lines of glue and a slightly heavier cold start, which is a trade worth taking for any API beyond a couple of endpoints.

The Problem with Standard Middleware Patterns

Continue reading...

]]> <![CDATA[OpenTelemetry Fundamentals: A Beginner's Guide to Modern Observability]]> https://sph.sh/en/posts/opentelemetry-fundamentals-beginner-guide/ https://sph.sh/en/posts/opentelemetry-fundamentals-beginner-guide/ Wed, 05 Nov 2025 00:00:00 GMT In distributed systems, a single user request can traverse dozens of services, so logs alone rarely explain a failure or a latency spike. Without a shared telemetry standard, every service emits data in its own format, and engineers correlate traces, metrics, and logs by hand across incompatible backends. OpenTelemetry (OTel) is the open-source framework that removes that mismatch: one vendor-neutral way to generate, process, and export telemetry from any language or runtime.

Continue reading...

]]> <![CDATA[7 Lesser-Known TypeScript Features: satisfies, Branded Types, and More]]> https://sph.sh/en/posts/typescript-essential-underutilized-features/ https://sph.sh/en/posts/typescript-essential-underutilized-features/ Tue, 04 Nov 2025 00:00:00 GMT Turning on strict in tsconfig.json feels like the end of the type-safety conversation. It is not. Indexed access still returns a type that hides undefined, a UserID still slots into a function that expects an OrderID, and a member added to a union still slips past every switch you already wrote.

The highest-value change is noUncheckedIndexedAccess, a compiler flag that strict does not turn on. Add it first, then reach for the type-level tools that cover the rest: satisfies, branded types, discriminated unions with exhaustiveness checking, type predicates, template literal types, and infer. All seven are compile-time constructs, so none of them cost anything at runtime.

The Gaps Strict Mode Leaves Open

Continue reading...

]]> <![CDATA[Network Fundamentals Every Software Developer Should Know]]> https://sph.sh/en/posts/network-fundamentals-developers-guide/ https://sph.sh/en/posts/network-fundamentals-developers-guide/ Thu, 30 Oct 2025 00:00:00 GMT Mysterious timeouts, slow APIs, and TLS errors in distributed systems are almost always network problems disguised as application problems. When developers lack a working model of TCP, DNS, and HTTP, diagnosis stalls at the wrong layer and fixes are guesswork.

The concepts below are the ones that surface most often in backend development and production troubleshooting: protocols, the connection lifecycle, debugging tools, and security basics. Each entry names what the concept is, when it matters, and which command answers the question.

Where Network Knowledge Pays Off

Perfect application code still fails when data movement between client and server is not understood. Developers struggle with:

Continue reading...

]]> <![CDATA[CloudEvents SDK for TypeScript: Standardizing Events in Serverless Architectures]]> https://sph.sh/en/posts/cloudevents-sdk-typescript-serverless/ https://sph.sh/en/posts/cloudevents-sdk-typescript-serverless/ Wed, 29 Oct 2025 00:00:00 GMT In event-driven architectures, every event source tends to describe events differently: one Lambda expects { userId: string }, another expects { user_id: string }, and a third uses { sub: string }. The cost of this heterogeneity is integration code that grows with the number of sources, and observability tools that cannot correlate events across systems. A standardized event envelope removes both problems; the cost is requiring every producer to adopt the same schema.

Continue reading...

]]> <![CDATA[Domain-Driven Design: Introduction and Fundamentals]]> https://sph.sh/en/posts/domain-driven-design-introduction/ https://sph.sh/en/posts/domain-driven-design-introduction/ Wed, 29 Oct 2025 00:00:00 GMT Domain-Driven Design (DDD) aligns the structure of your code with the business domain it serves. In complex, long-lived systems that alignment pays off: when classes and methods carry the names domain experts already use, business rules stay in one place instead of leaking across controllers and services. The cost is modeling time spent with people who know the business.

That cost is the whole decision. Rules that change often, a system you will own for years, and domain experts willing to sit with you: those three conditions make the investment worth it. Without them, a plain layered architecture serves you better.

What is Domain-Driven Design?

Continue reading...

]]> <![CDATA[Event Storming: A Practical Guide to Understanding Complex Domains]]> https://sph.sh/en/posts/event-storming-guide/ https://sph.sh/en/posts/event-storming-guide/ Tue, 28 Oct 2025 00:00:00 GMT A business process is hard to write down accurately. Interviews capture one person's slice of it, and the specification that follows misses the steps nobody thought to mention. Event Storming closes that gap in a workshop: business experts and engineers put domain events on a wall in chronological order until the whole process is visible at once.

If you have never run one, start with the Big Picture format and keep business experts in the room for all of it. Everything else the technique offers (detailed process design, aggregate boundaries, service boundaries) rests on the shared map that first session produces, and a session without domain experts turns into a design meeting where engineers guess.

What is Event Storming

Continue reading...

]]> <![CDATA[Dokploy + Cloudflare Tunnel on a VPS: Setup Guide]]> https://sph.sh/en/posts/cost-effective-vps-dokploy-cloudflared-setup/ https://sph.sh/en/posts/cost-effective-vps-dokploy-cloudflared-setup/ Sun, 26 Oct 2025 00:00:00 GMT Running a private server doesn't have to mean expensive cloud bills or complex infrastructure. The sweet spot often lies in combining simple, focused tools rather than reaching for enterprise platforms.

A production-ready private server needs three pieces: - VPS for affordable compute (~\$5-20/month) - Dokploy for Docker-based deployments with a clean UI - Cloudflared for secure access without opening ports

Together they cost about \$6-8 per month and handle multiple applications securely.

Prerequisites

Before starting, you'll need: - A domain name (for Cloudflare tunnel) - Basic terminal/SSH knowledge - A Cloudflare account (free tier works) - ~30 minutes of setup time

Continue reading...

]]> <![CDATA[Building CRM Systems with Event-Driven Architecture]]> https://sph.sh/en/posts/crm-event-driven-architecture/ https://sph.sh/en/posts/crm-event-driven-architecture/ Sun, 26 Oct 2025 00:00:00 GMT Traditional CRM systems store customer state directly: a record per customer, mutated in place with each interaction. That model breaks when the product needs real-time personalization, GDPR-compliant audit trails, and multi-channel orchestration at the same time. The current-state row has no memory of how it got there. Event-driven CRM inverts the model: every interaction is captured as an immutable event, and any view (profile, consent ledger, channel history) is a projection over that event stream.

A workable default: event sourcing on AWS with EventBridge and DynamoDB, plus CQRS projections for personalization and consent. The bill arrives as storage cost, eventual-consistency budgets, and replay windows.

The Event-Driven CRM Landscape

Continue reading...

]]> <![CDATA[Strapi vs Contentful vs Storyblok vs Kontent.ai: A Headless CMS Comparison]]> https://sph.sh/en/posts/multi-channel-content-management-headless-cms/ https://sph.sh/en/posts/multi-channel-content-management-headless-cms/ Sun, 26 Oct 2025 00:00:00 GMT Choosing a headless CMS gets hard the moment one content set has to feed a website, a mobile app, and whatever surface comes next. Four platforms dominate that shortlist: Strapi, Contentful, Kontent.ai, and Storyblok. They differ less in what they can store than in who absorbs the cost of using them, so the decision comes down to one question: is the bottleneck your content team or your engineering team?

Continue reading...

]]> <![CDATA[Traefik vs Nginx: A Practical Introduction for Nginx Users]]> https://sph.sh/en/posts/traefik-101-introduction/ https://sph.sh/en/posts/traefik-101-introduction/ Sun, 26 Oct 2025 00:00:00 GMT Traefik is a reverse proxy and load balancer built for infrastructure that changes while it runs. It watches your container orchestrator and updates its own routing rules; nginx expects you to edit a config file and reload. That single difference decides most of the choice. If your services are containers that come and go on their own schedule, put Traefik at that edge and keep nginx where the topology is stable.

The trade is operational convenience against a leaner data path. Traefik removes the edit-test-reload loop, and pays for it with a larger runtime footprint and a less mature rewrite and caching engine. For a fixed set of upstreams serving static files, that is a bad trade. For a fleet of containers redeployed several times a day, it is an easy one.

Continue reading...

]]> <![CDATA[The AI Assistance Spectrum: Choosing the Right Level for Professional Software Engineering]]> https://sph.sh/en/posts/ai-assistance-spectrum-professional-software-engineering/ https://sph.sh/en/posts/ai-assistance-spectrum-professional-software-engineering/ Fri, 24 Oct 2025 00:00:00 GMT How much AI assistance belongs in a professional engineering workflow? The useful answer is not yes or no but a level. Above a fully manual baseline sit six of them: review-only lookups, inline autocomplete, function generation, multi-file refactoring, autonomous agents, and "vibe coding," where nobody reads the output. Each step up buys speed and spends comprehension.

For most production code the defensible default is function-level generation. You write the signature and the intent, the model writes the body, and you review it like any other diff. Dial that down in regulated or security-critical paths, and up only where test coverage is strong enough to catch what the model gets wrong.

The Core Problem

Continue reading...

]]> <![CDATA[AI Developer Tools Landscape: Adoption Data and Trends]]> https://sph.sh/en/posts/ai-tools-developers-part-1/ https://sph.sh/en/posts/ai-tools-developers-part-1/ Fri, 03 Oct 2025 00:00:00 GMT AI coding assistants have reached near-universal adoption: DORA's 2025 research puts usage at around 90% of technologists. In the same period, a randomized trial by METR measured experienced open-source developers completing tasks 19% slower when they were allowed to use AI tools. Those same developers believed the tools had sped them up by 20%. Both findings can hold at once, and together they explain why so many rollouts stall.

Continue reading...

]]> <![CDATA[How to Adopt AI Coding Tools: From Pilot to Production]]> https://sph.sh/en/posts/ai-tools-developers-part-2/ https://sph.sh/en/posts/ai-tools-developers-part-2/ Fri, 03 Oct 2025 00:00:00 GMT Rolling AI coding tools out to an existing engineering organization fails on second-order costs rather than on the tools. Review queues lengthen, security controls written for human-authored code stop covering the surface, and the productivity story is not the one the pilot deck promised: METR's randomized study found experienced developers took 19% longer on their own repositories when they were allowed to use AI assistance, even though they expected to be faster. METR has since widened that estimate and reported a follow-up pointing the other way. Treat the size of the productivity effect as unsettled; the second-order costs are the part you can plan for.

Continue reading...

]]> <![CDATA[AI Coding Tools Security Risks and Governance]]> https://sph.sh/en/posts/ai-tools-developers-part-3/ https://sph.sh/en/posts/ai-tools-developers-part-3/ Fri, 03 Oct 2025 00:00:00 GMT AI coding assistants introduce a distinct class of security risk: they generate plausible-looking secrets from training data and normalize patterns that slip past standard secret-scanning heuristics. The default that survives contact with this is narrow. Treat every AI suggestion as untrusted input, scan it before it reaches a commit, and give the tool the least repository access it can work with. Everything else in an AI governance program is a way of enforcing that default at organizational scale.

Continue reading...

]]> <![CDATA[AI Coding Tools ROI: Measuring Real Business Value]]> https://sph.sh/en/posts/ai-tools-developers-part-4/ https://sph.sh/en/posts/ai-tools-developers-part-4/ Fri, 03 Oct 2025 00:00:00 GMT AI developer tooling budgets fail in a predictable direction. The seat price looks like the decision, and since GitHub moved Copilot to usage-based billing in June 2026 it is not even a fixed number. The lines that dominate year-one spend are the ones no vendor model contains: metered usage stacked on top of the seat, the productivity dip while everyone learns the tools, reviewer capacity to absorb a larger pull-request queue, and security controls retrofitted after the first incident.

Continue reading...

]]> <![CDATA[Lambda Layer Versioning Strategies for Multi-Environment Deployments]]> https://sph.sh/en/posts/lambda-layer-versioning-multi-environment/ https://sph.sh/en/posts/lambda-layer-versioning-multi-environment/ Fri, 03 Oct 2025 00:00:00 GMT AWS Lambda gives a layer an auto-incrementing integer and nothing above it. There is no semantic version, no promotion path between environments, and no record of which build a given function is running. Teams close that gap with whatever is nearest to hand, which is how dev, staging, and production end up on three different layer versions that nobody can map back to a change.

The default worth starting from is a version manifest: a YAML file in the repository that pins an explicit layer ARN per environment, promoted by commit and rolled back by revert. It gives you a Git audit trail and no lookups at deploy time. Three other strategies handle the cases where a hand-edited file does not fit.

When Layer Versions Diverge

Continue reading...

]]> <![CDATA[Role Expectations in Software Teams: RACI and DACI Frameworks]]> https://sph.sh/en/posts/role-expectations-team-performance/ https://sph.sh/en/posts/role-expectations-team-performance/ Fri, 03 Oct 2025 00:00:00 GMT Role ambiguity in software teams shows up as stalled work, not as an argument about roles. Gallup's 2024 US workplace research found that 46% of employees cannot say what is expected of them at work. When engineers don't know who owns a decision, the work either waits for a meeting or gets built twice on separate branches.

Two lightweight frameworks cover most of it. Use RACI for recurring workflows such as API design, deployment, and requirements, and DACI for one-off decisions such as architecture and tool selection. The default worth starting from is narrow: pick the two or three workflows that generate the most rework, write down who decides, and leave everything else informal until it starts costing you.

The Cost of Role Ambiguity

Continue reading...

]]> <![CDATA[Next.js Deployment Alternatives to Vercel: A Comprehensive Guide]]> https://sph.sh/en/posts/vercel-alternatives-nextjs-deployment/ https://sph.sh/en/posts/vercel-alternatives-nextjs-deployment/ Tue, 30 Sep 2025 00:00:00 GMT Vercel gives Next.js the smoothest deploy experience available, but the bill scales faster than the traffic. Bandwidth overages run \$0.15/GB and function invocations accumulate quietly, so a single marketing spike can multiply costs at the exact moment conversions matter most. The platform-specific APIs that make deployment easy also create lock-in that complicates any future move.

Cloudflare Workers with the OpenNext adapter is the default worth trying first for most Next.js applications: bandwidth is not metered, and the adapter keeps the application portable if the answer changes later. SST on AWS and a Docker VPS behind a CDN cover the cases where that default does not fit. Each target carries its own cost profile and its own migration details that the docs leave out.

Continue reading...

]]> <![CDATA[GitHub Spec Kit: A Guide to Spec-Driven AI Development]]> https://sph.sh/en/posts/github-speckit-ai-specification-framework/ https://sph.sh/en/posts/github-speckit-ai-specification-framework/ Wed, 24 Sep 2025 00:00:00 GMT Code generated by AI tools often passes a local smoke test but fails the production bar: ambiguous interfaces, unverified assumptions about upstream data, missing error handling, and structure that reflects the prompt rather than the codebase's conventions. The gap between "works in isolation" and "ships to production" is not a model capability problem; it is a specification problem. A clear, machine-readable specification of the interface, inputs, invariants, and error modes closes most of that gap before the model generates a single line.

Continue reading...

]]> <![CDATA[Building Ephemeral Preview Environments with AWS CDK and Serverless]]> https://sph.sh/en/posts/ephemeral-preview-environments-aws-serverless-cdk/ https://sph.sh/en/posts/ephemeral-preview-environments-aws-serverless-cdk/ Sun, 21 Sep 2025 00:00:00 GMT The Problem with Shared Staging Environments

A single shared staging environment becomes a bottleneck once a team opens more than one pull request per day against it. Concurrent PRs overwrite each other's database state, flap on the same feature flags, and compete for the same DNS record; test signal drops because a failure is as likely to mean "someone else's PR" as a real regression.

Continue reading...

]]> <![CDATA[What Is a Key-Value Store? Choosing the Right Solution]]> https://sph.sh/en/posts/redis-key-value-storage-fundamentals/ https://sph.sh/en/posts/redis-key-value-storage-fundamentals/ Mon, 15 Sep 2025 00:00:00 GMT Applying relational database patterns to key-value access workloads (session storage, caching, cart data) causes avoidable latency and schema complexity. Choosing the wrong storage model forces teams into index-tuning cycles that cannot fix a fundamental architectural mismatch. Key-value storage removes the mismatch: the data model matches the access pattern, so a lookup costs one hash probe instead of a query plan.

For distributed workloads, Redis is the default worth beating. The exceptions are narrow and predictable: etcd for configuration and coordination, DynamoDB for serverless traffic that swings, an in-process cache when there is only one server, and embedded Hazelcast when the whole deployment runs on the JVM. The work is recognizing which case you are in.

Continue reading...

]]> <![CDATA[Claude Code MCP Servers: Setup and Configuration Guide]]> https://sph.sh/en/posts/claude-code-mcp-ecosystem-mastery/ https://sph.sh/en/posts/claude-code-mcp-ecosystem-mastery/ Sat, 13 Sep 2025 00:00:00 GMT Claude Code's productivity ceiling rises sharply once MCP (Model Context Protocol) servers join the picture. Without them the workflow stays in copy-paste mode; with the right MCP servers wired in, Claude Code can act directly against your infrastructure, databases, and services. The setup worth starting from is small: the filesystem server plus one documentation server, with everything else added task by task and switched off again afterwards.

What Claude Code Is

Claude Code is a development environment with capabilities that most developers never explore. Three of them matter more than the rest.

The Three Interaction Modes

Continue reading...

]]> <![CDATA[The Hidden Cost of Cultural Blindness: When Global Engineering Teams Fail]]> https://sph.sh/en/posts/cultural-misunderstandings-global-engineering-teams/ https://sph.sh/en/posts/cultural-misunderstandings-global-engineering-teams/ Sat, 13 Sep 2025 00:00:00 GMT Cultural blindness on global engineering teams is expensive in a quiet way: teams report "ready" while meaning different things, and the gap surfaces at integration, not in code. Communication style, hierarchy expectations, and feedback delivery differ sharply across cultures, and a distributed team that never names those differences pays for them in rework, missed escalations, and people who stop speaking up.

Continue reading...

]]> <![CDATA[RACI and DACI for Software Teams: Fixing Role Ambiguity]]> https://sph.sh/en/posts/hidden-cost-role-ambiguity-software-team-performance/ https://sph.sh/en/posts/hidden-cost-role-ambiguity-software-team-performance/ Sat, 13 Sep 2025 00:00:00 GMT Role ambiguity (unclear ownership of decisions and deliverables) quietly drains engineering throughput through duplicated work, decision paralysis, and escalation overhead that never appears on any sprint board. Left unaddressed, it compounds across distributed teams where informal coordination no longer fills the gaps. Three frameworks remove most of that waste without adding process overhead: RACI matrices, swim-lane definitions, and escalation protocols.

If you adopt only one, make it RACI and apply it to recurring work such as API design, deployments, and requirement sign-off. Keep DACI for one-off architectural calls. The rule underneath both is the same: exactly one person is accountable for a decision, and everyone else knows whether they are consulted or only informed.

Continue reading...

]]> <![CDATA[Working with Difficult Coworkers in Software Teams: Beyond Textbook Solutions]]> https://sph.sh/en/posts/managing-difficult-coworkers-software-engineering-teams/ https://sph.sh/en/posts/managing-difficult-coworkers-software-engineering-teams/ Sat, 13 Sep 2025 00:00:00 GMT Generic workplace advice about difficult coworkers fails on engineering teams because the friction has technical roots. A blocked deployment, a code review that turns into a 47-message naming debate, or a teammate who vanishes during an outage are not personality clashes you can resolve with the standard Pessimist, Passive-Aggressive, and Know-It-All playbook. The behavior is amplified by code ownership, review authority, and on-call pressure.

That mismatch produces archetypes the management literature does not cover: the perfectionist blocker, the technical purist, the ghost colleague. Each one needs a different response, and that response is usually a process change; direct confrontation is rarely the first move.

Continue reading...

]]> <![CDATA[The Security Glossary: 50+ Terms Every Dev Team Should Know]]> https://sph.sh/en/posts/security-glossary-appendix/ https://sph.sh/en/posts/security-glossary-appendix/ Sat, 13 Sep 2025 00:00:00 GMT Security terminology confusion turns into architecture mistakes. A team that builds login on OAuth2 alone finds out weeks later that OAuth2 grants authorization and says nothing about identity. The fix is OIDC, and by then the token handling is already wired the wrong way on both the client and the API.

The terms below cover authentication, tokens, access control, and the Zero Trust vocabulary that shows up in design reviews. Each entry gives the definition, the implementation detail that decides whether it holds up, and the misconception that usually costs time. Where a sane default exists (OIDC over SAML for new systems, passkeys over passwords, short-lived access tokens over convenient ones), it is named.

Authentication Fundamentals

Continue reading...

]]> <![CDATA[Team Conflict Resolution: A Field Guide to Turning Dysfunction into High Performance]]> https://sph.sh/en/posts/team-conflict-resolution-field-guide/ https://sph.sh/en/posts/team-conflict-resolution-field-guide/ Sat, 13 Sep 2025 00:00:00 GMT Engineering teams lose velocity not when conflict appears, but when they lack a framework to distinguish productive disagreement from toxic dysfunction. Unresolved architectural standoffs, escalating code-review threads, and rising attrition share the same root: no shared process for surfacing and resolving friction early. The default worth adopting is narrow: classify the conflict by type before choosing an intervention, and anchor that classification in a working agreement the team drafts itself.

Continue reading...

]]> <![CDATA[pnpm Catalogs: Fix Dependency Drift in Monorepos]]> https://sph.sh/en/posts/pnpm-catalog-dependency-drift-solution/ https://sph.sh/en/posts/pnpm-catalog-dependency-drift-solution/ Wed, 10 Sep 2025 00:00:00 GMT In a JavaScript monorepo, dependency drift starts quietly. One service declares lodash at ^4.17.20, another at ^4.17.21, and the installer gives you both. Weeks later a shared helper behaves differently depending on which service imports it, and the bug reproduces on one machine out of five.

pnpm catalogs close that gap at the source. Each shared version is declared once in pnpm-workspace.yaml, packages reference it with catalog:, and a CI check fails the build when a package declares a version inline. The trade is that one file becomes a shared bottleneck: exactly what you want for react, and exactly what you do not want for a parser only one service uses.

The Dependency Drift Challenge

Continue reading...

]]> <![CDATA[How to Write a Technical RFC: Section-by-Section Guide]]> https://sph.sh/en/posts/anatomy-of-technical-rfc/ https://sph.sh/en/posts/anatomy-of-technical-rfc/ Mon, 08 Sep 2025 00:00:00 GMT An RFC for a critical system stalls for one of two reasons: reviewers cannot tell what problem it solves, or they cannot find the part that concerns them. Both are structural problems, and both are fixable before the first review comment lands.

Treat the RFC as a sales document. It sells one solution to four audiences with competing priorities: executives who fund the work, architects who vet the design, implementers who build it, and operators who carry the pager afterwards. Structure it so each audience finds its answer without reading the whole document, and put those answers in the order the audiences ask for them.

The Audience Sets the Order

Continue reading...

]]> <![CDATA[Authentication Strategies by Industry: Banking, Healthcare, E-commerce, SaaS]]> https://sph.sh/en/posts/authentication-authorization-strategies-by-business-domain/ https://sph.sh/en/posts/authentication-authorization-strategies-by-business-domain/ Mon, 08 Sep 2025 00:00:00 GMT Authentication and authorization are not a single technical decision; they are a composition of regulatory constraints, user expectations, failure modes, and audit requirements that differ sharply by business domain. A banking authentication flow and a social media one answer the same mechanical question ("is this request from the claimed user?") but the acceptable answers diverge on session length, multi-factor strength, recovery paths, and what a lockout looks like. Reusing an auth stack across domains rarely fails on the crypto primitives. It fails on the edge cases those domains handle differently: step-up auth in banking, delegated identity in IoT, graceful degradation in social.

Continue reading...

]]> <![CDATA[Code Review Culture: From Nitpicking to Knowledge Sharing]]> https://sph.sh/en/posts/code-review-culture-nitpicking-to-knowledge-sharing/ https://sph.sh/en/posts/code-review-culture-nitpicking-to-knowledge-sharing/ Mon, 08 Sep 2025 00:00:00 GMT A recurring signal in team retrospectives: junior developers who prefer working alone on a feature for two weeks over submitting code for review. That preference points to a specific failure mode in review culture.

The instinct behind rigorous reviews is sound, but the execution often creates an environment where getting code reviewed feels like defending a dissertation to a committee of critics more interested in finding faults than helping someone succeed.

Continue reading...

]]> <![CDATA[GitHub Copilot ROI: An Enterprise Cost Analysis Framework]]> https://sph.sh/en/posts/copilot-to-production-cost-analysis/ https://sph.sh/en/posts/copilot-to-production-cost-analysis/ Mon, 08 Sep 2025 00:00:00 GMT Measuring the return on an AI coding assistant requires separating productivity-proxy metrics (keystroke velocity, completion acceptance rate) from the outcomes the tool is supposed to move (delivery cycle time, defect rate, maintenance cost). Vendor-reported numbers are usually the first set; the second set determines whether the investment pays back. A controlled experiment run by GitHub researchers measured a 55.8% faster completion time on a scoped task. DORA's 2025 report, surveying delivery outcomes across thousands of organizations, finds AI adoption positively related to delivery throughput and still negatively related to delivery stability. Both findings can hold at once, and the gap between them is where the budget goes.

Continue reading...

]]> <![CDATA[Database Query Profiling: Systematic Optimization Journey]]> https://sph.sh/en/posts/database-query-profiling-100k-optimization/ https://sph.sh/en/posts/database-query-profiling-100k-optimization/ Mon, 08 Sep 2025 00:00:00 GMT Slow database queries are the most common source of runaway infrastructure costs in SaaS products: product searches taking 8 seconds and dashboards stalling for 45 seconds are symptoms, not root causes. Adding servers suppresses the symptoms while compounding the bill. Profile first, and scale only the part that profiling cannot explain. On PostgreSQL that means pgstatstatements plus EXPLAIN; on MongoDB it means the database profiler plus an explain plan on the pipeline.

Symptoms in a Multi-Tenant SaaS

Continue reading...

]]> <![CDATA[Lewis Deep Democracy in Engineering Teams: Beyond False Consensus]]> https://sph.sh/en/posts/deep-democracy-engineering-teams/ https://sph.sh/en/posts/deep-democracy-engineering-teams/ Mon, 08 Sep 2025 00:00:00 GMT Technical decisions that look unanimous often carry no real agreement behind them. The cause is usually rank and thin psychological safety rather than weak engineering. Arnold Mindell's Deep Democracy gives engineering groups a workable default: treat dissent as design input, record it next to the decision, and set review triggers that fire when the minority concern turns out to be right.

The Hidden Costs of False Consensus

In many architecture reviews everyone visibly agrees, then the decision quietly reverses six months later because no one felt safe voicing concerns. The pattern repeats wherever teams mistake silence for agreement.

Continue reading...

]]> <![CDATA[AI Code Review vs Human Review: What Each Catches]]> https://sph.sh/en/posts/llm-code-review-ai-finds-what-humans-miss/ https://sph.sh/en/posts/llm-code-review-ai-finds-what-humans-miss/ Mon, 08 Sep 2025 00:00:00 GMT Human code review misses a predictable class of defects: subtle SQL injection in a query builder that reads fine in isolation, the same flawed pattern repeated across every service that copied it, the security check skipped at the end of a long week. Reviewers focus on the diff in front of them, so systemic and cross-codebase issues slip through even when a senior engineer signs off.

AI reviewers catch exactly those patterns, but they miss business logic and architectural fit. The useful framing is not whether AI replaces human review; it is how to pair AI pattern recognition with human judgment so each covers the other's blind spot. Run both in parallel and consolidate the findings. Here is what each side catches and how to combine them.

Continue reading...

]]> <![CDATA[Migrating from Microservices Back to a Modular Monolith]]> https://sph.sh/en/posts/monolith-revenge-microservices-technical-debt/ https://sph.sh/en/posts/monolith-revenge-microservices-technical-debt/ Mon, 08 Sep 2025 00:00:00 GMT When a microservices architecture evolves into a distributed monolith, teams face the exact problems they were trying to avoid. Deployment coupling, data consistency struggles, and coordination overhead are the visible symptoms.

Consolidating those services into a modular monolith is a valid architectural pattern, not an admission of failure. For a team of roughly 50 engineers or fewer, the sensible default is one well-structured deployable per product team. Extract a service out of it only when a measured need justifies the operational cost.

When Adding a Cart Item Touches 47 Services

Continue reading...

]]> <![CDATA[Migrating from Node.js to Go on AWS Lambda: A Practical Guide]]> https://sph.sh/en/posts/nodejs-to-go-serverless-migration-guide/ https://sph.sh/en/posts/nodejs-to-go-serverless-migration-guide/ Mon, 08 Sep 2025 00:00:00 GMT Serverless bills have a way of growing faster than expected, and language choice is one of the first levers teams reach for. Node.js to Go is the usual candidate: a compiled binary with a small resident footprint, running on the same Lambda platform and the same event payloads.

The useful default is narrow. Stay on Node.js unless one specific service has a measurable volume, latency, or memory-cost problem, and then migrate that service alone. Go earns its keep on high-volume handlers with simple logic. It rarely earns anything on the complex business-logic service that took two years to get right, and knowing when not to migrate is the harder half of the decision.

When Go Makes Sense on Lambda

Continue reading...

]]> <![CDATA[Moment.js Alternatives for Node.js: Migration Guide and Comparison]]> https://sph.sh/en/posts/nodejs-zaman-yonetimi-zamana-hukmetmek/ https://sph.sh/en/posts/nodejs-zaman-yonetimi-zamana-hukmetmek/ Mon, 08 Sep 2025 00:00:00 GMT Time handling in production systems is a source of silent bugs because the defaults (local system time, implicit timezone, new Date() parsing) differ across nodes, languages, and layers. A payment rejected for a "past date transaction" even though the request carries a current local date is usually a timezone-offset bug between the client's wall clock, the application server's interpretation, and the database's storage format. UTC-everywhere with explicit offset conversion at the display boundary removes this entire class of bug, but requires discipline at every API, log, schema, and test fixture boundary.

Continue reading...

]]> <![CDATA[Observability Beyond Metrics: The Art of System Storytelling]]> https://sph.sh/en/posts/observability-beyond-metrics-system-storytelling/ https://sph.sh/en/posts/observability-beyond-metrics-system-storytelling/ Mon, 08 Sep 2025 00:00:00 GMT Every dashboard is green, every metric sits inside its threshold, and customers still report broken checkouts. Aggregate metrics describe components one at a time, so a failure that lives in the path between components stays invisible to each of them.

Distributed tracing closes that gap. A single trace follows one request through every service it touches and records the order in which things happened. The default worth reaching for is one complete user journey instrumented end to end, with business context attached to every span.

What a Single Trace Shows

Continue reading...

]]> <![CDATA[Deep Democracy Between Product and Tech Teams: From Deadline Dictatorship to Collaborative Delivery]]> https://sph.sh/en/posts/product-tech-deep-democracy/ https://sph.sh/en/posts/product-tech-deep-democracy/ Mon, 08 Sep 2025 00:00:00 GMT Product and Engineering often pull in opposite directions on the same scope. Product wants three months of features in six weeks; Engineering's estimates show twelve weeks; the meeting ends in a "compromise" that satisfies neither and ships buggy code into a quarter spent fixing fires. The cycle isn't bad luck or weak leadership; it's a missing decision-making system.

The teams that escape the cycle run a different decision process. The default worth adopting comes from Arnold Mindell's "Deep Democracy": surface every voice, including the dissenting one, before the group commits. Applied to product and engineering, it turns sprint planning from a negotiation into a design session with explicit rank, explicit assumptions and explicit trade-offs.

Continue reading...

]]> <![CDATA[From RFC to Production: What They Don't Tell You About Implementation]]> https://sph.sh/en/posts/rfc-to-production-implementation-reality/ https://sph.sh/en/posts/rfc-to-production-implementation-reality/ Mon, 08 Sep 2025 00:00:00 GMT RFCs rarely survive contact with production unchanged, and that is not automatically a failure. Architecture diagrams that looked clean in review become tangled six months later, as timeline pressure, missing requirements, and operational realities force trade-offs that were never in the design.

The pattern is not bad design or bad engineers. It is the normal cost of building complex systems under business constraints. The useful skill is separating signal from drift: a gap is signal when the design met a requirement nobody could have known about at review time, and drift when the design was abandoned because following it was inconvenient. Notification systems make a good worked example, because the specification is short and the operational surface is unusually wide.

Continue reading...

]]> <![CDATA[Building a Scalable User Notification System: Architecture and Database Design]]> https://sph.sh/en/posts/user-notification-system-part-1-architecture/ https://sph.sh/en/posts/user-notification-system-part-1-architecture/ Mon, 08 Sep 2025 00:00:00 GMT Multi-channel notification systems fail when teams model them as template-plus-send pipelines. A notification is a per-user routing decision: it may fan out, coalesce, suppress, or defer across email, SMS, push, and in-app channels. Without an explicit router layer, delivery guarantees collapse, user preferences get ignored, and compliance auditability becomes impossible.

Continue reading...

]]> <![CDATA[Real-time Notifications and Multi-Channel Delivery: WebSockets, Push, Email, and Beyond]]> https://sph.sh/en/posts/user-notification-system-part-2-realtime-delivery/ https://sph.sh/en/posts/user-notification-system-part-2-realtime-delivery/ Mon, 08 Sep 2025 00:00:00 GMT Real-time notifications sound simple until you deal with platform-specific push notification differences, WebSocket connection management at scale, and vendor costs that multiply with traffic.

Multi-channel notification systems reveal that the challenge isn't sending notifications; it is doing so reliably and at scale. Connection drain on WebSockets, token invalidation on push, bounce handling on email: every delivery mechanism carries its own quirks, limits, and failure modes.

Here are patterns for WebSocket connections, push notifications, email delivery, SMS, and webhooks that work in production environments. Each channel also carries its own latency expectation: WebSockets need sub-second delivery, while a few minutes is acceptable for email.

Continue reading...

]]> <![CDATA[Debugging Notification Delivery Failures at Scale]]> https://sph.sh/en/posts/user-notification-system-part-3-production-debugging/ https://sph.sh/en/posts/user-notification-system-part-3-production-debugging/ Mon, 08 Sep 2025 00:00:00 GMT Notification systems fail in ways that hurt most: silently, at peak load, when a launch or a campaign depends on them. Welcome emails don't arrive, push notifications time out, and in-app alerts lag, but the dashboards stay green because each subsystem looks fine in isolation.

Two defaults hold up under this kind of failure: rank monitoring signals by their distance from the user, and put a circuit breaker in front of every dependency you do not control. CPU and memory alerts describe the wreckage accurately and say nothing about which subsystem started it.

Cascade Failures Under Peak Traffic

Continue reading...

]]> <![CDATA[Notification Analytics and Performance Optimization: A/B Testing, Metrics, and Tuning at Scale]]> https://sph.sh/en/posts/user-notification-system-part-4-analytics-optimization/ https://sph.sh/en/posts/user-notification-system-part-4-analytics-optimization/ Mon, 08 Sep 2025 00:00:00 GMT Notification systems turn from basic delivery mechanisms into growth infrastructure through comprehensive analytics, systematic A/B testing, and performance optimization. Four building blocks carry that shift: multi-layered analytics pipelines, user journey tracking, safety-first experimentation, and cost-aware processing.

Once notification systems achieve basic functionality and stability, organizations face a new challenge: moving beyond simple delivery metrics to drive business growth. Product teams need answers about engagement rates, optimal timing, and content effectiveness. Engineering teams encounter performance bottlenecks as volume scales. Traditional monitoring approaches become insufficient when systems need to support millions of users while maintaining cost efficien...

Continue reading...

]]> <![CDATA[How to Write an Effective RFC: A Guide for Engineers]]> https://sph.sh/en/posts/writing-effective-rfcs-principal-engineer-guide/ https://sph.sh/en/posts/writing-effective-rfcs-principal-engineer-guide/ Mon, 08 Sep 2025 00:00:00 GMT Architectural disagreements surface late, when a feature is half-built and the cost of changing course is highest. Slack threads on the same decision drag across weeks, good ideas die in committee, and teams ship systems everyone "agreed" on yet interpreted differently. The RFC process exists to move that argument forward, before implementation locks the answer in.

An effective RFC is not documentation; it is the artifact that forces a team to reason through a problem and reach a decision that sticks. The shape of one depends on org size: a startup needs one or two pages, an enterprise needs more structure. A user notification system RFC serves as the running example here, because it shows both what the format buys and where it goes wrong.

Why RFCs Matter<...

Continue reading...

]]> <![CDATA[Build a URL Shortener with AWS CDK Part 3: Security & Custom Domains]]> https://sph.sh/en/posts/aws-cdk-link-shortener-part-3/ https://sph.sh/en/posts/aws-cdk-link-shortener-part-3/ Fri, 05 Sep 2025 00:00:00 GMT Building a production link shortener takes more than creating short URLs. It takes security measures that absorb legitimate scale while blocking abuse. Link shorteners are attractive targets for malicious actors who use them to distribute harmful content, bypass security filters, and run phishing campaigns.

Modern link shortener services need defense-in-depth protection combining input validation, rate limiting, authentication, and real-time monitoring. This approach protects both your service and the users who click shortened links.

In Part 1 and Part 2, we built the foundation and core redirect functionality. Now let's add the advanced features and security measures that separate a toy project from a production service.

Custom Domain Configuration...

Continue reading...

]]> <![CDATA[Build a URL Shortener with AWS CDK Part 4: Production Deployment]]> https://sph.sh/en/posts/aws-cdk-link-shortener-part-4/ https://sph.sh/en/posts/aws-cdk-link-shortener-part-4/ Fri, 05 Sep 2025 00:00:00 GMT Production optimization is about predictable performance under any load condition, not raw speed alone. Infrastructure that behaves perfectly in staging can still reveal scaling bottlenecks the first time traffic spikes.

The most common oversight is provisioning the database for steady-state traffic instead of peak load. A DynamoDB table sized for normal operations becomes a bottleneck when traffic increases 10x during a campaign or a product launch.

Parts 1-3 covered the foundation, core functionality, and security. What follows is the production layer: four environments, Lambda and DynamoDB tuning, cost controls, blue-green deployment, and the metrics worth alerting on.

Multi-Environment Deployment: Beyond Dev and Prod

Continue reading...

]]> <![CDATA[AWS CDK URL Shortener Part 5: Scaling & Long-term Maintenance]]> https://sph.sh/en/posts/aws-cdk-link-shortener-part-5/ https://sph.sh/en/posts/aws-cdk-link-shortener-part-5/ Fri, 05 Sep 2025 00:00:00 GMT A single-region CDK link shortener starts to show latency and availability gaps once traffic spreads across geographies. The DynamoDB table also turns into a single point of failure. Without multi-region replication and a disaster recovery plan, one regional outage takes the entire redirect service down. The default worth reaching for is DynamoDB Global Tables behind a global CloudFront distribution, with Route 53 failover routing as the escape hatch when a region goes dark.

Part 1 covered the foundational link shortener infrastructure. This part scales it globally and adds the operational layer that keeps it running: capacity planning, backup automation, and maintenance of the technical debt a long-lived system accumulates.

Multi-Region Architecture

Continue reading...

]]> <![CDATA[API Versioning with AWS API Gateway and CDK: A Practical Guide]]> https://sph.sh/en/posts/api-versioning-aws-cdk-complete-guide/ https://sph.sh/en/posts/api-versioning-aws-cdk-complete-guide/ Thu, 04 Sep 2025 00:00:00 GMT Path-based versioning (/v1/users, /v2/users) backed by an explicit lifecycle record per version is the default worth reaching for on API Gateway. It costs more infrastructure than one continuously evolving endpoint, and it is the approach that survives clients who cannot update on your schedule.

API evolution creates a standing conflict: the contract has to improve while existing integrations keep working. That conflict sharpens with enterprise clients, whose release cadences run from weekly deploys to update windows measured in quarters, and whose integrations are often embedded in systems nobody wants to touch. The CDK shape of the default is a version registry, per-version Lambda handlers, a discovery endpoint, and the deprecation signals that make an eventual sunset possible....

Continue reading...

]]> <![CDATA[Auth0 vs Firebase Auth vs Cognito vs Supabase Auth: Which to Choose]]> https://sph.sh/en/posts/auth-providers-mobile-web-api-comparison/ https://sph.sh/en/posts/auth-providers-mobile-web-api-comparison/ Thu, 04 Sep 2025 00:00:00 GMT Authentication provider choice sets development velocity, compliance ceiling, and monthly bill for years. Swapping providers later is one of the riskiest migrations a product can run. The default worth starting from is the managed provider already native to your primary platform: Firebase Auth for mobile-first consumer apps, Supabase Auth for PostgreSQL-backed products, Cognito inside AWS-native serverless stacks, and Auth0 when SAML/SSO and compliance artifacts are contract requirements. Custom JWT stays a learning exercise.

Continue reading...

]]> <![CDATA[Auth0 Multiple Audiences: Token Management in Micro Frontends]]> https://sph.sh/en/posts/auth0-multi-audience-micro-frontends-token-management/ https://sph.sh/en/posts/auth0-multi-audience-micro-frontends-token-management/ Thu, 04 Sep 2025 00:00:00 GMT An Auth0 access token carries exactly one audience. A micro frontend estate that talks to three separate APIs therefore needs three tokens, and the naive reading of that constraint is three logins. It does not have to be. Keep a single Auth0 session in the shell application. The shell trades that session for a per-audience access token on demand and passes tokens to each micro frontend over an origin-checked postMessage channel. The alternatives (one Auth0 application per micro frontend, one wide audience with fine-grained scopes, a server-side exchange service) all cost more and give back less.

Continue reading...

]]> <![CDATA[Auth0 React Native Session Management with Biometrics]]> https://sph.sh/en/posts/auth0-react-native-session-management-biometrics/ https://sph.sh/en/posts/auth0-react-native-session-management-biometrics/ Thu, 04 Sep 2025 00:00:00 GMT Session management in mobile applications presents challenges that web developers rarely encounter. A mobile app has to handle background states, network interruptions, biometric authentication, and platform-specific security constraints while keeping the experience seamless. The default that holds up across React Native apps: let the Auth0 tenant own refresh token rotation, keep tokens in Keychain or Keystore behind a biometric gate, and refresh preemptively instead of reacting to a 401.

The pieces are a token manager that refreshes on a timer and on network recovery, a biometric gate over platform secure storage, an app-state hook that enforces idle timeout, and an auth context that ties them together. Each step builds on the previous one, so the code is meant to be read in ord...

Continue reading...

]]> <![CDATA[AWS CDK Link Shortener Part 1: Project Setup & Basic Infrastructure]]> https://sph.sh/en/posts/aws-cdk-link-shortener-part-1/ https://sph.sh/en/posts/aws-cdk-link-shortener-part-1/ Thu, 04 Sep 2025 00:00:00 GMT Building a link shortener on AWS looks straightforward until redirect latency, URL validation, and per-link analytics become hard requirements. At millions of redirects per month, each architectural choice (storage engine, caching layer, CDN placement) affects both cost and tail latency.

The default that holds up is a single DynamoDB table, one small Lambda per route, and CloudFront in front of the redirect path. Get the project layout and the table schema right on day one, and the later parts of the series stay additive instead of turning into migrations. Redirect loops, malicious URLs, and abuse traffic are not late-stage concerns either: they decide what the create handler validates before it writes anything.

Architecture Overview

Continue reading...

]]> <![CDATA[AWS CDK Link Shortener Part 2: Core Functionality & API Development]]> https://sph.sh/en/posts/aws-cdk-link-shortener-part-2/ https://sph.sh/en/posts/aws-cdk-link-shortener-part-2/ Thu, 04 Sep 2025 00:00:00 GMT A link shortener is mostly a redirect engine. The short-code lookup and the HTTP 301 response are the only operations on the critical latency budget, and both have to stay under the user-perceived-instant threshold (around 200ms) even at high concurrency. The business logic around that hot path (analytics, rate limiting, link expiration, custom slugs) must not block the redirect; every feature added to the redirect handler directly costs latency at the edge.

Continue reading...

]]> <![CDATA[AWS Fargate 101: Serverless Containers Explained]]> https://sph.sh/en/posts/aws-fargate-101-serverless-containers/ https://sph.sh/en/posts/aws-fargate-101-serverless-containers/ Thu, 04 Sep 2025 00:00:00 GMT Running containers on EC2 means managing OS patches, cluster capacity, and host-level failures. That work scales with the number of hosts, not with application complexity. AWS Fargate takes the layer away: you hand AWS a container image and a CPU/memory pair, and it runs the task on infrastructure you never log into.

For new containerized workloads, Fargate is the sensible default. You pay a premium per unit of compute and stop maintaining hosts in exchange. The cases where that trade goes the wrong way are specific: GPU workloads, privileged containers, and steady high utilization that Reserved Instances or Spot already cover. Knowing which side of that line a workload falls on is most of the decision.

How to Think About Fargate

Continue reading...

]]> <![CDATA[AWS Fargate Production Patterns: Cost, Monitoring, Blue-Green]]> https://sph.sh/en/posts/aws-fargate-102-advanced-patterns/ https://sph.sh/en/posts/aws-fargate-102-advanced-patterns/ Thu, 04 Sep 2025 00:00:00 GMT In Fargate 101, we covered the basics of getting started. The patterns below come from what breaks after that: the bill, the parts of the infrastructure Fargate hides from you, and deployments that need a way back. Cost optimization, stateful containers, monitoring, and blue-green deploys, in that order.

Cost Optimization Strategies

As mentioned in the previous post, Fargate does cost more than EC2 for the same compute. Four levers close most of that gap: Spot capacity, right-sizing, ARM, and Savings Plans.

Fargate Spot for Interruptible Work

Continue reading...

]]> <![CDATA[AWS Fargate Troubleshooting: ENI Limits, Timeouts, Debugging]]> https://sph.sh/en/posts/aws-fargate-103-production-lessons/ https://sph.sh/en/posts/aws-fargate-103-production-lessons/ Thu, 04 Sep 2025 00:00:00 GMT Fargate hides resource constraints (ENI limits, memory leaks, and subnet exhaustion) behind green dashboards until a traffic spike makes them impossible to ignore. These failures share a pattern: the root cause is invisible to standard CloudWatch metrics, so tasks stall or crash with misleading errors. Five failure modes account for most of them, and each one has a check that identifies it in minutes.

Previous parts of this Fargate series (101, 102) covered the basics and advanced patterns. The next part, 104, covers Infrastructure-as-Code deployment patterns.

ENI Exhaustion

Symptom: Tasks never leave PENDING, and the service event log shows: [code block]

Continue reading...

]]> <![CDATA[Deploying AWS Fargate: CDK vs Terraform vs SAM]]> https://sph.sh/en/posts/aws-fargate-104-iac-deep-dive/ https://sph.sh/en/posts/aws-fargate-104-iac-deep-dive/ Thu, 04 Sep 2025 00:00:00 GMT Deploying Fargate services with CDK, Terraform, or SAM each produces working infrastructure, but the wrong choice creates maintenance overhead that compounds with every new service. For a new AWS-only service, CDK is the default: its high-level constructs collapse dozens of CloudFormation resources into a few lines. Terraform earns the switch when several teams share one change surface, or when a second cloud is realistic. SAM fits only when Fargate is a side note next to Lambda.

The differences rarely show up in the first deployment. They show up a year later, in how a change gets reviewed, how drift is detected, and how much code each new service costs to add.

IaC Tool Comparison for Fargate

Continue reading...

]]> <![CDATA[AWS Lambda Cold Start Optimization: Production Lessons Learned]]> https://sph.sh/en/posts/aws-lambda-guide-101-cold-start-optimization/ https://sph.sh/en/posts/aws-lambda-guide-101-cold-start-optimization/ Thu, 04 Sep 2025 00:00:00 GMT Cold start latency lands on the user's clock. For a Lambda function behind an interactive API, the cheapest wins come from three places: the runtime you pick, the size of the deployment package, and what the initialization code does before the handler runs. Work through those three first.

Provisioned concurrency removes the init cost from the requests it covers, and for a checkout endpoint with a latency SLA it is the right answer. Traffic above the provisioned count spills onto on-demand environments and can still cold start, so the scaling policy matters as much as the reservation. It also changes the bill enough to deserve a cost calculation before it ships.

Where Cold Starts Cost You

Continue reading...

]]> <![CDATA[AWS Lambda Memory Allocation and Performance Tuning: The Complete Guide]]> https://sph.sh/en/posts/aws-lambda-guide-102-memory-performance-tuning/ https://sph.sh/en/posts/aws-lambda-guide-102-memory-performance-tuning/ Thu, 04 Sep 2025 00:00:00 GMT After optimizing cold starts in the first part, the next challenge is making your Lambda functions run efficiently once they are warm. Memory allocation is the configuration knob with the widest blast radius, because one value sets the CPU share, the execution time, and the bill at once.

The working default: start at 1024 MB, then move only where a measured curve tells you to. The 128 MB default is almost always wrong for anything that computes, and the reflex fix of jumping straight to 3008 MB usually buys capacity that single-threaded code cannot spend.

Memory size is only one input. The model worth carrying is the relationship between allocated memory, the CPU that comes with it, and the GB-seconds you are billed for.

Lambda's Memory-CPU Model

Continue reading...

]]> <![CDATA[AWS Lambda Production Monitoring and Debugging: Proven Strategies]]> https://sph.sh/en/posts/aws-lambda-guide-103-production-monitoring-debugging/ https://sph.sh/en/posts/aws-lambda-guide-103-production-monitoring-debugging/ Thu, 04 Sep 2025 00:00:00 GMT Lambda functions fail silently in production when default CloudWatch metrics, cold-start noise, and missing distributed traces combine to obscure the root cause. Without a structured observability strategy, debugging shifts from data-driven analysis to guesswork under pressure. The setup that holds for most Lambda workloads is small: custom metrics keyed to business outcomes, X-Ray active tracing, and JSON logs carrying the request ID on every line.

Those three signals do different jobs. Metrics tell you that something broke, traces tell you where, and logs tell you why. Drop one and the other two leave a gap that surfaces at the worst moment: a payment handler that times out without logging an error, or a retry storm that never trips an alarm.

Continue reading...

]]> <![CDATA[AWS Lambda Cost Optimization: VPC, Layers, and Advanced Patterns]]> https://sph.sh/en/posts/aws-lambda-guide-104-advanced-patterns-cost-optimization/ https://sph.sh/en/posts/aws-lambda-guide-104-advanced-patterns-cost-optimization/ Thu, 04 Sep 2025 00:00:00 GMT Serverless bills rarely surprise anyone in the first month. They surprise people at scale. Over-provisioned memory, idle provisioned concurrency, and a monolithic handler each multiply the same invocation count month after month, and Lambda's per-invocation pricing makes all three cheap to make and expensive to keep.

Past a few dozen functions the questions change. How do you share dependencies without wrecking cold starts, when is VPC attachment worth its cost, how do you reach across accounts safely, and where does the bill actually go? The answer to the last one is unglamorous: audit memory and concurrency against CloudWatch data before touching anything else, because configuration drift usually costs more than code-level optimization recovers.

Continue reading...

]]> <![CDATA[Middy Alternatives: Building a Custom AWS Lambda Middleware Framework]]> https://sph.sh/en/posts/aws-lambda-middleware-middy-custom-framework/ https://sph.sh/en/posts/aws-lambda-middleware-middy-custom-framework/ Thu, 04 Sep 2025 00:00:00 GMT Middy covers the typical middleware needs of a small Lambda fleet, but the tradeoffs of its generic middleware-chain model become measurable once a service hits about 50 functions sharing a common middleware stack: per-invocation overhead, cold-start cost of the middleware chain, and the coupling that a shared wrapper creates between otherwise unrelated functions. At that scale the question becomes whether to continue layering on top of Middy's abstractions, replace them with AWS Lambda Powertools, or build a project-specific middleware framework that only pays for the hooks the fleet actually uses.

Continue reading...

]]> <![CDATA[AWS Lambda Middleware with Middy - Clean Code and Best Practices]]> https://sph.sh/en/posts/aws-lambda-middleware-middy-introduction/ https://sph.sh/en/posts/aws-lambda-middleware-middy-introduction/ Thu, 04 Sep 2025 00:00:00 GMT Lambda handlers tend to grow the same preamble: parse the JSON body, validate it, catch errors, attach CORS and security headers. Every endpoint repeats it, and every copy drifts a little from the last one.

Middy is the pragmatic default for Node.js handlers behind API Gateway. It wraps a handler in composable middleware, so parsing, validation, error shaping, and headers live in one shared chain instead of in each function. The cost is an extra dependency and a little cold-start weight, which is why a few function shapes are still better off without it.

What is Middy?

Continue reading...

]]> <![CDATA[AWS Lambda Performance Optimization: Sub-10ms Latency]]> https://sph.sh/en/posts/aws-lambda-millisecond-optimization-guide/ https://sph.sh/en/posts/aws-lambda-millisecond-optimization-guide/ Thu, 04 Sep 2025 00:00:00 GMT Latency-critical Lambda workloads are won or lost on the warm path. Cold starts get the attention, but a function that answers a request in single-digit milliseconds is mostly a story about which runtime loads your handler, how many network handshakes happen per invocation, and how much memory the function was given.

The default worth starting from: a compiled runtime on the hot path, clients created outside the handler, DynamoDB or ElastiCache behind it, and memory picked with AWS Lambda Power Tuning instead of guessed. Node.js can reach the same range, but it needs stricter bundle discipline to get there.

Where the Milliseconds Go

Continue reading...

]]> <![CDATA[S3 Presigned URLs for Large File Uploads with Lambda and CDK]]> https://sph.sh/en/posts/aws-lambda-s3-signed-urls-large-file-uploads/ https://sph.sh/en/posts/aws-lambda-s3-signed-urls-large-file-uploads/ Thu, 04 Sep 2025 00:00:00 GMT Proxying file uploads through Lambda is the obvious first design, and it holds until the files get large. API Gateway caps a REST API request payload at 10 MB and Lambda caps a synchronous invocation payload at 6 MB, so a 2 GB video never reaches the function. Even when the payload fits, Lambda is billed for every second the transfer is in flight.

S3 presigned URLs are the better default above a few megabytes. Lambda signs a URL and returns it, the client PUTs the bytes straight to S3, and an S3 event notification wakes a processing function once the object lands. The trade-off is that everything Lambda used to enforce mid-stream (file type, size limits, virus scanning) has to move to signing time or to the event handler afterwards.

Continue reading...

]]> <![CDATA[AWS Lambda with TypeScript: Production Best Practices]]> https://sph.sh/en/posts/aws-serverless-typescript-guide/ https://sph.sh/en/posts/aws-serverless-typescript-guide/ Thu, 04 Sep 2025 00:00:00 GMT A traditional Express.js API on EC2 delivers fixed costs, predictable scaling, and 99.9% uptime. The case for Lambda is usually triggered by a specific mismatch: a feature that needs to process 50,000 webhooks in under 10 minutes, once per month.

Keeping EC2 instances running 24/7 for a 10-minute monthly spike is wasteful, and Lambda removes that idle cost. What it adds is a different set of failure modes: an account-wide concurrency limit, cold starts on the critical path, and a billing model where one careless DynamoDB Scan costs more than all the compute around it.

Common Objections to Serverless

Continue reading...

]]> <![CDATA[Bus Factor in Engineering Teams: How to Reduce Knowledge Risk]]> https://sph.sh/en/posts/bus-factor-knowledge-management-engineering-teams/ https://sph.sh/en/posts/bus-factor-knowledge-management-engineering-teams/ Thu, 04 Sep 2025 00:00:00 GMT When critical knowledge about a system lives in a single person's head, that person becomes a single point of failure. This is the bus factor risk. It bites hardest because the knowledge is rarely written down. Payment flows, fraud-detection quirks, and the deploy steps everyone leaned on walk out with the engineer, and recovery slows down at exactly the moment an incident hits. The remedy that holds up is narrow: document the critical paths first, then prove the documentation works by handing it to someone who did not build the system.

Understanding the Bus Factor

Continue reading...

]]> <![CDATA[Circuit Breaker Pattern: Building Resilient Microservices That Don't Cascade Failures]]> https://sph.sh/en/posts/circuit-breaker-pattern-resilient-microservices/ https://sph.sh/en/posts/circuit-breaker-pattern-resilient-microservices/ Thu, 04 Sep 2025 00:00:00 GMT A slow dependency is more dangerous than a dead one: requests that wait 30 seconds to time out exhaust thread pools and propagate failure upstream across otherwise healthy services. Without a containment mechanism, a single degraded downstream call can saturate an entire distributed system in seconds. The Circuit Breaker pattern contains that failure with three states and two numbers: the request timeout, and the error rate that trips the breaker. The timeout matters most: two to three times your P99 latency, rather than whatever the client library ships as a default. Sized that way, the breaker trips before the thread pool drains.

The Problem: When Slow is Worse Than Dead

Continue reading...

]]> <![CDATA[CQRS with AWS Lambda, EventBridge, and DynamoDB]]> https://sph.sh/en/posts/cqrs-pattern-serverless-nodejs/ https://sph.sh/en/posts/cqrs-pattern-serverless-nodejs/ Thu, 04 Sep 2025 00:00:00 GMT CQRS (Command Query Responsibility Segregation) separates write operations (commands) from read operations (queries). Instead of one model serving both, each side gets a shape that fits its job: the write side validates and stores, the read side answers questions quickly.

Reach for the split when the two workloads have genuinely different shapes: a read-to-write ratio of 10:1 or higher, different latency budgets, or query patterns that a write-optimized schema cannot serve. The setup below uses one DynamoDB table per side, a separate Lambda function per path, and EventBridge carrying the events that keep the read model current. When reads and writes look alike, the pattern only adds moving parts.

The Core Principle

Continue reading...

]]> <![CDATA[How to Choose a Database: SQL vs NoSQL vs NewSQL vs Edge]]> https://sph.sh/en/posts/database-selection-comprehensive-guide/ https://sph.sh/en/posts/database-selection-comprehensive-guide/ Thu, 04 Sep 2025 00:00:00 GMT Choosing the wrong database engine for a workload forces expensive migrations later: a product catalog that runs fine on MongoDB at 1,000 records can degrade to full-collection scans at 100,000 without proper schema and index design. The mismatch between data model and access pattern is the root cause, not the database itself. SQL, NoSQL, NewSQL, and edge database categories each carry concrete trade-offs that point to the right choice before the first migration becomes necessary.

Continue reading...

]]> <![CDATA[Dead Letter Queue Strategies: Production-Ready Patterns for Resilient Event-Driven Systems]]> https://sph.sh/en/posts/dead-letter-queue-production-strategies/ https://sph.sh/en/posts/dead-letter-queue-production-strategies/ Thu, 04 Sep 2025 00:00:00 GMT Dead Letter Queues hold messages that a consumer cannot process after its retry budget is exhausted. Without a DLQ, a poison pill either blocks the primary queue at head-of-line or silently disappears with the failed handler; either outcome loses both the event and the operational signal that something went wrong. The DLQ is a separation of concerns between "messages to process" and "messages that need human or tooling intervention", and it only works when the retry policy, alerting, and replay tooling around it are designed alongside.

Continue reading...

]]> <![CDATA[Documentation as Infrastructure: Scaling Knowledge Across Engineering Teams]]> https://sph.sh/en/posts/documentation-as-infrastructure-scaling-knowledge/ https://sph.sh/en/posts/documentation-as-infrastructure-scaling-knowledge/ Thu, 04 Sep 2025 00:00:00 GMT Documentation debt slows engineering teams in ways that look fine until the wrong person leaves. The cost surfaces during a payment incident, a migration, or an audit: the written procedure exists but the deep system understanding doesn't. The documentation that survives that moment has three layers: decisions captured as RFCs and ADRs, system reference generated from the systems themselves, and process docs written from real examples. Everything else is tooling and the review habits that keep those three layers current.

Common Documentation Patterns

Some recurring challenges in documentation appear across many organizations:

Continue reading...

]]> <![CDATA[Kafka vs SQS vs EventBridge: Choosing Event-Driven Tools]]> https://sph.sh/en/posts/event-driven-systems-tools-comparison/ https://sph.sh/en/posts/event-driven-systems-tools-comparison/ Thu, 04 Sep 2025 00:00:00 GMT Choosing an event-driven tool is less about hype and more about matching three shapes: a queue, a fan-out topic, or a router. Start with the managed primitive your cloud already gives you for that shape. Move to Kafka only when you need event replay, ordering across a partitioned key space, or throughput a managed queue quota cannot cover.

The rest of the decision comes down to delivery guarantees, message size limits, and what happens to a message nobody can process.

Message Patterns: The Foundation

Each pattern carries different tools and trade-offs:

Continue reading...

]]> <![CDATA[Frontend Build Tools History: From jQuery and Grunt to Bower]]> https://sph.sh/en/posts/frontend-tooling-evolution-101-the-early-web-era/ https://sph.sh/en/posts/frontend-tooling-evolution-101-the-early-web-era/ Thu, 04 Sep 2025 00:00:00 GMT Frontend tooling began as a concatenate-and-minify problem: hand-managed script order, shell scripts for deployment, and the first wave of task runners (Make, then Grunt, then Gulp) as teams outgrew the manual process. The pressure on this early tooling came not from build speed but from dependency ordering and cross-browser compatibility: the difference between a site that loaded and one that produced silent JavaScript errors.

The story starts in the pre-build era (1995-2006) of hand-written scripts and browser-specific hacks, moves through jQuery's arrival as a compatibility layer, and ends in 2012 with Bower, the first taste of real package management on the frontend.

The Pre-jQuery Dark Ages (1995-2006)

Continue reading...

]]> <![CDATA[Grunt vs Gulp vs Webpack: How Modern Bundling Emerged]]> https://sph.sh/en/posts/frontend-tooling-evolution-102-task-runners-and-bundlers/ https://sph.sh/en/posts/frontend-tooling-evolution-102-task-runners-and-bundlers/ Thu, 04 Sep 2025 00:00:00 GMT Manual shell-script build pipelines break silently across machines, accumulate tribal knowledge, and collapse when the one developer who understands them moves on. Undocumented build failures block deployments and make the toolchain itself a source of risk. Grunt answered that with declarative task automation, and Gulp replaced its configuration blocks with code streams. Browserify and webpack then moved the model from task orchestration to dependency-graph bundling.

Grunt arrived into that environment as a clear step forward. For the first time, teams had a tool that could automate the boring, error-prone processes while being configurable enough to handle complex projects. But as with every tool in this series, Grunt solved one set of problems while revealing entirely new ones....

Continue reading...

]]> <![CDATA[esbuild, SWC, and Vite: Why Native Build Tools Replaced Webpack]]> https://sph.sh/en/posts/frontend-tooling-evolution-103-performance-revolution/ https://sph.sh/en/posts/frontend-tooling-evolution-103-performance-revolution/ Thu, 04 Sep 2025 00:00:00 GMT JavaScript-based bundlers like webpack hit a hard performance ceiling: single-threaded execution, per-file AST parsing, and garbage collection pauses pushed production builds past 60 seconds on large React apps. Slow feedback loops break developer focus and inflate CI costs at every merge. esbuild, SWC, and Vite broke through that ceiling by moving the hot path into native compiled code.

As teams grew larger, build times became bottlenecks for everything: local development, CI/CD pipelines, and deployment processes. Development teams spent more time waiting for builds than actually writing code.

That pressure produced the performance revolution in frontend tooling: a shift away from JavaScript-based tools toward native compiled ones.

Continue reading...

]]> <![CDATA[The Future Landscape: Edge Computing and Beyond]]> https://sph.sh/en/posts/frontend-tooling-evolution-104-the-future-landscape/ https://sph.sh/en/posts/frontend-tooling-evolution-104-the-future-landscape/ Thu, 04 Sep 2025 00:00:00 GMT Frontend build tooling has crossed a threshold where bundler speed is no longer the limiting factor for developer experience; the next frontier is how build tooling interacts with where and how the code will run. Edge runtimes, deployment platforms, and framework-level primitives (React Server Components, streaming SSR, partial hydration) now influence the build pipeline as much as the bundler does. The boundary between "build" and "deploy" is dissolving into a single pipeline that targets a set of runtimes rather than a single server.

Continue reading...

]]> <![CDATA[Git Branching Strategies: Real-World Lessons for Different Teams and Products]]> https://sph.sh/en/posts/git-branching-strategies-real-world/ https://sph.sh/en/posts/git-branching-strategies-real-world/ Thu, 04 Sep 2025 00:00:00 GMT Choosing the wrong Git branching strategy for your team size and release cadence causes coordination overhead, broken main branches, and blocked deployments. The mismatch compounds as teams grow: a strategy tuned for three developers adds unnecessary friction at twenty-five, and vice versa. For most teams the right default is GitHub Flow: short feature branches, one pull request gate, merge to main. The other four models each earn their overhead only under a specific constraint, whether that is continuous deploys, QA approval gates, environment schedules, or compliance audit trails.

Five Production-Relevant Strategies

Continue reading...

]]> <![CDATA[Google Closure Compiler: Legacy, Lessons, and Modern Alternatives]]> https://sph.sh/en/posts/google-closure-compiler-legacy-modern-web-development/ https://sph.sh/en/posts/google-closure-compiler-legacy-modern-web-development/ Thu, 04 Sep 2025 00:00:00 GMT Google's Closure Compiler brought whole-program static analysis to JavaScript in 2009: cross-file dead code elimination and JSDoc-based type checking. That was years before webpack, esbuild, or TypeScript made those capabilities mainstream. Teams unaware of the lineage keep rediscovering the same ideas and crediting them to newer tools. Some of Closure's innovations survived into today's build toolchain, others did not, and the difference explains why parts of the modern stack look the way they do.

What Made Closure Compiler Significant

The Closure Compiler wasn't just another minifier. It was a complete static analysis engine that could understand your JavaScript code at a level that seemed almost magical for its time.

Continue reading...

]]> <![CDATA[Mermaid Diagram Types: Examples of Every Chart Type]]> https://sph.sh/en/posts/mermaid-diagram-showcase/ https://sph.sh/en/posts/mermaid-diagram-showcase/ Thu, 04 Sep 2025 00:00:00 GMT Mermaid turns plain text into diagrams, so a chart can live in the same file as the code it documents. Every diagram type below comes with a working example you can copy and adapt. Click any diagram to open it fullscreen.

1. Flowchart - Process Flow Visualization

Flowcharts are perfect for visualizing processes, decision trees, and system flows.

The styled nodes below use a single neutral fill (#1e293b) and carry meaning in the stroke color, which keeps a dense diagram readable on a dark background.

[code block]

2. Sequence Diagram - Interaction Timeline

Perfect for documenting API calls, user interactions, and system communications.

[code block]

Continue reading...

]]> <![CDATA[Advanced Micro Frontend Patterns: Performance, Debugging, and Production Lessons]]> https://sph.sh/en/posts/micro-frontends-advanced-patterns-debugging/ https://sph.sh/en/posts/micro-frontends-advanced-patterns-debugging/ Thu, 04 Sep 2025 00:00:00 GMT Micro Frontend Series Navigation

- Part 1: Architecture fundamentals and implementation types - Part 2: Module Federation, communication patterns, and integration strategies - Part 3 (You are here): Advanced patterns, performance optimization, and production debugging

Prerequisites: Part 1 fundamentals and Part 2 implementation patterns.

---

Continue reading...

]]> <![CDATA[Micro Frontend Architecture Fundamentals: From Monolith to Distributed Systems]]> https://sph.sh/en/posts/micro-frontends-architecture-fundamentals/ https://sph.sh/en/posts/micro-frontends-architecture-fundamentals/ Thu, 04 Sep 2025 00:00:00 GMT Micro frontend architectures split a single-page frontend into independently deployable, independently owned slices that compose at runtime. They solve a specific set of problems (team-size scaling, independent release cadence, technology flexibility) and introduce a corresponding set of new ones (runtime composition complexity, shared-dependency management, cross-slice state, cross-slice performance). The choice to adopt them is rarely a clean win; it is a trade of coordination overhead for release autonomy, and the trade only pays back at certain team sizes and product-structure boundaries.

Continue reading...

]]> <![CDATA[Micro Frontend Implementation Patterns: Module Federation and Beyond]]> https://sph.sh/en/posts/micro-frontends-implementation-patterns/ https://sph.sh/en/posts/micro-frontends-implementation-patterns/ Thu, 04 Sep 2025 00:00:00 GMT Micro Frontend Series Navigation

- Part 1: Architecture fundamentals and implementation types - Part 2 (You are here): Module Federation, communication patterns, and integration strategies - Part 3: Advanced patterns, performance optimization, and production debugging

Prerequisites: Part 1 covers the concepts assumed below. If you're new to micro frontends, start there.

---

Part 1 covered the fundamental architectural patterns for micro frontends. Module Federation is the dominant runtime integration approach, and the practical work lives in its setup, the communication patterns around it, and the debugging strategies production systems demand.

Continue reading...

]]> <![CDATA[Replacing Factories and DI in Node.js with Pure Functions]]> https://sph.sh/en/posts/microservices-to-serverless-functions-nodejs/ https://sph.sh/en/posts/microservices-to-serverless-functions-nodejs/ Thu, 04 Sep 2025 00:00:00 GMT Changing one validation rule in a Node.js payment service can eat an afternoon when the rule sits behind a factory, a dependency injection container, and a stack of interfaces with one implementation each. The cost is the distance between the change you want and the file that holds it. Xia and colleagues measured where that time goes in a field study for IEEE Transactions on Software Engineering: seven projects, 79 professional developers, 3,244 working hours. Comprehension took 57.62% of the working day, navigation another 23.96%, and editing 5.02%.

Continue reading...

]]> <![CDATA[Re.Pack and Rspack for Cross-Platform Micro Frontends]]> https://sph.sh/en/posts/mobile-micro-frontends-multi-channel-production/ https://sph.sh/en/posts/mobile-micro-frontends-multi-channel-production/ Thu, 04 Sep 2025 00:00:00 GMT Mobile-first micro frontend architectures rarely survive contact with a second channel unchanged. The assumptions that made the architecture work on mobile (WebView lifecycle, native bridge, native gestures, per-channel asset bundles) either do not map to web and desktop at all, or they map at a performance cost that erases the point of sharing the code in the first place. True multi-channel micro frontends (mobile, web, desktop Electron) require a runtime abstraction layer and a discipline around channel-specific code paths, not just "build once, deploy everywhere."

Continue reading...

]]> <![CDATA[Mobile Micro Frontends with React Native Expo: WebView Architecture and Real-World Implementation]]> https://sph.sh/en/posts/mobile-micro-frontends-react-native-expo-webviews/ https://sph.sh/en/posts/mobile-micro-frontends-react-native-expo-webviews/ Thu, 04 Sep 2025 00:00:00 GMT Mobile teams increasingly face the challenge of integrating multiple web-based services from different teams, each with their own deployment cycles and tech stacks. Tight delivery timelines compound this complexity when web teams can't pause their development to assist with mobile integration.

The default worth reaching for is a native React Native shell that embeds each web app in its own WebView. Every web team keeps its own bundler and release cadence. The mobile side pays for that in memory pressure, bundle size, and navigation glue that has to be written by hand.

Mobile Micro Frontend Series

This is Part 1 of the mobile micro frontends series:

Continue reading...

]]> <![CDATA[React Native WebView Communication: postMessage Bridge Patterns]]> https://sph.sh/en/posts/mobile-micro-frontends-webview-communication-patterns/ https://sph.sh/en/posts/mobile-micro-frontends-webview-communication-patterns/ Thu, 04 Sep 2025 00:00:00 GMT WebView-to-native communication in a mobile micro frontend fails in three concrete ways: messages arrive out of order, TypeScript types diverge between the web and native sides, and JavaScript exceptions inside a WebView surface no stack trace in native crash reporters. Without a structured bridge layer these failures compound; a race condition in message passing can silently swallow payment confirmations or auth tokens.

Continue reading...

]]> <![CDATA[Monolith to Microservices in Node.js: A Migration Guide]]> https://sph.sh/en/posts/monolith-to-microservices-nodejs-evolution/ https://sph.sh/en/posts/monolith-to-microservices-nodejs-evolution/ Thu, 04 Sep 2025 00:00:00 GMT Monolith Maintainability Limits

Node.js monoliths degrade predictably. A single shared deployment boundary lets one slow domain block the whole release cycle, and a peak-traffic failure in one feature takes the rest of the process down with it. The architectural fix is not refactoring the monolith; it is decomposing it into independently deployable, event-driven functions.

Boundaries decide the outcome. Pick them from how the code actually changes and fails, keep the system releasable while the split is in progress, and the migration stays reversible at every step.

How the Monolith Grew

An e-commerce platform of this shape usually begins as a straightforward Node.js Express application:

[code block]

Continue reading...

]]> <![CDATA[Multi-Account AWS Architecture: Event-Driven Systems at Scale]]> https://sph.sh/en/posts/multi-account-aws-event-driven-architecture/ https://sph.sh/en/posts/multi-account-aws-event-driven-architecture/ Thu, 04 Sep 2025 00:00:00 GMT Single-Account Architecture Limits

Multi-account AWS architecture becomes essential when organizations reach certain scale and complexity thresholds. The shape worth defaulting to is one account per service team, a shared EventBridge bus between them, and event choreography instead of a central orchestrator.

Consider a multi-service platform with nine development teams deploying to the same AWS account. This works for small organizations, but it creates several critical problems as scale increases.

Common Single-Account Anti-Patterns

Multiple teams sharing a single AWS account often leads to resource conflicts, security issues, and operational complexity. Here's a typical anti-pattern configuration:

[code block]

Continue reading...

]]> <![CDATA[OpenTelemetry in React Native: Building Production-Ready Observability]]> https://sph.sh/en/posts/opentelemetry-react-native-firebase-observability/ https://sph.sh/en/posts/opentelemetry-react-native-firebase-observability/ Thu, 04 Sep 2025 00:00:00 GMT Many React Native teams ship without production visibility. Crashes that never reproduce locally, performance complaints with no timing data behind them, support tickets that describe a symptom but never the state the app was in.

A workable default: the OpenTelemetry JavaScript SDK inside the app, exporting over OTLP to a collector you run, with Firebase Performance and Crashlytics kept as a second signal. Vendor SDKs install faster, but the collector is what lets you swap backends later without shipping a new build, and it keeps APM credentials out of the app bundle.

Mobile Observability Requirements

Continue reading...

]]> <![CDATA[Axios vs Fetch vs Undici: Node.js HTTP Clients Compared]]> https://sph.sh/en/posts/server-side-http-clients-comparison/ https://sph.sh/en/posts/server-side-http-clients-comparison/ Thu, 04 Sep 2025 00:00:00 GMT Picking an HTTP client for Node.js server-to-server calls is rarely a one-time decision: native fetch, Axios, undici, and Effect each behave differently under connection pressure, retry storms, and partial failures. For a service that spends its day calling other services, undici is the default worth reaching for. It owns its connection pool, its timeouts are explicit, and it is the same engine native fetch already runs on.

The failure that costs the most is also the easiest to ship: native fetch with no timeout. Hanging connections hold Lambda concurrent executions open, so a slow upstream becomes a bill and an outage at once. Connection pooling, timeout semantics, and circuit-breaker support decide how a client behaves on its worst day; feature lists do not.

Continue reading...

]]> <![CDATA[Serverless Framework vs AWS CDK: Should You Migrate? (Part 1)]]> https://sph.sh/en/posts/serverless-to-cdk-migration-part-1/ https://sph.sh/en/posts/serverless-to-cdk-migration-part-1/ Thu, 04 Sep 2025 00:00:00 GMT Serverless Framework and AWS CDK solve overlapping problems with different philosophies. Serverless Framework is a YAML-driven, provider-neutral abstraction over a Lambda-centric deployment unit; CDK is a typed, AWS-native synthesis layer over CloudFormation. When Serverless Framework introduced paid licensing, staying put stopped being the cost-free default, and the comparison became worth making again.

Continue reading...

]]> <![CDATA[Migrating from Serverless Framework to AWS CDK: Part 2 - Setting Up Your CDK Environment]]> https://sph.sh/en/posts/serverless-to-cdk-migration-part-2/ https://sph.sh/en/posts/serverless-to-cdk-migration-part-2/ Thu, 04 Sep 2025 00:00:00 GMT A CDK project that works for one developer rarely survives contact with a team. The flat, single-stack layout from most tutorials breaks down once several engineers deploy Lambda functions across multiple environments at the same time. Shared stacks create merge conflicts, ownership gets blurry, and nobody agrees on where a new file belongs.

The fix is a project structure that isolates units of work so engineers can move in parallel, while keeping the conventions Serverless Framework users already know. For teams leaving Serverless Framework for CDK, this is the layout that scales from a first migration to a production platform.

Continue reading...

]]> <![CDATA[Migrating from Serverless Framework to AWS CDK: Part 3 - Lambda Functions and API Gateway]]> https://sph.sh/en/posts/serverless-to-cdk-migration-part-3/ https://sph.sh/en/posts/serverless-to-cdk-migration-part-3/ Thu, 04 Sep 2025 00:00:00 GMT Lambda functions and API Gateway configurations are where migration complexity concentrates. A YAML-to-TypeScript conversion looks mechanical until bundling, memory sizing, and error handling each turn into a separate decision.

The pattern that holds up is a single shared NodejsFunction construct: runtime, architecture, memory, tracing, and bundling defaults live in one place, and every prop stays overridable for the functions that need something else. API Gateway gets the same treatment, with validators, authorizers, and integration responses defined once and reused across routes.

Continue reading...

]]> <![CDATA[Migrating from Serverless Framework to AWS CDK: Part 4 - Database and Environment Management]]> https://sph.sh/en/posts/serverless-to-cdk-migration-part-4/ https://sph.sh/en/posts/serverless-to-cdk-migration-part-4/ Thu, 04 Sep 2025 00:00:00 GMT Database and environment management carry the most risk in a CDK migration. Unlike stateless Lambda functions, these components hold your application's persistent state and configuration. A wrong step deletes a table, loses data, or wires staging to a production key without any error message.

The safe path is narrow. Verify that a table exists before importing it, generate environment values from a type-safe builder that fails the synth when a required key is missing, and scope every secret to a single stage. The sections below apply that default to DynamoDB imports, Parameter Store, Secrets Manager, and VPC-attached functions.

Continue reading...

]]> <![CDATA[Migrating from Serverless Framework to AWS CDK: Part 5 - Authentication, Authorization, and IAM]]> https://sph.sh/en/posts/serverless-to-cdk-migration-part-5/ https://sph.sh/en/posts/serverless-to-cdk-migration-part-5/ Thu, 04 Sep 2025 00:00:00 GMT Migrating authentication and authorization from Serverless Framework to AWS CDK presents unique challenges that can impact both security posture and application performance. Organizations often discover their Serverless Framework implementations have accumulated security debt through organic growth and rapid iteration cycles.

Common patterns include functions with overly broad IAM permissions, scattered authorization logic across multiple custom authorizers, and insufficient audit trails for access control decisions. These issues become apparent during migration assessments and can significantly impact compliance requirements.

Continue reading...

]]> <![CDATA[Migrating from Serverless Framework to AWS CDK: Part 6 - Migration Strategies and Best Practices]]> https://sph.sh/en/posts/serverless-to-cdk-migration-part-6/ https://sph.sh/en/posts/serverless-to-cdk-migration-part-6/ Thu, 04 Sep 2025 00:00:00 GMT A CDK migration's final phase is not about the correctness of the generated infrastructure. It is about operational readiness during cut-over: a plan for taking traffic, a plan for reverting if the migration degrades production, and a plan for reconciling drift that appears under live load. For a migration covering dozens of Lambda functions and multiple DynamoDB tables, the cut-over plan is larger than the migration code itself.

Continue reading...

]]> <![CDATA[DynamoDB Toolbox Guide: Single-Table Design in TypeScript]]> https://sph.sh/en/posts/streamline-dynamodb-toolbox-serverless-typescript/ https://sph.sh/en/posts/streamline-dynamodb-toolbox-serverless-typescript/ Thu, 04 Sep 2025 00:00:00 GMT Building serverless APIs with raw DynamoDB SDK calls creates significant maintenance overhead. Thousands of lines of AttributeValue mappings, dozens of scattered UpdateExpression strings, and zero type safety lead to brittle systems. When schema changes accidentally corrupt user records, it becomes clear that a better approach is essential.

DynamoDB Toolbox is the default worth reaching for. It wraps a table in typed entity definitions, so key construction, defaults, and marshalling stop being hand-written at every call site. Entity design, a service layer that owns the business rules, and a staged migration off raw SDK calls are where most of the work sits.

Continue reading...

]]> <![CDATA[Feature Flags in React Native: A Stale-While-Revalidate Pattern]]> https://sph.sh/en/posts/swr-style-feature-flags-react-native/ https://sph.sh/en/posts/swr-style-feature-flags-react-native/ Thu, 04 Sep 2025 00:00:00 GMT Feature flags sit on the critical path of a checkout flow, so how you load them is an availability decision. A synchronous API call to fetch a flag adds a network round trip to every render. Under cold-start conditions that round trip can stretch into seconds, the checkout times out, and the user abandons the cart. Stale-while-revalidate takes the lookup off the critical path: the cached value is returned instantly while a fresh value is fetched in the background. Treat the cache as the default answer and the network as a background refresh, never as a gate.

The Cost of Synchronous Flag Loading

A basic feature flag system makes a synchronous API call to AWS Parameter Store every time a flag value is needed:

[code block]

Continue reading...

]]> <![CDATA[Holacracy vs Team Topologies: Team Autonomy Models Compared]]> https://sph.sh/en/posts/team-autonomy-structures/ https://sph.sh/en/posts/team-autonomy-structures/ Thu, 04 Sep 2025 00:00:00 GMT Leadership announcements about "giving teams more autonomy" tend to land with mixed reactions. Autonomy without boundaries often creates more problems than it solves.

The common pattern is familiar. Moving from matrix project teams to product mode with stream-aligned teams produces velocity gains, along with unintended consequences: more defects, duplicated effort, teams stepping on each other's toes. Effective autonomy is not about removing constraints; it is about designing the right ones.

Team Topologies is the workable default here. Use its team types and interaction modes as the frame, then borrow role charters from Holacracy and community-of-practice vocabulary from the Spotify model. Context varies, but that combination lowers the trial-and-error cost of reorganizin...

Continue reading...

]]> <![CDATA[Complete Markdown Typography Guide]]> https://sph.sh/en/posts/typography/ https://sph.sh/en/posts/typography/ Thu, 04 Sep 2025 00:00:00 GMT Markdown processors agree on headings, lists, and code fences. Beyond that, support diverges: footnotes, definition lists, math blocks, collapsible sections, and admonitions each depend on the renderer. The sections below show every feature with its source syntax, so you can check what survives in your own renderer before relying on it.

Headings

Heading 1 Style (H1 = Post Title) Heading 2 (H2) Heading 3 (H3) Heading 4 (H4) Heading 5 (H5) Heading 6 (H6)

Text Formatting

Basic Formatting

Continue reading...

]]> <![CDATA[Zod + OpenAPI + AWS Lambda: Schema-First API Development with CDK]]> https://sph.sh/en/posts/zod-openapi-aws-lambda-cdk/ https://sph.sh/en/posts/zod-openapi-aws-lambda-cdk/ Thu, 04 Sep 2025 00:00:00 GMT When a Lambda API and its OpenAPI spec are maintained separately, schema drift is inevitable. A field added to Zod validation quietly goes missing from the contract clients generate code against, and downstream consumers break without warning. The fix is to keep one source of truth: wire Zod schemas directly into OpenAPI spec generation and CDK deployment, so the published contract cannot diverge from the validation that runs on every request.

Documentation Drift: Business Cost

The classic serverless API development problem is four different sources of truth diverging silently:

[code block]

Continue reading...

]]>