DEV Community: Dev Encyclopedia

Your RLS Policy Passed Its Test For the Wrong Reason

Dev Encyclopedia — Fri, 21 Aug 2026 12:47:06 +0000

A manual psql check answers exactly one question: does this policy work right now, against today's schema, with today's roles. It says nothing about tomorrow.

Three ordinary changes are enough to quietly break tenant isolation without anyone noticing at review time. A migration that drops and recreates a table loses RLS entirely, since it's a per-table flag, not something that travels with column definitions. A new service role for a background job can skip the policy if nobody remembers to apply it. And the most common one: someone grants BYPASSRLS during an incident and never revokes it.

Most guides point you at pgTAP here and stop. pgTAP is fine, but it's a separate SQL-based framework with its own runner. If your backend is already on Jest, you don't need a second test framework, you need a Jest test that actually proves a leak can't happen. The core pattern: seed a row as tenant A, query as tenant B, assert the result is empty. Run it through a dedicated low-privilege role, since table owners and superusers bypass RLS by default even with FORCE enabled for the owner.

I break down the full pattern, the queryAsTenant helper, testing WITH CHECK on INSERT/UPDATE, catching accidental BYPASSRLS grants, and wiring it into GitHub Actions here: https://devencyclopedia.com/blog/postgres-rls-testing-jest

If you're doing this across more than one or two tables, I also built RLSBuilder, a browser tool that generates the CREATE POLICY SQL and a matching Jest test from the same three inputs so they can't drift apart: https://devencyclopedia.com/tools/rls-builder

Stop Writing Your Mongoose Schema Twice: InferSchemaType, HydratedDocument, and the populate() Fix Nobody Explains

Dev Encyclopedia — Tue, 18 Aug 2026 04:51:28 +0000

If you've added TypeScript to a Mongoose project, you've probably written the same shape twice, once as an interface, once as the schema that actually enforces it at runtime. They don't check each other. Add a field to the schema and forget the interface, and TypeScript won't catch it, because as far as the type checker knows, the interface is correct. It's just wrong relative to what actually gets saved to MongoDB.

InferSchemaType fixes that duplication, it derives the plain data shape straight from the schema. But it only gets you the data shape. It doesn't know about .save(), it doesn't know about ._id, and it has no idea what Mongoose attaches to a document once it comes back from a query. That's where HydratedDocument comes in, and skipping it is the single most common reason people end up reaching for "as any" on a perfectly normal query result.

Then there's the part that trips up almost everyone eventually: .populate(). By default a referenced field types as a raw ObjectId, even after you've populated it. TypeScript has no way to see that a runtime call changed the shape of your result. There's an open GitHub issue on Mongoose's own repo about exactly this, with no canonical fix linked anywhere easy to find.

I break down the full fix, plus typing instance methods, statics, virtuals, and when you should still hand-write an interface, here: https://devencyclopedia.com/blog/mongoose-typescript-interfaces

If you just want the interface and populate snippet generated for your actual schema instead of reconstructing the generics from memory, I also built a free browser tool for that: https://devencyclopedia.com/tools/mongoosets

Mongoose 9 Migration Guide: What Actually Breaks in a Real MERN App

Dev Encyclopedia — Sun, 16 Aug 2026 11:35:16 +0000

If you run npm update on a Mongoose 8 project without a pinned version, you might land on Mongoose 9 without meaning to. And depending on your codebase, that upgrade can go wrong in ways your test suite won't catch.

The headline change is that Mongoose 9 drops callback support from pre() hooks entirely. Any hook shaped like schema.pre('save', function(next) { ... next(); }) still runs, but next() is now a silent no-op. No thrown error, no console warning, just code after the hook that stops firing the way it used to.

That alone is grep-and-fix work. The riskier part is what it does to plugins you didn't write. Auth and validation packages like mongoose-unique-validator and passport-local-mongoose attach their own internal pre-save hooks. If a plugin's version predates confirmed Mongoose 9 support, its hook can silently stop doing its job, meaning duplicate key errors that used to get converted into clean ValidationErrors start reaching your API responses raw.

On top of that, ObjectId construction got stricter, and Mongoose's generated TypeScript types now check query filters more aggressively against your schema shape, so a clean tsc run before the upgrade won't necessarily stay clean after.

I break down all of this with a practical six-step upgrade order, how to write tests that actually catch a silently skipped hook, and a safe rollback plan here: https://devencyclopedia.com/blog/mongoose-9-migration-guide

CSS @scope Is Baseline Now. Here's a Playground to Actually See How It Works

Dev Encyclopedia — Fri, 07 Aug 2026 03:38:16 +0000

@scope reached Baseline in December 2025, which means Chrome, Edge, Safari, and Firefox all ship it in stable. That's great news, except most explanations of @scope are still static code blocks, and a scoping rule is exactly the kind of feature that's hard to reason about without watching it run.

So I built ScopeLab, a live editor for @scope. You write HTML in one pane and CSS in the other, and the browser's own @scope engine renders the result inside a sandboxed iframe. No polyfill, no custom parser standing between your code and the outcome.

The interesting part is the highlight layer. It reads the scope root and optional limit straight out of your first @scope rule and draws outlines accordingly: solid green for the root, dashed green for in-scope descendants, dashed red for anything past a scope limit. Because that highlight is itself implemented as an @scope rule, it can never disagree with what the browser is actually doing.

There's also a Without @scope toggle that strips the wrappers so the same selectors apply globally, which is the fastest way to see the exact leak that @scope was built to stop.

If you've ever been unsure how scope limits create a "donut scope," or how proximity to the scope root affects specificity ties, this is built to make that click. I walk through the syntax reference and real scoping scenarios (component containment, protecting nested widgets, excluding third-party iframes) here: https://devencyclopedia.com/tools/scopelab

Why Two GraphQL Queries Against the Same Schema Can Differ in Cost by 1000x

Dev Encyclopedia — Thu, 06 Aug 2026 04:34:46 +0000

REST has a nice property: each endpoint has a roughly fixed cost. GraphQL throws that out. A single query can request arbitrarily deep and wide data, so two queries hitting the exact same schema can differ in resolution cost by orders of magnitude.

That flexibility cuts both ways. A tiny query string, whether crafted by an attacker or introduced by an accidental infinite nesting bug, can force a server to resolve millions of objects. This is why every major GraphQL server library ships some form of complexity analysis, and why knowing a query's cost before it hits production actually matters.

The core mechanic is simpler than it sounds: every field starts at a base cost of 1, list fields (anything with a first/last/limit argument, or that just looks like a collection) become multipliers, and a field's final cost is the product of every list ancestor above it. Nesting compounds fast. One deeply nested list field with a couple of first:N arguments stacked on top of each other can dominate the entire score.

I built QueryWeight to make this visible without doing the math by hand. Paste a query, get the AST-parsed depth, complexity score, unbounded list flags, and a ranked breakdown of what's actually driving the number, all computed client-side with zero network calls.

Full breakdown of the scoring model and how to read the results here: https://devencyclopedia.com/tools/queryweight

I Built a Tool That Explains MongoDB Aggregation Pipelines Without Touching a Database

Dev Encyclopedia — Wed, 05 Aug 2026 03:29:53 +0000

If you've ever opened a PR with a five-stage aggregation pipeline and had to reconstruct what it does in your head, you know the drill: trace the $match, figure out what the $group collapses, work out whether that $lookup is even necessary, all without a database connection to actually run it against.

That's the exact gap PipelineExplain fills. Paste your pipeline array (strict JSON or Mongo shell syntax with unquoted keys and constructors like ObjectId(...) and ISODate(...)) and it parses it locally in your browser, then explains each stage in plain English using your actual field names and group keys, not a generic placeholder.

It also groups consecutive stages into categories like filter, group, join, and reshape, so you get a one-line shape summary of the whole pipeline before diving into stage-by-stage detail. And it scans for the classic performance traps: a late $match, a $sort running before a $group, or a $lookup that might be more expensive than it looks.

The tool never connects to a real database and never executes anything, so the "before/after" examples are illustrative, not your actual documents. For that, you'd still reach for Compass or the shell. But for the moment you're reading someone else's pipeline in a PR or a Stack Overflow thread with no DB handy, this is built for exactly that.

Full breakdown of supported syntax and stage coverage here: https://devencyclopedia.com/tools/pipelineexplain

Your Crate's MSRV Is Probably Wrong (And You Won't Know Until Someone's Build Breaks)

Dev Encyclopedia — Mon, 03 Aug 2026 06:48:09 +0000

Here's a scenario that plays out constantly in Rust projects: your Cargo.toml declares rust-version = "1.70", your CI is green, your tests pass. Then a contributor on an older pinned toolchain opens an issue because their build fails on a syntax error you've never seen.

Somewhere between when you set that rust-version and now, a PR quietly introduced a feature that needs something newer. Maybe it was a let-else statement. Maybe someone swapped in OnceLock instead of the once_cell crate. Nothing failed locally because your own toolchain is newer than what you claim to support.

The tricky part is that Rust features fall into different categories with very different implications. Syntax changes like let-else won't parse at all on an older compiler, full stop. Standard library additions like Option::is_some_and often have a crate-based equivalent you can swap in. Trait system changes like generic associated types or native async fn in traits are usually the hardest to walk back since they change what the compiler can express.

I built a small browser tool that pattern-matches pasted Rust source or a Cargo.toml against a feature lookup table spanning Rust 1.60 through 1.82, and reports the newest feature it finds, since that's your actual floor. It also cross-checks a declared rust-version against what it detects and flags the mismatch.

It's a heuristic, not a compiler, so it won't replace cargo-msrv for a final release check. But for eyeballing a PR or a new dependency before you commit real time to it, it's instant. I walk through how it handles trait blocks and the async-trait macro distinction here:
https://devencyclopedia.com/tools/msrvcheck

Kubernetes Swap Support in 1.35: The Config That Silently Does Nothing

Dev Encyclopedia — Sun, 02 Aug 2026 05:17:02 +0000

Node swap support (KEP-2400) went GA in 1.34 and stable in 1.35. If you've been putting off a decision on this, this is the release where it's actually safe to test.

But "stable" doesn't mean "on for you." Swap is opt-in at two levels: swap has to be provisioned on the node's disk, and the kubelet has to be explicitly configured to allow it. Nothing changes just because you upgraded.

Here's the trap. Setting failSwapOn: false gets you NoSwap by default, which just stops the kubelet from refusing to start on a swap-enabled node. Your pods still don't get swap access. People provision swap, flip failSwapOn, restart the kubelet, and wonder why nothing changed. The setting you actually need is memorySwap.swapBehavior: LimitedSwap.

There's also a QoS restriction that trips people up: only Burstable pods (where at least one container's memory request is below its limit) get swap access at all. Guaranteed pods are excluded by design, and BestEffort pods never get it either.

In the full writeup I cover the cgroup v2 and container runtime prerequisites, the exact kubelet config, how to verify it actually worked (not just that the kubelet accepted it), and a breakdown of workload types where this helps versus where it makes p99 latency worse: https://devencyclopedia.com/blog/kubernetes-swap-support-1-35

Earning the July 2026 GitHub Actions Top Reader Badge! 🏆

Dev Encyclopedia — Sat, 01 Aug 2026 11:15:47 +0000

Hey DEV community! 👋

I’m thrilled to share that I just received the July 2026 Top Reader Badge for GitHub Actions from DevEncyclopedia!

As a software engineer, I'm always looking to streamline my CI/CD workflows, improve how I handle automation, and optimize my project deployments. Spending time this month diving deep into GitHub Actions tutorials and resources has been incredibly rewarding. Continuous learning is such a core part of what we do in tech, and it's an awesome feeling to have that dedication recognized.

A huge thank you to the authors and creators who put together these fantastic resources. If you haven't checked them out yet, I highly encourage you to explore and keep leveling up your skills.

What new tech or tools are you all learning this month? Let me know below! 👇

Building Native Desktop Apps with Deno 2.9 and Pure TypeScript

Dev Encyclopedia — Fri, 31 Jul 2026 04:14:21 +0000

Shipping a web application as a desktop binary has traditionally required significant compromises. Electron developers deal with massive binary sizes due to bundled Chromium instances, while Tauri developers face a steep learning curve by being forced to write backend logic in Rust. For teams completely standardized on TypeScript, neither approach feels entirely seamless.

Deno 2.9 addresses this gap by introducing deno desktop, a canary feature that lets you package a Deno web project into a native desktop application using only TypeScript. Instead of manually wiring up ports or managing inter-process communication boundaries, you can point the command directly at your server. Better yet, the framework supports a window.bind API that bridges page JavaScript straight to backend functions with zero HTTP overhead.

Whether you are targeting macOS, Windows, or Linux, the workflow stays firmly within the runtime you already know. I break down the full tutorial, configuration, and native API bindings here: https://devencyclopedia.com/blog/deno-desktop-tutorial

Stop Guessing What Your Cron Expression Actually Does

Dev Encyclopedia — Thu, 30 Jul 2026 03:54:04 +0000

If you've ever stared at "0 9 * * 1-5" and had to mentally reconstruct which field is which, you're not alone. Cron syntax is compact by design, which makes it great for config files and terrible for readability.

The real problems show up once you leave plain Linux crontab. GitHub Actions runs everything in UTC regardless of your repo's timezone, and it silently ignores any schedule more frequent than every 5 minutes, no error, it just won't fire as often as you asked. AWS EventBridge adds a 6-field format with seconds and year, plus its own rate() syntax. Kubernetes CronJobs look identical to standard 5-field cron but run in the pod's timezone, which defaults to UTC unless you set it explicitly.

Then there's the logic trap: when both the day-of-month and day-of-week fields are restricted at the same time, cron doesn't AND them together, it ORs them. So an expression meant to mean "first Monday of the month" actually fires on the 1st of the month OR every Monday, whichever comes first.

I put together a free Cron Expression Builder that translates any expression into plain English, shows your next 5 scheduled run times in your local timezone, and breaks down the platform-specific quirks above. I break down all of it here: https://devencyclopedia.com/tools/cron-builder

How to Switch to uv: Replace pip, virtualenv, and Poetry in Your Python Project

Dev Encyclopedia — Wed, 29 Jul 2026 07:18:42 +0000

If you've worked on a Python project for more than a year, you know the drill: pip to install packages, virtualenv or venv to isolate environments, pyenv to manage Python versions, and pip-tools to generate a lockfile. Four separate tools, four config formats, and four different points of failure in CI.

uv, built by Astral (the team behind ruff), collapses all of that into a single Rust binary. It's not a modest speed bump either, we're talking 10 to 100x faster than pip on cold installs and near-instant on warm ones. In CI, where the cache is cold on every run, that difference is often the gap between a multi-minute install and one that finishes in seconds.

This isn't a "starting fresh" tutorial. It's specifically about migrating a project that already has a requirements.txt or a Poetry-based pyproject.toml, since that's the situation most of us are actually in.

The guide covers the real friction points: importing an existing requirements.txt cleanly (there's a one-liner for simple files and a safer fallback for ones with pins, comments, or extras), migrating off Poetry with a dedicated conversion tool, what doesn't auto-migrate (dependency groups, private indexes, poetry run calls), pinning your Python version so the whole team and CI stay in sync, and wiring up GitHub Actions with the one flag that keeps your lockfile honest.

I break down every step, plus the actual benchmark numbers, here: https://devencyclopedia.com/blog/switch-to-uv-python