DEV Community: Dev Encyclopedia

You Don't Need Express to Build a Microservice (Here's the Zero-Dependency Version)

Dev Encyclopedia — Sat, 12 Sep 2026 11:30:54 +0000

Open ten "Node.js microservices" tutorials and nine start the exact same way: install Express, install an HTTP client, write a docker-compose.yml, stand up a message broker. By the time application code shows up, you've installed six things and still don't know if microservices were even the right call.

Node ships with everything two communicating services actually need. node:http is the server. Global fetch is the client. node:test is the runner. --watch is the reloader. No install step, no node_modules.

So I built two real services this way: a user service holding user records, and an order service that has to confirm a user exists before creating an order for them, calling across the boundary with a plain fetch. Along the way you run into the actual failure modes of distributed systems, not the theoretical ones. fetch rejects on a refused connection instead of returning a response object, which means an unhandled rejection inside your request handler can take your service down right along with the one it was calling. That single try/catch is the whole lesson.

The bigger trap isn't technical though. It's splitting a codebase into two folders while both still connect to the same schema. That gets you all the operational cost of distributed systems and none of the actual benefit, independent deployability included.

I walk through building both services, testing them with node:test, and watching the failure happen live (kill one service, watch the other survive, then watch it not survive once you remove the catch) here: https://devencyclopedia.com/blog/nodejs-microservices-without-express

If you've been reaching for Express and Docker by default before writing a line of logic, this is worth forty lines of your time first.

40 React Interview Questions for 2026 (Actions, Server Components, and the Compiler Era)

Dev Encyclopedia — Sun, 06 Sep 2026 11:38:12 +0000

If you last prepped for a React interview before 2025, there's a good chance your mental model is missing an entire layer of what gets asked now.

React 19 shipped Actions, useActionState, and ref as a regular prop. React 19.2 followed with useEffectEvent, the Activity component, and cacheSignal. And the React Compiler went stable in October 2025, which changes the default answer to "should I useMemo this?" from yes to "probably not, let the compiler handle it."

The fundamentals haven't gone anywhere. Props vs state, the key prop, reconciliation, the Rules of Hooks, these still get asked in nearly every interview regardless of seniority. But the questions that actually separate candidates who kept up from candidates repeating 2022 answers live in the React 19 specific territory: what problem does useEffectEvent actually solve, why is Activity different from conditionally unmounting a component, and can you explain Server Components vs traditional SSR in one clean sentence without getting flustered.

There's also a career-level layer that a lot of prep guides skip entirely: how do you test a component built around an Action, what ESLint setup does the Compiler actually need, and how would you explain the Client vs Server Component tradeoff to a teammate who hasn't caught up yet.

I put together 40 questions across five sections, fundamentals, hooks, React 19/19.2 specifics, performance and architecture, and testing/tooling, with a quick reference table so you can see all 40 at a glance before deciding where to spend your prep time. Full breakdown here: https://devencyclopedia.com/blog/react-interview-questions

Node.js Quietly Removed --experimental-transform-types, Here's What Breaks

Dev Encyclopedia — Mon, 24 Aug 2026 07:06:20 +0000

Buried in the Node.js 26 release notes, between a Temporal API announcement and a GCC bump, is a single bullet that broke more projects than anything else in that changelog: --experimental-transform-types is gone.

Node's native TypeScript support always ran in one of two modes. Strip mode deletes type annotations and replaces them with whitespace, it's been the default since Node 22.18.0 and 24.3.0. Transform mode did more, it compiled enums into runtime objects, namespaces into IIFEs, and parameter properties into constructor assignments. That second mode is the one that just got pulled, with no replacement.

The result is a parse error. Run a file with a plain enum on an affected Node version and you get ERR_UNSUPPORTED_TYPESCRIPT_SYNTAX before your program executes a single line. No try/catch will save you, and your editor won't warn you either, because tsc considers this syntax completely valid.

Here's the detail that catches teams off guard: this isn't purely a Node 26 story. The same removal landed in Node 24.12.0, a patch release on the 24 LTS line, and in 25.2.0. A range pin like 24.x or ^24.0.0 in your Dockerfile or CI matrix can pull this in without any major version bump.

I break down all four breaking patterns (enums, namespaces, parameter properties, import-equals) and their mechanical rewrites here: https://devencyclopedia.com/blog/node-experimental-transform-types-removed

If you want to know how much of your own codebase is affected before touching tsconfig, I also built TypeStripCheck, a free browser tool that scans a pasted file and returns every finding with a line number and rewrite, entirely client-side: https://devencyclopedia.com/tools/typestripcheck

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! 👇