Gabriele Ferreri’s Post

The Try-Catch Time Trap: Why Async Errors Escape? Lets look at this code that reads and parse the invalid JSON file. Sync code try { const data = fs.readFileSync("invalid.json", "utf-8"); const jsonData = JSON.parse(data); } catch (err) { console.log("error caught:", err.message); // catches parsing error } All good. --- Async code try { fs.readFile("invalid.json", "utf-8", (err, data) => { const jsonData = JSON.parse(data); }); } catch (err) { console.log("error caught:", err.message); // does NOT even run } Catch block won't execute. Now the question is… 👉 Why? --- Here’s how I started thinking about it: If JS finds an error → it stops execution → looks for a catch block in the current call stack → if not found, it bubbles up the stack --- In sync code: 👉 Everything runs in one continuous stack → error happens → catch block is right there → so it works --- But async changes things. When this line runs: fs.readFile(..., callback) 👉 JS does NOT execute the callback immediately Instead: → it registers the callback → pushes it to the event loop → and moves on --- Now important part 👇 👉 The current call stack finishes execution → which means try-catch is gone --- Later… 👉 when file reading is done → event loop pushes the callback to the call stack → callback runs But now: 👉 this is a new call stack And the old try-catch? 👉 already gone. --- So when error happens inside callback: ❌ there is no catch block anymore --- That’s when it clicked for me: 👉 try-catch works only within the same execution stack Not across time. Not across async boundaries. #JavaScript #Node #Programming #ErrorHandling #Interview #Eventloop #Callstack

Prisma's bundle in a Lambda function: node_modules/@prisma/client: ~15MB query-engine-rhel-openssl: ~40MB Drizzle's bundle in a Lambda function: drizzle-orm: ~7.4KB That's not a small difference. That's a different category of tool. I wrote the complete Drizzle ORM guide — here's why it's become my default for TypeScript backends: 📐 Schema as TypeScript — your tables are TypeScript files. Types flow automatically. No .prisma DSL to maintain separately. 🧠 SQL-like queries — if you know SQL, you already know Drizzle: db.select()  .from(posts)  .where(and(eq(posts.published, true), gte(posts.createdAt, cutoff)))  .orderBy(desc(posts.createdAt))  .limit(10) Every clause maps directly to SQL. No custom vocabulary. ⚡ Zero initialization overhead — no query engine to spin up. Critical for serverless cold starts. 🔗 Relations with full type inference — define once, query with typed nested results. 🗄️ Drizzle Kit — generates migrations by diffing your TypeScript schema. No shadow database required. 🖥️ Drizzle Studio — browser-based DB GUI, one command: npx drizzle-kit studio 📦 Zero dependencies — works on Node.js, Bun, Deno, Cloudflare Workers, Lambda, and edge runtimes. Full guide in my article — schema, queries, relations, transactions, migrations, Zod integration, and serverless patterns. Are you on Drizzle yet? 👇 #Drizzle #TypeScript #JavaScript #WebDev #Backend #100DaysOfBlogging

Type errors slip through because strict mode is off and any is everywhere. ────────────────────────────── Partial and Required Utility Types Guide with Examples Learn how to effectively use Partial and Required utility types in TypeScript. This tutorial covers detailed explanations, practical examples, and common pitfalls to help you master these concepts. hashtag#typescript hashtag#utilitytypes hashtag#partial hashtag#required hashtag#programming hashtag#intermediate ────────────────────────────── Core Concept Partial and Required are utility types that were introduced in TypeScript 2.1. They are part of a broader set of utility types that TypeScript provides to manipulate types more effectively. These utilities help developers write more robust and maintainable code by allowing the definition of types that can be modified dynamically. Partial<T> constructs a type with all properties of T set to optional. This is particularly useful in scenarios where not all properties are necessary at all times, such as during updates or optional configurations. Required<T>, on the other hand, constructs a type with all properties of T set to required. This is useful for scenarios where you need to enforce that certain properties are always present, such as when processing form data. Key Rules • Always prefer Partial when updating objects to allow flexibility. • Use Required to enforce strict property requirements during data creation. • Leverage TypeScript’s type inference to reduce redundant type annotations. 💡 Try This interface User { id: number; name: string; ❓ Quick Quiz Q: Is Partial and Required Utility Types different from Type Assertions? A: Yes, Partial and Required are different from type assertions. Type assertions tell the TypeScript compiler to treat a variable as a specific type. In contrast, Partial and Required create new types based on existing ones, modifying their properties. 🔑 Key Takeaway In this tutorial, we covered the usage of Partial and Required utility types in TypeScript. We explored their definitions, use cases, and best practices for implementation. Understanding these utility types helps you create flexible and robust code structures. The next step is to apply these concepts in your applications and explore more advanced TypeScript features. ────────────────────────────── 🔗 Read the full guide with code examples & step-by-step instructions: https://lnkd.in/gbCtW8Pa

🎬 𝘖𝘯𝘦 𝘤𝘰𝘯𝘤𝘦𝘱𝘵. 𝘍𝘰𝘶𝘳 𝘧𝘰𝘳𝘮𝘴. 𝘐𝘯𝘧𝘪𝘯𝘪𝘵𝘦 𝘶𝘴𝘦 𝘤𝘢𝘴𝘦𝘴. You've seen what Streams are. Now let's meet each one properly. ━━━━━━━━━━━━━━━ 🧵 Node.js Streams 𝗧𝗵𝗲 𝟰 𝗙𝘂𝗻𝗱𝗮𝗺𝗲𝗻𝘁𝗮𝗹 𝗦𝘁𝗿𝗲𝗮𝗺𝘀 𝗘𝘅𝗽𝗹𝗮𝗶𝗻𝗲𝗱 ━━━━━━━━━━━━━━━ 1️⃣ 𝗥𝗲𝗮𝗱𝗮𝗯𝗹𝗲 𝗦𝘁𝗿𝗲𝗮𝗺 Data flows IN. You consume it chunk by chunk. Example → fs.createReadStream() Key events: → 𝗱𝗮𝘁𝗮 — fires every time a chunk arrives → 𝗲𝗻𝗱 — fires when there's nothing left to read → 𝗲𝗿𝗿𝗼𝗿 — fires if something goes wrong 2️⃣ 𝗪𝗿𝗶𝘁𝗮𝗯𝗹𝗲 𝗦𝘁𝗿𝗲𝗮𝗺 Data flows OUT. You push it somewhere. Example → fs.createWriteStream() Key functions: → 𝘄𝗿𝗶𝘁𝗲() — sends a chunk to the destination → 𝗲𝗻𝗱() — signals no more data will be written → 𝗳𝗶𝗻𝗶𝘀𝗵 event — fires when all data has been flushed 3️⃣ 𝗗𝘂𝗽𝗹𝗲𝘅 𝗦𝘁𝗿𝗲𝗮𝗺 Both Readable AND Writable at the same time. Example → net.Socket (TCP connections) A socket can receive data AND send data simultaneously. Two lanes. One stream. ⚡ 4️⃣ 𝗧𝗿𝗮𝗻𝘀𝗳𝗼𝗿𝗺 𝗦𝘁𝗿𝗲𝗮𝗺 Data comes in → gets modified → goes out. Example → zlib.createGzip() Reads raw data, compresses it on the fly, outputs compressed chunks. No need to load the full file. No memory spike. 🔥 Key function: → 𝗽𝗶𝗽𝗲() — chains streams together like a pipeline ━━━━━━━━━━━━━━━ 𝗧𝗵𝗲 𝗯𝗶𝗴 𝗽𝗶𝗰𝘁𝘂𝗿𝗲: ━━━━━━━━━━━━━━━ Readable → Transform → Writable That's a full streaming pipeline. Read a file → compress it → write it to disk. All in one chain. All chunk by chunk. All production grade. 🚀 Which of the 4 have you used in your projects? Drop it below. 👇 #NodeJS #BackendDevelopment #JavaScript #Streams #Developer

𝗠𝗮𝘀𝘁𝗲𝗿𝗶𝗻𝗴 𝗩𝗮𝗿𝗶𝗮𝗯𝗹𝗲𝘀 𝗮𝗻𝗱 𝗗𝗮𝘁𝗮 𝗧𝘆𝗽𝗲𝘀 𝗶𝗻 𝗝𝗮𝘃𝗮𝗦𝗰𝗿𝗶𝗽𝘁 Variables and data types are key to storing and manipulating information in JavaScript. You need to understand how to use them. You use variables to store data. In JavaScript, you declare variables with let, const, or var. For example: let age = 30 const name = 'Alice' var isAdmin = false JavaScript has six main data types: - string - number - boolean - null - undefined - symbol Each type stores simple data. JavaScript also has complex data types like objects and arrays. Objects store key-value pairs. Arrays store ordered lists. For example: const person = { name: 'Bob', age: 25 } const numbers = [1, 2, 3, 4, 5] JavaScript is dynamically typed. Variables can change types during runtime. Type coercion converts one data type to another. For example: const result = 10 + '5' // Result: '105' To write good code, follow best practices. Use const for values that do not change. Prefer let over var. Be mindful of type coercion. Mastering variables and data types helps you become a better developer. You can write cleaner code by understanding variables and data types. Source: https://lnkd.in/gpqja7bg

𝗠𝗮𝘀𝘁𝗲𝗿𝗶𝗻𝗴 𝗩𝗮𝗿𝗶𝗮𝗯𝗹𝗲𝘀 𝗮𝗻𝗱 𝗗𝗮𝘁𝗮 𝗧𝘆𝗽𝗲𝘀 𝗶𝗻 𝗝𝗮𝘃𝗮𝗦𝗰𝗿𝗶𝗽𝘁 Variables and data types are key to storing and manipulating information in JavaScript. You need to understand how to use them. You use variables to store data. In JavaScript, you declare variables with let, const, or var. For example: let age = 30 const name = 'Alice' var isAdmin = false JavaScript has six main data types: - string - number - boolean - null - undefined - symbol Each type stores simple data. JavaScript also has complex data types like objects and arrays. Objects are key-value pairs. Arrays are ordered lists. For example: const person = { name: 'Bob', age: 25 } const numbers = [1, 2, 3, 4, 5] JavaScript is dynamically typed. Variables can change types during runtime. Type coercion converts one data type to another. For example: const result = 10 + '5' // Result: '105' To write good code, follow best practices. Use const for values that do not change. Prefer let over var. Be mindful of type coercion. Mastering variables and data types helps you become a better developer. You can write cleaner code by understanding variables and data types. Source: https://lnkd.in/gpqja7bg

Type errors slip through because strict mode is off and any is everywhere. ────────────────────────────── Readonly and ReadonlyArray Guide with Examples Learn everything about Readonly and ReadonlyArray in TypeScript. This comprehensive guide covers usage patterns, best practices, and common pitfalls with real-world examples. hashtag#typescript hashtag#readonly hashtag#readonlyarray hashtag#programming hashtag#tutorial ────────────────────────────── Core Concept Readonly and ReadonlyArray are key components of TypeScript's type system aimed at providing immutability. Introduced to facilitate safer coding practices, these types prevent unintended side effects by ensuring that objects and arrays cannot be modified after their initial creation. The Readonly modifier can be applied to object properties to indicate they should not be changed. This is particularly useful in large applications where state management is critical, as it allows developers to build predictable and reliable code. On the other hand, ReadonlyArray is a special type for arrays that prevents modifications like push, pop, or splice. This immutability helps in maintaining data integrity, especially in functional programming paradigms where functions avoid changing input data. Key Rules • Use Readonly for Configuration: Always make configuration objects readonly to prevent unintended changes. • Leverage ReadonlyArray for Functional APIs: When creating functions that take arrays as arguments, prefer ReadonlyArray to signal immutability. • Document Readonly Properties: Clearly document which properties are readonly to improve code readability. 💡 Try This // A readonly array of numbers const numbers: ReadonlyArray<number> = [1, 2, 3, 4]; // Attempting to modify the array will cause a compilation error ❓ Quick Quiz Q: Is Readonly and ReadonlyArray different from Array? A: Yes, Readonly and ReadonlyArray are different from Array in that they enforce immutability. While a regular array allows modifications such as adding or removing elements, a readonly array does not permit these operations, making it safer for use in applications where data integrity is essential. 🔑 Key Takeaway In this guide, we explored the concepts of Readonly and ReadonlyArray in TypeScript. We covered their definitions, use cases, and best practices for implementation. By incorporating these types into your coding practices, you can achieve greater code safety and maintainability. ────────────────────────────── 🔗 Read the full guide with code examples & step-by-step instructions: https://lnkd.in/g42n9CKf

Stop writing the same null check 5 times. Use a discriminated union instead. I spent years writing code like this: if (data && data.user && data.user.id) { ... } Then I started modeling state properly with discriminated unions in TypeScript, and it changed how I structure entire features. Instead of a blob of optional fields, you define each possible state explicitly: type FetchState<T> = | { status: 'idle' } | { status: 'loading' } | { status: 'success'; data: T } | { status: 'error'; message: string } Now TypeScript narrows the type for you. No more defensive ?. chains. No more "wait, can this be null here?" The shape of your data tells the story. It works especially well in React, where UI state maps directly to these cases. One switch on status and each branch is fully typed. The shift in thinking: stop modeling data as "what fields might exist" and start modeling it as "what states can this be in." What patterns do you reach for first when typing async state in TypeScript? #TypeScript #React #WebDevelopment

hi connections Day 25 of 30: Efficient Data Merging with LeetCode 2722 🚀 Today’s challenge, Join Two Arrays by ID, perfectly mirrors a common task in full-stack development: combining data from different API endpoints or database tables into a single, unified list. The Strategy The key to solving this efficiently is avoiding nested loops (which would lead to slow O(n^2) performance). Instead, I used a Hash Map (Object) approach: Map Creation: Store all items from the first array in an object using their id as the key. Smart Overriding: Iterate through the second array. If an id already exists, use the Spread Operator (...) to merge the objects, ensuring the second array's data takes priority. Final Sorting: Convert the object back into an array and sort it by id to meet the output requirements. Why It Matters This logic is the foundation of modern state management. Whether you're merging updated user profiles in a React frontend or joining related documents in MongoDB, understanding how to handle property overrides and unique identifiers is essential. Using a Map keeps the performance at O(n \log n), making it capable of handling large-scale data without lagging the application. Only 5 days left! The momentum is stronger than ever. 💻✨ #JavaScript #LeetCode

🚀 Most developers ignore this… until their database slows down to a crawl. Indexing isn’t just an optimization — it’s the difference between milliseconds and seconds 👇 Indexing minimizes disk access and helps you locate data faster using a structured lookup system. Primary Index ≠ Secondary Index Primary Index → Works on sorted data, defines how records are physically stored Secondary Index → Works on unsorted data, provides an additional fast lookup path When building real systems, you don’t just rely on storing data efficiently — you rely on indexing to handle performance at scale, especially for heavy SELECT queries and filtering ⚡ Think about it: Without indexing → full table scan (slow 🐢) With indexing → direct access using pointers (fast ⚡) Dense Index ≠ Sparse Index Dense Index → Entry for every record (fast lookup, more space) Sparse Index → Entry for some records (less space, slightly slower lookup) This small distinction changes how you design systems — because every index you add improves read performance but impacts writes (INSERT, UPDATE, DELETE). Good engineers don’t just add indexes blindly. They balance read vs write trade-offs based on real use cases. Building systems > memorizing concepts. What’s one concept developers often misunderstand? #fullstackdeveloper #softwareengineering #webdevelopment #javascript #reactjs #backend #buildinpublic #nodejs #nextjs #typescript