标签：#node

Your schema is portable. But each runtime loads environment variables differently. CtroEnv adapters bridge the gap — same validation logic, different data sources. Node.js: process.env + .env Files The @ctroenv/node adapter loads .env files and wraps process.env : import { defineEnv , string , number } from " @ctroenv/core " import { loadEnv } from " @ctroenv/node " const env = defineEnv ( schema , { source : loadEnv () }) loadEnv() resolves files in order: .env — shared defaults .env.{NODE_ENV} — environment-specific ( .env.development , .env.production ) .env.local — local overrides (gitignored) Later files override earlier ones. process.env takes precedence unless override: true . Monorepo Root loadEnv ({ path : " ../.. " }) // look up two directories for root .env Native Node 22+ Node 22 has built-in process.loadEnvFile() . Use native: true to delegate: loadEnv ({ native : true }) // uses process.loadEnvFile() if available Falls back to the custom parser on older Node versions. System Fallback By default, only file values are returned. With system: true , missing keys fall through to process.env : loadEnv ({ system : true }) Standalone Parser Use parseEnvFile() directly for custom file loading: import { parseEnvFile } from " @ctroenv/node " const content = readFileSync ( " .env.custom " , " utf-8 " ) const vars = parseEnvFile ( content ) Handles quotes, multiline values (backslash continuation), interpolation ( ${VAR} ), comments, and export prefix. Vite: Build-Time Validation The @ctroenv/vite plugin validates during the build: // vite.config.ts import { ctroenvPlugin } from " @ctroenv/vite " export default defineConfig ({ plugins : [ ctroenvPlugin ({ schema : " ./src/env.ts " }), ], }) If DATABASE_URL is missing, the build fails — no broken artifacts shipped. Schema Options Pass a file path or inline definition: // File path — imports the module, looks for `schema` export ctroenvPlugin ({ schema : " ./src/env.ts " }) // Inline definition ctroenvPlugin ({ schem

Most TypeScript projects treat environment variables like second-class citizens. They're string | undefined everywhere, asserted with ! and parsed with parseInt() . TypeScript can't help because process.env is typed as Record<string, string | undefined> . Schema-based validation fixes this. But most solutions bring zod, which adds 50 KB to your bundle. CtroEnv does it with zero dependencies and 6.5 KB gzipped. How Inference Works The type system reads each validator's configuration at compile time: type InferredValue < V > = V extends Validator < infer T > ? V [ " metadata " ] extends { hasDefault : true } ? T // .default() → non-nullable : V [ " metadata " ] extends { optional : true } ? T | undefined // .optional() → nullable : T // required → guaranteed present : never This means the schema defines the type: const env = defineEnv ({ PORT : number (). port (). default ( 3000 ), // ^? number — default makes it always present DB_URL : string (). url (), // ^? string — required DEBUG : boolean (). optional (), // ^? boolean | undefined — optional NODE_ENV : pick ([ " dev " , " prod " , " staging " ] as const ), // ^? "dev" | "prod" | "staging" — exact union }) No interface Env { ... } . No z.infer<typeof Schema> . Add a new validator, and the type updates automatically. Default vs Optional vs Required The three states and their types: Declaration Type Runtime behavior string() string Required — throws if missing string().optional() `string \ undefined` string().default("x") string Falls back to "x" string().optional().default("x") string Default overrides optional TypeScript reflects this exactly. Optional gives you | undefined . Default removes it. The as const Requirement pick() needs as const to preserve literal types: pick ([ " dev " , " prod " ]) // type: string — widened pick ([ " dev " , " prod " ] as const ) // type: "dev" | "prod" — exact union Without as const , TypeScript widens the array to string[] and you lose the union. Exhaustive Checking With exact l

Last year I was doing a code review for a startup. Everything looked fine on the surface, clean code, good structure, tests passing. Then I noticed this: const query = `SELECT * FROM users WHERE email = ' ${ req . body . email } '` That's it. That's the bug. SQL injection, sitting right there in a startup that had been in production for 8 months. Nobody caught it. Not the developer, not the reviewer, not the CTO. Here's the thing, it's not that developers are careless. It's that this kind of bug is invisible until it isn't. The code works perfectly. Tests pass. Users are happy. Until someone types ' OR '1'='1 in the email field and walks straight into your database. The bugs I see most often 1. Raw SQL with user input // 🚨 This is everywhere const query = `SELECT * FROM users WHERE email = ' ${ email } '` // ✅ Use parameterized queries const query = ' SELECT * FROM users WHERE email = $1 ' db . query ( query , [ email ]) 2. Secrets in environment variables... committed to git # .env DATABASE_URL = postgres://user:actualpassword@prod-db.company.com/mydb STRIPE_SECRET = sk_live_... Then .env ends up in the repo because someone forgot to add it to .gitignore . I've seen this more times than I want to admit. GitHub's secret scanning catches some of these, but not always before someone has already cloned the repo. 3. JWT tokens that are never actually verified // 🚨 Decoding is not the same as verifying const user = jwt . decode ( token ) // ✅ Always verify const user = jwt . verify ( token , process . env . JWT_SECRET ) jwt.decode just reads the token. Anyone can forge it. jwt.verify actually checks the signature. The names are confusingly similar and the wrong one silently works in development. 4. No rate limiting on auth endpoints // 🚨 Anyone can try a million passwords app . post ( ' /login ' , async ( req , res ) => { const user = await db . findUser ( req . body . email ) // ... }) // ✅ Add rate limiting const authLimiter = rateLimit ({ windowMs : 15 * 60 * 1000 , m

If you've wired Swiss Ephemeris into a Node astrology app, you know the ritual. You npm install sweph , and now every machine needs Python plus a C/C++ toolchain, because the package compiles Swiss's C code via node-gyp at install time (make/gcc on Linux, Xcode on macOS, Visual C++ Build Tools on Windows). It works on your laptop. Then it explodes: Apple Silicon: node-gyp can't find full Xcode behind Command Line Tools. Slim Docker / CI images: no Python, no build-essential , so the install dies. Serverless: the .node binary you built locally won't load on Amazon Linux (wrong arch or glibc). Then there's the data. Neither sweph nor swisseph bundles the .se1 ephemeris files; you download them yourself and point the library at a path. The modern set is 2 MB, the full GitHub set is 100 MB. And since 2.10.1 , sweph is AGPL-3.0 (LGPL only under a professional license), a real obligation to weigh for a closed-source SaaS backend. The pure-Rust alternative XALEN Ephemeris is an analytical engine written entirely in Rust and licensed Apache-2.0. Three things make it interesting for JS/TS devs: No node-gyp. The Node addon is napi-rs, which ships prebuilt per-platform binaries via npm. No Python, no C compiler, no compile step. A real WASM build via wasm-bindgen, so you compute charts client-side in the browser: no server round-trip, no backend copyleft. Zero data files. The core math (VSOP87A, ELP2000-82, IAU precession/nutation, an 8,870-star catalog) is analytical and compiled into the binary. No .se1 to host. import init , * as xalen from " xalen-ephemeris " ; // WASM build, runs in the browser await init (); // load the .wasm module const chart = xalen . computeChart ({ datetime : " 1990-04-12T08:30:00Z " , lat : 28.6 , lon : 77.2 }); console . log ( chart ); // planet longitudes, house cusps, etc. Swiss via Node XALEN (pure Rust) Build deps node-gyp + Python + C compiler none: prebuilt binary / .wasm Runtime data .se1 files (2 to 100 MB) none, compiled in Browser / WASM

Remember how I promised you (or rather myself) two weeks ago that from now on I'd only write light,...

Last year I was asked to investigate a startup's AWS bill. It had jumped from roughly $200/month to over $3,000 in a few weeks. Nobody knew why. After digging through logs, metrics, and database traffic, I found the culprit: a polling loop with no backoff strategy. The code looked harmless: async function processQueue () { const jobs = await getJobs () for ( const job of jobs ) { await processFile ( job ) } processQueue () } processQueue () At first glance, this seems reasonable. Process all available jobs, then check again. The problem appears when the queue is empty. When getJobs() returned no work, the loop immediately queried the database again. And again. And again. There was no delay, no backoff, and no event-driven trigger. As a result, the service continuously hammered the database looking for work that didn't exist. Each iteration generated: A database query Network traffic CPU usage Logging overhead Additional infrastructure load Individually, each operation was cheap. Executed hundreds of thousands of times per day, they became expensive. The fix was simple: async function processQueue () { while ( true ) { const jobs = await getJobs () for ( const job of jobs ) { await processFile ( job ) } await new Promise ( resolve => setTimeout ( resolve , 5000 )) } } Even better would have been replacing polling entirely with an event-driven design using a message queue. What this incident taught me: 1. Empty queues are production workloads. Many engineers optimize for peak traffic and forget about idle traffic. Systems often spend more time idle than busy. 2. Polling needs backoff. If you're polling, always define what happens when no work is found. 3. Cost bugs rarely look like bugs. Nothing crashed. No exceptions were thrown. The system was technically working exactly as written. It was just doing useless work 24/7. 4. Always monitor cost alongside performance. CPU, latency, and error rates looked normal. The AWS bill was the first real alert. One question I ask

Hello Dev Community! 👋 It is officially Day 71 of my unbroken 100-day full-stack engineering run! After mastering polymorphic multi-part storage configurations yesterday, today I successfully crossed into core transactional operations: Engineering a High-Fidelity "Confirm and Pay" Checkout View and Wiring Database Inbound Array Modifications! In real-world booking platforms, processing a successful transaction requires more than updating an absolute view; you have to link documents relationally across collections. Today, I wired that entire execution pipeline together! 🧠 What I Handled on Day 71 (Checkout Engineering & Target Mutations) As displayed across my latest system files in "Screenshot (164).png" and "Screenshot (165).jpg" , handling payments runs through structured backend steps: 1. High-Fidelity Checkout Component ( /reserve ) I built out the detailed split-pane verification interface visible in "Screenshot (164).png" . The layout captures target trip date selections, total guests parameter caps, card input structures, and computes subtotal ledgers dynamically: Base Compute: $9000 x 5 nights = $45000 . Transactional Upgrades: Appending structured service charges ( $85 ) and local tax calculations ( $42 ) to update the final sum directly to $45127 . 2. Live Document Array Mutators (MongoDB User List Insertion) The most crucial logic happens when the user clicks the primary validation trigger labeled Confirm and pay : The inbound route controller extracts the targeted property identity token ( home._id ) via an embedded hidden input container. Instead of running isolation updates, it issues an atomized update operation straight into our MongoDB user records array (e.g., using Mongoose operators like $push or tracking active profiles inside our custom data state loops). This appends the exact property listing target ID directly into the user's booking history array database matrix! 🛠️ View Markup Code Integration View As showcased in my VS Code script structu

10 Things Nobody Tells You About process.env I've burned myself on most of these so you don't have to. Here's what I wish someone had told me early on. 1. Keys are case-sensitive on Linux, case-insensitive on Windows process . env . PORT = " 3000 " console . log ( process . env . port ) // undefined on Linux, "3000" on Windows This one got me during a "works on my machine" incident. My Windows dev box ran fine. The Linux CI server crashed because a teammate typed env.port instead of env.PORT . Your CI runs Linux. Your dev box probably runs macOS or Windows. Case-sensitivity differences will bite you. How to handle it : Use a validation layer that throws on missing keys. A simple getEnv("PORT") will catch typos at startup. 2. Values are always strings console . log ( typeof process . env . PORT ) // "string" even if you set PORT=3000 Number(process.env.PORT) can return NaN without throwing. Boolean values like "false" are truthy strings. How to handle it : Always parse. If you use a schema library like CtroEnv, it coerces types and throws on invalid input. 3. process.env is NOT the same as .env This confused me for way too long. process.env is whatever the shell gave the process. A .env file is just a text file dotenv reads to populate process.env . Node doesn't touch .env files on its own. // This won't read .env automatically console . log ( process . env . MY_VAR ) // undefined How to handle it : Call dotenv.config() at entry, or use @ctroenv/node which loads .env files automatically. 4. You can set env vars per-command PORT = 4000 node app.js This sets PORT only for that single process. It doesn't pollute your shell session. Super useful for one-off runs or testing different configurations without editing files. console . log ( process . env . PORT ) // "4000" 5. process.env is mutable at runtime process . env . DATABASE_URL = " postgres://hacker:gotme@evil.com/db " I've seen code that modifies process.env to "fix" config at runtime. Don't do this. If something i

This article covers what I learned or maybe didn't really learn. The Problem With Traditional HTTP Most web applications use HTTP. The flow looks like this: Client → Request → Server Client ← Response ← Server Once the server sends the response, the connection is closed. This works perfectly for: Authentication CRUD operations Fetching data Form submissions But what happens when the server needs to send information without being asked? For example: A new task is assigned Someone comments on a task A project status changes A teammate updates a board With traditional HTTP, the browser would need to keep asking: "Anything new?" "Anything new?" "Anything new?" This technique is called polling, and it's inefficient. That's where Socket.io comes in. What Socket.io Actually Does Socket.io creates a persistent connection between the client and server. Instead of repeatedly opening and closing connections, the connection stays alive. Now communication becomes two-way: Client ↔ Server The client can send data whenever it wants. The server can also send data whenever it wants. This is what makes real-time applications possible. Why Express Alone Isn't Enough One thing that confused me initially was why Socket.io couldn't simply be attached directly to my Express app. The answer lies in how Express works. When you write: app . listen ( 5000 ); Express creates the HTTP server internally. You don't have direct access to it. Socket.io, however, needs access to the raw HTTP server. So instead of: app . listen ( PORT ); The flow becomes: const httpServer = createServer ( app ); Then Socket.io attaches to that server: const io = new Server ( httpServer ); Finally: httpServer . listen ( PORT ); This architecture allows Socket.io and Express to share the same server. Understanding Events Socket.io is event-driven. Everything revolves around two methods: socket . emit () and socket . on () Think of them as: emit = send on = listen For example: Client: socket . emit ( " join-project " ,

Chaos engineering sounds expensive. Netflix built Chaos Monkey to randomly kill production servers. Google runs DiRT (Disaster Recovery Testing) across their entire infrastructure. Amazon does game days where they intentionally take down services. You're building a Node.js API. You don't have a platform team. You don't have a chaos infrastructure. But you still need to know: what happens when your dependencies get slow? The good news is that 80% of the value of chaos engineering comes from one question, and you can answer it locally in five minutes. The one question that matters What does my application do when a dependency responds slowly or not at all? Not "what if the server catches fire" — that's infrastructure chaos. What about application chaos: the database is slow, the payment API is timing out, Redis is having a bad day. These happen constantly in production and they're almost never tested. The failure modes look like this: Your DB gets slow under load → your API response times climb → your timeout fires → you retry → now you're sending twice the load to an already-slow DB Your Redis cache goes down → every request hits Postgres directly → Postgres gets slow → same cascade Stripe's API takes 3 seconds instead of 200ms → your checkout route times out → users get errors → you're losing revenue Every one of these is a latency failure , not a crash. The service is still up. It's just slow. And slow is the hardest failure mode to test because your local environment is fast. Why local testing misses this When you test locally, your "database" is either: A real local Postgres running on the same machine (sub-millisecond latency, not production-like) A mock that returns instantly ( jest.fn().mockResolvedValue(data) ) A fake with a flat delay ( await sleep(200) ) None of these produce realistic latency. A real production database has: Fast responses most of the time (p50 ~5ms) Occasional slowdowns (p95 ~50ms) Rare but real spikes (p99 ~200ms, p99.9 ~2000ms) The spik

Hello Dev Community! 👋 It is officially Day 50 — a massive half-century milestone on my daily, unbroken streak toward mastering full-stack MERN engineering! Reaching Day 50 feels absolutely incredible. Yesterday, I mapped out dynamic path parameters. Today, I wired the input engine by building a complete asset workflow: Capturing Host "Add New Product" data payloads and committing them to local file storage pipelines! Following Prashant Sir's backend sequence , today was all about bridging the gap between host client forms and backend architecture using the Model-View-Controller framework. 🧠 Key Learnings From Day 50 (Product Ingestion & Storage) Processing data mutations sent from input forms requires tight coordination between parsing middlewares and file serialization engines. Here is how I structured the logic today: 1. Intercepting Form Submissions ( POST /host/add-product ) Set up a clean route mapping inside hostRouter.js to process dynamic data blocks sent by the host. The endpoint parses input parameters securely via backend streams. 2. Utilizing Class Instances for Storage Instead of directly pushing raw unstructured dictionaries into file records, I initialized a new object instance using my Day 48 structural class framework ( new houseList(...) ). This forces incoming data attributes—like name, price, location, and images—to match my exact system layout blueprint. 3. Asynchronous File Serialization Invoked the instance method .save() , which runs a non-blocking background task: it reads the active database layout array inside homesdata.json , appends the newly formulated object safely, and flushes the stringified update back onto the hard drive array using Node's fs operations. javascript // A conceptual look at how my controller hands data over to the model layer today const Product = require("../model/home"); exports.postAddProduct = (req, res) => { const { title, price, location, rating, imageUrl } = req.body; // Instantiating the core class data mold

Hello Dev Community! 👋 It is officially Day 48 of my unbroken full-stack engineering journey! Yesterday, I refactored my modular core patterns into MVC architecture. Today, I linked up a major functional extension inside the /model layer by introducing JavaScript Classes (OOP) to coordinate my local file operations and storage data patterns! Instead of writing loose object definitions, I stepped up my enterprise game by structuring a reusable class footprint that encapsulates data parameters and handles non-blocking file-system persistence asynchronously. 🧠 Key Learnings From Day 48 (OOP Modeling & File Systems) As clearly shown in my development workspace layout within "Screenshot (116).png" , modeling data with dedicated classes shifts your core structural logic from simple scripts into highly scalable engines: 1. The Model Data Blueprinter ( constructor ) I used the standard ES6 class framework inside home.js to structure an explicit data mold ( houseList ) with attributes tracking: houseName , price , location , rating , and photoUrl . This ensures every entry traveling through our server follows an identical structure. 2. Streamlining Async Persistence ( save() ) Rather than relying on globally declared floating arrays, my .save() blueprint method triggers an internal lookup to read existing data stacks asynchronously before safely using fs.writeFile() to serialize and flash mutated JSON rows into a local data asset ( homesdata.json ). 3. Static Decoupled Fetchers ( static fetchAll() ) I mastered using static methods. Since reading a data grid requires pulling records without creating an instance of a single house first, making fetchAll(callback) static allows our controllers to tap the hard disk records straight from the class reference layout: javascript // A conceptual look at my file-reading design today static fetchAll(callback) { const filePath = path.join(rootDir, 'data', 'homesdata.json'); fs.readFile(filePath, (err, data) => { if (err) { callback(JSON.

Authentication is broken at its foundation - not just inconvenient. Passwords are shared secrets: hand one to a server, and you have instantly doubled your attack surface. With over 5 billion passkeys now active globally and Google reporting a 99.9% lower account compromise rate compared to passwords, the industry has already moved. This guide covers how passkeys work cryptographically, how to implement them in TypeScript, and the pitfalls to avoid before going to production. Why Passwords Are Structurally Broken The core issue isn't that users pick weak passwords - it's that passwords require a shared secret stored on both sides. The Verizon 2025 DBIR found that 22% of all breaches started with stolen credentials, and 88% of web app attacks relied on them. In 2024, infostealer malware alone harvested 548 million passwords. Adding 2FA helps but doesn't fix the root problem: SMS codes are SIM-swap targets, and TOTP tokens can be phished in real time by proxy attackers who replay codes within their validity window. What Passkeys Actually Are A passkey is a credential built on public-key cryptography, standardized through the WebAuthn spec and FIDO2. When you register, your device generates a public-private key pair - the private key stays locked in hardware (Secure Enclave, StrongBox, or a hardware key), and the server only receives the public key. At login, the server sends a random challenge, your device signs it with the private key after biometric or PIN verification, and the server verifies the signature. No secret is ever transmitted. This eliminates credential stuffing, server-side breach exposure, and phishing - because passkeys are cryptographically bound to a specific origin domain. The Cryptography Worth Understanding The standard algorithm is ES256 - ECDSA with the P-256 curve and SHA-256. Each credential is tied to a specific relying party ID (your app's domain). A passkey created for yourapp.com cannot be used on yourapp-phishing.com because the origin i

As developers, we’ve all been there: you’re building a hobby project, a side hustle, or a microservice, and you need object storage. You look at AWS S3 or dedicated cloud providers, and the costs start adding up. Meanwhile, most of us have hundreds of gigabytes of idle, wasted space sitting in our personal Google Drive, Dropbox, or Mega accounts. I wanted to find a way to use that personal cloud storage programmatically—specifically as an S3-compatible bucket—without paying premium storage fees. But I had one strict rule for myself: The solution had to be 100% stateless. No caching files on my servers, no data retention, and zero storage costs on my end. Security and privacy meant that files had to exist on my infrastructure only in-flight as streaming data packets. Here is a deep technical breakdown of the architecture I built to make this happen using NestJS, Fastify, OpenDAL, and BullMQ in a monorepo structure. 1. The Core Architecture: A Monorepo Approach To keep performance blazing fast and maintain a clean separation of concerns, I broke the system down into three distinct, decoupled services inside a monorepo, sharing underlying core modules. Because raw Node.js HTTP overhead can become a bottleneck when proxying heavy streams, I swapped out Express for Fastify as the underlying HTTP provider for NestJS. ┌────────────────────────────────────────┐ │ Main API Server │ │ (Handles Auth, Web Dashboard, OAuth) │ └───────────────────┬────────────────────┘ │ │ (Pushes Sync/Heavy Tasks) ▼ ┌───────────┐ │ BullMQ │ └─────┬─────┘ │ ▼ ┌────────────────────────────────────────┐ │ Worker Server │ │ (Processes Heavy Background Jobs) │ └────────────────────────────────────────┘ ───────────────────────────────────────────────────────────────────────── ┌────────────────────────────────────────┐ │ S3-Compatibility Server │ │ (Streams Data / Translates S3 XML) │ └────────────────────────────────────────┘ The Main API Server: Handles user authentication, the web dashboard manageme

Hi everyone 👋 I'm a Full Stack Developer with experience in JavaScript, React.js, Next.js, Node.js, Express.js, MongoDB, and WordPress development. Over the last few years, I have worked on multiple projects ranging from company websites to full-stack web applications. In this article, I want to share my experience transitioning from the traditional MERN stack to Next.js and why it has become my preferred framework for modern web development. Why I Started with MERN Stack The MERN stack was my first choice because it allowed me to build complete applications using JavaScript. Technologies MongoDB Express.js React.js Node.js Benefits ✅ Single language across frontend and backend ✅ Huge ecosystem ✅ Fast development ✅ Easy API integration Challenges I Faced As projects became larger, I started facing issues like: SEO limitations Performance optimization Routing complexity Code organization Server-side rendering requirements This is where Next.js entered the picture. Why I Switched to Next.js Next.js provides several powerful features out of the box. Server-Side Rendering (SSR) Pages can be rendered on the server which improves SEO and initial page load performance. 2.** Static Site Generation (SSG)** Perfect for blogs, landing pages, and marketing websites. 3.** App Router** The new App Router makes routing cleaner and more scalable. Server Components Less JavaScript is sent to the browser, improving performance. Better Developer Experience Features like: File-based routing Built-in image optimization Middleware API routes make development faster and cleaner. My Current Tech Stack Frontend Next.js React.js TypeScript Tailwind CSS Backend Node.js Express.js MongoDB Tools Git & GitHub Postman Vercel Contentful CMS What I Learned The biggest lesson I learned is: Focus on solving real business problems instead of chasing every new technology. Frameworks will change, but understanding JavaScript fundamentals, APIs, databases, authentication, and system design will always be

You know that feeling when you start a new project and spend the first 20 minutes doing nothing productive? Hunting for the Android keystore. Finding the right .env file. Copying VS Code settings. Again. And again. Every. Single. Project. I got tired of it. So I tried building something to fix it — coffee-installer. How it works Create a collection folder and point coffee-installer to it: mkdir ~/.coffee-collection echo '{ "baseSource": "~/.coffee-collection" }' > ~/.coffee.config.json Add your reusable files to the collection: mkdir -p ~/.coffee-collection/my-app/android/app cp android/app/keystore.jks ~/.coffee-collection/my-app/android/app/ cp android/key.properties ~/.coffee-collection/my-app/android/ Preview before installing: $ coffee diff my-app Diff — my-app ( config ) + add android/key.properties + add android/app/keystore.jks + add frontend/.env.development.local 3 to add, 0 to overwrite, 0 to skip Then install with one command: $ coffee install my-app 📦 Installing my-app... ✅ copied android/key.properties ✅ copied android/app/keystore.jks ✅ copied frontend/.env.development.local ✅ my-app installed. All commands coffee list # see everything in your collection coffee diff my-app # preview before installing coffee install my-app # install into current project coffee pull my-app # sync changes back to collection Why I built this I work across multiple projects — mobile apps, web backends, Flutter apps. Every project needs the same credentials, the same IDE config, the same environment files. The alternative was a folder of files I'd manually copy every time, or worse — storing credentials in a repo (never do this). coffee-installer keeps everything in one local folder that never touches version control. It's not perfect yet, but it already saves me a lot of setup time. Zero dependencies The entire thing runs on Node.js stdlib only — no external packages, nothing to audit, nothing that breaks when a dependency changes. Try it ihdatech / coffee-installer CLI fo

Ok so first, let me be honest. This post is partly me venting. I've been maintaining node-dependency-injection for about 9 years now. 300 stars on GitHub. Not exactly viral. And every time I look at InversifyJS or tsyringe climbing in popularity I think "yeah, but at what cost". So let me explain my problem with decorators. The coupling nobody talks about When you write this: @ Injectable () export class UserService { constructor (@ Inject ( MAILER_TOKEN ) private mailer : IMailer ) {} } Where does that @Injectable() live? In your DI framework. Which means your UserService — which is domain logic, business rules, the thing that should outlive any framework decision — now has a direct dependency on your IoC container library. Your domain knows about your infrastructure. That's the wrong direction. I know, I know. "It's just a decorator, it doesn't do anything". But it's still an import. It's still coupling. And if you ever want to swap the container, or move that service somewhere else, or just test it without spinning up the whole container — you now have to think about it. With NDI, your service is just a class: export class UserService { constructor ( private mailer : IMailer ) {} } That's it. No imports from my library. No decorators. No metadata. The service doesn't know it's being injected. The wiring lives completely outside — in a YAML file or in a bootstrap file. Your domain stays clean. "But Symfony does decorators and it's fine" Symfony doesn't use decorators in services actually. The DI config is external — YAML, XML, PHP config files. Your service is just a PHP class. That's literally what inspired NDI from the beginning. What NDI actually does Quick example. You have two payment providers and you want to inject the right one based on context: services : payment.stripe : class : ' payments/StripePayment' keyed : group : payment key : stripe default : true payment.paypal : class : ' payments/PaypalPayment' keyed : group : payment key : paypal checkout.ser

Ky 2.0 is an open-source JavaScript HTTP client built on the Fetch API, featuring significant updates such as consolidated hook handling, enhanced timeout management, and improved URL processing. The release includes response validation through schema validation libraries and addresses migration from earlier versions. It aims to provide a lightweight alternative to axios. By Daniel Curtis

Hello Dev Community! 👋 It is officially Day 41 of my continuous streak toward full-stack MERN engineering! Yesterday, I migrated my codebase from native Node boilerplate to Express.js. Today, I dived straight into the absolute core mechanism that makes Express so incredibly powerful in Prashant Sir's (Complete Coding) masterclass : Middlewares . Before today, I thought requests hit an endpoint and immediately returned a response. Today, I learned how to intercept, inspect, and modify that request before it ever reaches the final route handler! 🧠 Key Learnings From Node.js Lecture 9 (Middlewares) A middleware is essentially a function that executes during the Request-Response cycle, having full access to the req , res , and the next middleware function in line. Here is the technical breakdown: 1. The Anatomy of Middleware Unlike a standard route handler that takes (req, res) , a middleware takes a third powerful argument: next . If you don't invoke next() , your request will hang forever and the browser will eventually timeout! 2. Built-in vs. Custom Middleware Custom Middleware: Wrote my own custom functions using app.use((req, res, next) => { ... }) to act as a security guard or global logger. Built-in Middleware: Explored how Express natively handles data types using structures like express.json() and express.urlencoded() , which automatically parse inbound request bodies so we don't have to manually handle streams anymore! javascript const express = require("express"); const app = express(); // Custom Global Logging Middleware app.use((req, res, next) => { console.log(`[${new Date().toISOString()}] ${req.method} request to ${req.url}`); next(); // Pass control to the next handler in line! }); app.get("/dashboard", (req, res) => { res.send("Welcome to the secure dashboard layer!"); }); app.listen(8000);

The Cryptographic Trust Problem (Why Webhooks Are Unforgiving) Webhooks are the nervous system of modern production apps. Whether you are processing a payment on Stripe, tracking a subscription on Lemon Squeezy, or fulfilling an order via Shopify, webhooks are how external platforms tell your backend: "Hey, something important just happened". Because these webhook endpoints have to be publicly accessible, they are prime targets for malicious actors. To prevent this, platforms use cryptographic signature verification . The Golden Rule of Verification When a provider sends a webhook, they take the HTTP request body and hash it with a shared secret key using HMAC-SHA256 . They pass this resulting signature in the request headers (like Stripe-Signature). When the request hits your server, your code has to do the exact same math: Grab the shared secret. Grab the exact raw bytes of the incoming request body. Hash them together and compare your result with the signature in the header. This process is completely binary and zero-tolerance. If your backend framework alters even a single byte—adding a trailing newline, stripping a whitespace, or reordering a JSON key during parsing—the math changes entirely. The signatures won't match, and the verification will fail. This brings us to our fundamental architectural bottleneck: to verify a webhook, you must intercept the request before your framework touches it. Why Python/Werkzeug Struggles If you build a Cloud Function in Python using the Firebase Functions SDK, you are working on top of Flask, which relies on Werkzeug to handle the underlying web server mechanics. Werkzeug is fantastic for standard web apps, but it has a specific architectural design that makes webhook verification a nightmare: it treats the incoming request body as a one-time, sequential input stream. The Single-Consumption Stream Under the WSGI (Web Server Gateway Interface) standard that powers Python web frameworks, the network payload arrives as an activ