Node.js Event Loop Freeze Prevention with Worker Threads

Building a browser-based strategy game is essentially a masterclass in frontend state management. Today’s focus on the "Siege of Eger" engine: creating a seamless, type-safe data pipeline from a Supabase backend to an Angular 21 frontend. 🏰 Here is a breakdown of today's architecture evolution: 🔹 Strict Full-Stack Type Safety (Zod) When bridging PostgreSQL and TypeScript, data types like timestamptz can cause silent bugs if not handled correctly. By using Zod to parse the backend DTOs, the raw DB timestamp string is safely transformed into a JavaScript Date object before it ever touches the game logic. If the schema fails, the app catches it immediately. 🔹 Reactive Fetching with httpResource I migrated the data layer away from raw fetch Promises to Angular 19/21's native httpResource. 💡 Why it’s great: It automatically exposes .value(), .isLoading(), and .error() as Signals. This completely eliminates manual loading state boilerplate, handles memory cleanup automatically, and makes building polished UI transitions trivial. 🔹 The Client-Side Game Loop (NgRx SignalStore & RxJS) To make resources "generate" in real-time, you can't ping the database every second. 💡 The Solution: The server acts as the source of truth (saving a timestamp for offline progress), while the local NgRx SignalStore runs an RxJS interval to optimistically calculate the "delta time" and update the UI tick-by-tick. Moving a codebase from a "working prototype" to a "scalable, reactive architecture" is where the real fun begins. What is your go-to pattern for managing high-frequency, real-time state updates in modern frontend frameworks? Let me know below! 👇 #Angular #TypeScript #WebDevelopment #SoftwareArchitecture #RxJS #NgRx #Frontend #Fullstack #Coding #Programming

Early on, we’ve all written that routes.js file. You know the one. Business logic, Joi validations, database queries, and error handling—all stuffed into one massive functional callback. It works perfectly fine for a quick MVP. But when the application scales, it becomes a nightmare to maintain, debug, and test. Moving to class-based controllers—specifically using a framework like Hapi—completely changes the way you look at Node.js architecture. Here is why making the shift to structured, object-oriented patterns is worth the effort: 1. True Separation of Concerns: Your route file simply maps endpoints to controller methods. The controller handles the request/response lifecycle, and the heavy lifting is pushed down to your service layer. 2. Dependency Injection: Class constructors make it incredibly easy to inject your database instances (like Postgres) or external services. Your code becomes modular and completely decoupled. 3. Painless Unit Testing: Because dependencies are injected through the constructor, mocking them out for unit tests takes seconds. No more wrestling with complicated proxy tools just to isolate a function. 4. Readability: When a new engineer jumps into the codebase, they don't have to untangle a web of nested functions. The architecture is predictable. Functional programming in JavaScript is great, but for structured, robust backend systems, class-based architectures bring a level of sanity and predictability that is hard to beat. Curious to hear from other backend folks—are you team functional routes or team class-based controllers? Let me know below! 👇 #nodejs #hapijs #backendengineering #softwarearchitecture

“Uploading a file” sounds easy… Until you implement it in the backend. ⚙️ This week, I built file upload functionality using **Multer middleware** in Express.js — and it completely changed how I understand the request lifecycle in Node.js. 🚀 Here’s what actually happens: When a client sends `multipart/form-data`, Express cannot handle it by default. ❌ Multer acts as a middleware layer that: • 🔄 Intercepts the request • 📂 Processes incoming files • 📎 Attaches them to `req.file` or `req.files` • 🧱 Passes structured data to the controller Example: ```javascript router.route('/register').post( upload.fields([ { name: "avatar", maxCount: 1 }, { name: "coverImage", maxCount: 1 } ]), registerUser ); ``` Key concepts I strengthened: • 🔹 `.single()` vs `.array()` vs `.fields()` • 🔹 Difference between `req.file` and `req.files` • 🔹 How middleware fits into clean backend architecture • 🔹 Why file validation is critical for security 🔐 • 🔹 Separating concerns between middleware and controllers 💡 Big realization: Backend development is not just about building routes. It’s about controlling data flow, enforcing structure, and thinking about security at every layer. Small features like file uploads teach big architectural lessons. If you’re learning backend — what concept recently changed your understanding? 👇 #BackendDevelopment #NodeJS #ExpressJS #JavaScript #WebDevelopment #Multer #SoftwareEngineering #LearningInPublic

Your Node Version Is Lying to You, And nvm Is the Fix That yellow warning line in your terminal isn’t noise. It’s a contract violation, and understanding it changes how you think about every project you will ever clone. I was setting up the p5 web editor on my local machine. Excited, ready to explore the codebase, ready to contribute. I cloned the repo. Opened PowerShell. Ran npm i. And then the terminal started talking back in a language I didn’t fully understand yet. npm warn EBADENGINE Unsupported engine { npm warn EBADENGINE package: ‘p5.js-web-editor@2.20.2’, npm warn EBADENGINE required: { node: ‘18.20.8’, npm: ‘10.8.2’ }, npm warn EBADENGINE current: { node: ‘v25.4.0’, npm: ‘11.7.0’ } npm warn EBADENGINE } It still installed. “Added 2877 packages.” Green text. Looked fine. So I tried to run it. This isn’t just a story about fixing a version number. It’s about understanding the invisible contract that exists between every piece of software and the environment it was born in, and about a tool called nvm that exists precisely because that contract gets violated more often than anyone wants to admit. The Historical Backdrop: Why Does Node Even Have Versions? To understand why a version number caused this whole saga, we need to go back to where Node.js began. Node.js was created in 2009 by Ryan Dahl. His insight was simple: take the V8 JavaScript engine, the same engine powering Chrome, and let it run on a server. Suddenly, JavaScript wasn’t just a language for making buttons wiggle on web pages. It could power backend servers, read files, talk to databases, and build entire applications. Developers loved it. Adoption exploded. Entire companies were built on it. But here’s where things got complicated. Because Node.js was evolving so fast, new APIs, performance improvements, security patches, breaking changes, and different projects started being built on different versions. A project written in 2018 might depend on APIs that existed in Node 8. A project written in 2022 might use features that only landed in Node 16. And they weren’t always compatible with each other, or with what came after. This created a real and persistent problem. A developer’s machine might have Node 12 installed globally. The project they just cloned needed Node 18. What happens? Sometimes things work. Sometimes they crash in weird, unrelated-looking ways. And sometimes, like in my case, you get a very clear warning that says: “I need Node 18.20.8. You gave me 25.4.0. We need to talk.” The Node community’s answer was version managers. And on Windows, the most popular one is nvm-windows. What Is nvm, and Why Does It Exist? nvm stands for Node Version Manager...... Read the full piece on Medium; [https://lnkd.in/d6_vUsNt] #nodejs #nvm #npm #javascript #webdevelopment #opensource #EBADENGINE

Node.js event loop: The thing nobody explains properly. After 2 years of writing Node.js, I finally understand why my API was slow. The problem? I was blocking the event loop without knowing it. 🔄 How Node.js actually works: 1. Event Loop (single-threaded) → Handles I/O operations → Non-blocking by default → Can process thousands of requests 2. Worker Pool (multi-threaded) → Handles CPU-intensive tasks → File system operations → Crypto operations ⚠️ What blocks the event loop: ❌ Synchronous operations: - JSON.parse() on huge payloads - Crypto.pbkdf2Sync() - Heavy regex operations - Large loops (1M+ iterations) ✅ What doesn't block: - Database queries (async I/O) - HTTP requests (async I/O) - File reads with fs.promises - setTimeout/setInterval ✅Fix:move heavy work to: - Worker threads - Child processes - External queue systems Lesson: Node.js is fast for I/O, not CPU work. What's your biggest Node.js performance lesson? Code is attached as a screenshot for readability. What’s your biggest Node.js performance lesson? 👇 #SoftwareDevelopment #JavaScript #NodeJS #EventLoop #SoftwareEngineering #Performance #Programming #BackendDevelopment #Coding #Async #WorkerThreads

𝐀𝐫𝐞 𝐲𝐨𝐮 𝐬𝐭𝐢𝐥𝐥 𝐥𝐞𝐭𝐭𝐢𝐧𝐠 𝐓𝐲𝐩𝐞𝐒𝐜𝐫𝐢𝐩𝐭 𝐝𝐞𝐟𝐚𝐮𝐥𝐭 𝐭𝐨 `any` 𝐰𝐡𝐞𝐧 𝐚𝐜𝐜𝐞𝐬𝐬𝐢𝐧𝐠 𝐨𝐛𝐣𝐞𝐜𝐭 𝐩𝐫𝐨𝐩𝐞𝐫𝐭𝐢𝐞𝐬 𝐝𝐲𝐧𝐚𝐦𝐢𝐜𝐚𝐥𝐥𝐲? 𝐓𝐡𝐞𝐫𝐞'𝐬 𝐚 𝐛𝐞𝐭𝐭𝐞𝐫 𝐰𝐚𝐲 𝐭𝐨 𝐬𝐭𝐚𝐲 𝐭𝐲𝐩𝐞-𝐬𝐚𝐟𝐞. One common challenge in TS is creating generic functions that can access properties of an object without sacrificing compile-time type safety. Many resort to `any` or complex overloads, losing the benefits of TypeScript. The trick is combining Generics, `keyof`, and `extends` to tell the compiler exactly what to expect. Here’s a simple pattern for a type-safe `getProperty` function: ```typescript function getProperty<T, K extends keyof T>(obj: T, key: K): T[K] { return obj[key]; } interface User { id: number; name: string; email: string; } const user: User = { id: 1, name: 'Alice', email: 'alice@example.com' }; const userName = getProperty(user, 'name'); // Type of userName is 'string' - inferred correctly! const userId = getProperty(user, 'id'); // Type of userId is 'number' - perfect! // getProperty(user, 'address'); // Compiler error! 'address' is not assignable to type 'keyof User'. This is exactly what we want. ``` This pattern ensures that `key` is always a valid property of `T`, and the return type is correctly inferred as `T[K]`. No more runtime surprises or `any` casts! It's clean, reusable, and powerfully type-safe. What's your go-to TypeScript trick for maintaining type safety with dynamic data? Share in the comments! #TypeScript #FrontendDevelopment #SoftwareEngineering #React #WebDev

After weeks of building, I'm excited to share CodeReview — a self-hosted, real-time collaborative code review platform built from scratch. What it does: Developers can submit code, get instant automated analysis, leave line-by-line comments, and receive live notifications — no polling, no page refreshes. The architecture I'm most proud of: - The backend runs on 5 independent Go microservices — User, Review, Analysis, Notification, and an API Gateway — all communicating asynchronously via RabbitMQ. - When a review is submitted, an event cascades through the pipeline: triggering static analysis (10+ rules including hardcoded secret detection), persisting results, and broadcasting a live update over WebSocket. - Service-to-service communication happens over gRPC, with the API Gateway as the single HTTP/WebSocket entry point. - The frontend is a Vue.js 3 + TypeScript SPA with Pinia, Tailwind CSS v4, and auto-reconnecting WebSocket support. A few deliberate constraints I imposed on myself: No ORM — raw SQL throughout No generated gRPC stubs — manual Protobuf definitions Stateless JWT auth across all services Full Docker Compose setup for MySQL + RabbitMQ This was a genuine deep-dive into distributed systems design, real-time communication, and Go microservices patterns. Building something end-to-end — from auth to event-driven pipelines to a live UI — taught me more than any tutorial could. Check it on: https://lnkd.in/g3SHmfQB #GoLang #Microservices #VueJS #RabbitMQ #gRPC #WebSocket #DistributedSystems #BackendDevelopment

Most developers think Dependency Injection in NestJS is just framework magic. It’s not. It’s architectural discipline. On the left: Control is tight. Everything creates everything. On the right: Responsibilities are clear. Dependencies are declared. The container orchestrates. That shift — from creating dependencies to declaring dependencies — is where clean architecture begins. The real question is: If your database changes tomorrow… does your business logic panic? Or does it calmly accept a new provider? Dependency Injection isn’t about syntax. It’s about designing for change. #NestJS #BackendDevelopment #CleanCode #SoftwareArchitecture #DependencyInjection

✅ Just shipped: complex data structures as variables in Featurevisor https://lnkd.in/eyFZWXun 🚀 Previously, objects and arrays were limited to flat untyped objects and arrays of strings only. Going forward, variables can be more powerful supporting deep nested objects and also arrays of objects with full type safety backed by build-time validations. ✨ This also means your new complex variables can take full advantage of targeting by various different rules and overriding them depending on your custom requirements. 🙌 If you can imagine your configuration, you can now express it in Featurevisor with full clarity and safety. 👉 Note: Non-breaking change for v2.x users. Upgrade SDK first in your application(s), and then the CLI in your project. #featuremanagement #configuration #developers #software #delivery #cicd #opensource #javascript #nodejs #typescript #featureflags #data

🚀 NestJS Request Lifecycle — What Really Happens to Every Incoming Request? If you’re building APIs with NestJS, understanding the request lifecycle is critical for writing clean authentication, validation, logging, and error-handling logic. 📥 Incoming Request Flow => 1. Middleware The first layer that executes. Used for logging, modifying request objects, parsing tokens, etc. Runs before guards. => 2. Guards Determine whether the request should proceed. Best place for authentication & authorization logic. If a guard returns false, the request stops here. => 3. Interceptors (Before Handler) Interceptors wrap around the route handler. They execute logic before the handler runs (e.g., logging, caching, performance tracking). => 4. Pipes Pipes handle validation and transformation. This is where DTO validation (class-validator) and transformation (class-transformer) happen. If validation fails → an exception is thrown. => 5. Controller → Route Handler Your actual business logic executes here. Services are called. Database operations run. Data is processed. 📤 Outgoing Response Flow => 6. Interceptors (After Handler) Interceptors can transform or format the response before sending it back to the client. Example: wrapping responses in a standard API format. => 7. Exception Filters (If Error Occurs) If any error is thrown in the lifecycle, exception filters catch it and shape the final error response. 💡 Important Detail Developers Miss: Interceptors are executed twice: • Before the handler (request phase) • After the handler (response phase) This makes them extremely powerful for logging, caching, and response mapping. 🔥 Real-World Example: Request → Middleware logs request → Guard validates JWT → Pipe validates DTO → Controller processes logic → Interceptor formats response → Response sent Understanding this flow makes debugging easier, improves architecture decisions, and prevents mixing responsibilities. If you're serious about scalable backend systems, mastering the request lifecycle is non-negotiable. Official docs: https://lnkd.in/gxfvSqyC Are you using global guards and interceptors in your NestJS apps? #nestjs #nodejs #backenddevelopment #javascript #softwareengineering #api #webdevelopment