Typedrift v1.0.0: Eliminate Type Drift in React Apps

Coming in typedrift v1.1.0 Exactly one week ago, I shipped the first version of Typedrift because I got tired of the same old headaches in data fetching for React-driven frameworks. Data fetching has always felt broken. You define exactly what data a component needs in its props… then duplicate that logic in a separate query. Over time, they drift. You only discover the mismatch at runtime. Typedrift fixes that. Instead of writing queries, you define a typed view from your model. That view becomes the single source of truth for both fetching on the server and the props your component receives. No more duplication. No drift. What’s new in v1.1.0: - TanStack Adapter: seamless integration with TanStack Start - Next.js Adapter: first-class support for App Router and Server Components Clean, type-safe data fetching with zero boilerplate and zero codegen. If you’ve felt the pain of maintaining queries that drift away from your components (especially if you’ve used Relay, tRPC, or TanStack Query), I’d love your feedback. Check it out: - NPM: https://lnkd.in/drSZji_9 - GitHub: https://lnkd.in/e5HRgUgA What do you think — does this approach solve a real problem for you? #React #TypeScript #DataFetching #WebDev #NextJS #TanStack

The Queue That Saved Our PDF Pipeline We had a feature that generated detailed reports on demand. A React button, a NestJS endpoint, Puppeteer spinning up a headless browser. Simple enough. Until it was not. At some point, a user triggered 40 reports at once. The server ran out of memory. The request timed out. The user got nothing. The logs were a disaster. The fix was not more RAM. It was BullMQ. The principle is straightforward: do not do expensive work inside a request-response cycle. Accept the request, enqueue the job, return a job ID immediately. The client polls or listens for status. The worker processes jobs one at a time, or in controlled concurrency. Here is what that shift looked like in practice for the PDF pipeline: The NestJS controller goes from calling a service directly to calling queue.add() with a payload. The response changes from a file stream to a job ID and a status URL. A separate worker class, decorated with @Processor, handles the actual Puppeteer work. BullMQ manages retries automatically when Puppeteer crashes. A Bull Board dashboard gives full visibility into pending, active, and failed jobs. The result was not just stability. It was observability. Suddenly we could see exactly which reports were stuck, retry them individually, and set priority on urgent jobs without touching code. If your application does anything slow, anything that involves a third-party call, file generation, email sending, or data processing, that work belongs in a queue. Not in a controller. The request-response cycle is for acknowledgment. The queue is for work. #NestJS #NodeJS #BullMQ #SoftwareArchitecture #BackendDevelopment #WebDevelopment #QueueProcessing #Puppeteer #OpenSource

Most Express file uploads are unnecessarily complicated. We’ve normalized splitting data across: req.body, req.file, req.files But what if files just stayed inside req.body… like they logically belong? I just released multipartbody — an Express middleware that merges uploaded files directly into req.body. No scattered data. No messy reconstruction logic. Just one clean payload. What it supports: ✔ Nested objects ✔ Arrays ✔ MIME allowlists ✔ Multer-style limits ✔ Full TypeScript support Imagine sending this via curl: curl --location 'http://localhost:3000/upload' \ --form '[0].id=1' \ --form '[0].docs[0].file=@"/path/to/file-1.jpg"' \ --form '[1].id=2' \ --form '[1].docs[0].file=@"/path/to/file-2.jpg"' With multipartbody, your Express handler receives a clean, top-level array: app.post('/upload', (req, res) => {  console.log(req.body);   /* [     { id: '1', docs: [{ file: [FileObject] }] },     { id: '2', docs: [{ file: [FileObject] }] }    ]  */ }); npm: https://lnkd.in/dti9HDCN GitHub: https://lnkd.in/dJ2ik883 #NodeJS #ExpressJS #WebDevelopment #OpenSource #SoftwareEngineering #Backend #JavaScript

Count the lines of React 18 code you write for every single form submission: const [isPending, setIsPending] = useState(false) const [error, setError] = useState(null) async function handleSubmit(e) {  e.preventDefault()  setIsPending(true)  try { await save() } catch(e) { setError(e.message) }  finally { setIsPending(false) } } Now count the React 19 version: const [state, formAction, isPending] = useActionState(saveAction, null) One line. Same behavior. Automatic pending state, error handling, and reset. That's what React 19 is: the same React, with the boilerplate removed. Here's everything that changed: ⚡ Actions + useActionState — async mutations without manual loading state 🌐 Server Actions — call server functions from client components. No custom API routes. Just 'use server'. 🪜 Server Components — render on server, ship zero JS. Default in Next.js 15. ❤️🔥 useOptimistic — instant UI updates before the server responds. Auto-rollback on failure. ⚙️ use() hook — unwrap promises and read context inside loops, conditions, early returns. 🏠 Native metadata — <title> and <meta> tags from any component. No react-helmet. ❌ No more forwardRef — ref is just a prop in React 19. forwardRef deprecated. 🔍 Better hydration errors — actual diffs instead of "tree will be regenerated". 🤖 React Compiler — automatic memoization at build time. No more useMemo busywork. I wrote the complete guide — every new API with real before/after examples, Server Actions deep dive, and the React 18 → 19 migration steps. Still on React 18? 👇 #React #JavaScript #Frontend #WebDev #ReactJS #100DaysOfBlogging

Your backend probably isn’t slow. Your request path is.  I’ve seen teams jump to “we need a bigger server” when the real problem was a request doing 5 things in sequence:  auth lookup -> DB query -> internal service call -> AI call -> response shaping.  That feels like a backend issue.  Most of the time, it’s a design issue.  I’ve seen this pattern on real product work across systems where i past work.  → Clean code can still hide a bad waterfall. A few independent `await`s can quietly turn into 800ms of waiting.  → “Database slowness” is often query shape. Small dev data hides N+1 problems. Production exposes them.  → Heavy work inside the request is a trap. If it can run in a queue, it probably should.  I wrote this up with practical examples, NestJS snippets, and diagrams here:  https://lnkd.in/gmvaNejz  #BackendEngineering #Nodejs #NestJS #SystemDesign #APIPerformance #DeveloperWorkflow

Why my API was slow (and what actually fixed it) I recently noticed one of my APIs was taking way too long to respond — sometimes 3–4 seconds per request. At first, I thought it was just my code being “messy,” but digging deeper taught me a lot. Here’s what I found: Too many unnecessary DB calls – I was fetching the same data multiple times instead of reusing it. Unoptimized queries – Some queries were scanning entire collections instead of using indexes. Synchronous loops – I was waiting for each call to finish one by one, instead of running them in parallel. After making a few changes: Added proper indexes Used Promise.all for parallel DB calls Cached repeated data where possible Response time went from 3–4 seconds → under 300ms. The biggest takeaway? Sometimes it’s not your code logic, it’s how your code talks to the database and handles tasks. Small adjustments can make a huge difference. #FullStackDeveloper #WebDevelopment #APIDevelopment #BackendDevelopment #NestJS #NextJS #JavaScript #PerformanceOptimization #SoftwareDevelopment

#NestJS isn’t just about modules. The real magic? Guards, Pipes, and Interceptors. 🧙♂️ Most developers stop at controllers and services. But if you aren't leveraging the request lifecycle, you're writing repetitive, messy code. Let’s break down the Holy Trinity of #NestJS execution: 🛡️ GUARDS (The Bouncer) When: Runs BEFORE the route handler. What: "Does this user have permission?" Use case: Authentication, Role-based access control (RBAC). Return: boolean (allow/deny). 📏 PIPES (The Validator) When: Runs just before the handler, AFTER the guard. What: "Is this data shaped correctly?" Use case: Validation (class-validator), Transformation (string → number). Return: The transformed value or throw an exception. ⚡ INTERCEPTORS (The Wrapper) When: Runs BEFORE and AFTER the handler. What: "What do I do with the request/response?" Use case: Logging, response mapping (removing passwords), caching, timeout handling. Pro-Tip: The order matters. Request Flow: Middleware → Guard → Interceptor (before) → Pipe → Controller → Interceptor (after) → Response Here is the money quote: "Use Guards to say YES/NO. Use Pipes to shape the DATA. Use Interceptors to wrap the BEHAVIOR." 👇 What is the first custom NestJS injectable you ever built? Guard, Pipe, or Interceptor? Let me know in the comments. ♻️ Repost to help your network write cleaner NestJS code. #NestJS #NodeJS #TypeScript #SoftwareArchitecture #BackendDevelopment

Stop treating Multer as just a “File Uploader.” 📦 Ever wondered why req.body is empty when you send a file and data, even though the frontend is perfect? 🤔 Most developers add upload.single() to the route because the tutorial said to. But the real work happens in the parsing, not just the storage. The Technical Reality ⚙️ The Parser Gap: Standard JSON parsers cannot decode multipart/form-data. This format sends data in a boundary-separated stream that Express doesn't naturally read. The "Unlock" Mechanism: Multer’s main job is to intercept that stream 🔓 It is the middleware that fills req.body for your text fields and req.file for your binary data. The Dependency: Without this middleware, your server is essentially blind 👀❌ Not just to the file — but to the entire request payload. Don't just say you're uploading a file. You are parsing a multipart request to reconstruct data that would otherwise be unavailable to the server. Understanding the request-response cycle at this level is what separates someone who just codes… from someone who truly builds 🚀 #NodeJS #Backend #ExpressJS #SoftwareEngineering #WebDev