Md Kamrul Hasan’s Post

🚫 Why Your API Screams “CORS ERROR” (and how to shut it up) Your backend works. Your frontend works. Postman loves you. And then the browser walks in like: 🛑 “Whoa whoa whoa… different origin?? Not on my watch.” Bro, it’s localhost:3000 talking to localhost:8080. Literally the same laptop. ❌ "Access to fetch has been blocked by CORS policy" Why does this happen? ✅ CORS = Cross-Origin Resource Sharing When your frontend (localhost:3000) tries to call backend (localhost:8080), the browser checks: “Did the server explicitly allow this origin to access its data?” If the server didn’t send permission → browser blocks the response. To fix it, just let your backend say: “Yes, this origin is allowed.” Example (Node + Express): const cors = require("cors"); app.use(cors({ origin: "http://localhost:3000" })); ✅ Now browser is happy ✅ API works ✅ Developer survives another day Moral: CORS isn’t a bug. It’s the browser preventing unauthorized cross-site requests. Follow Lakshya Gupta for more #webdev #javascript #collegeProjects #developers #frontend #backend #coding #LearningEveryday

🚀 Understanding CORS in Node.js When building APIs with Node.js and Express, you’ll often run into something called CORS (Cross-Origin Resource Sharing) — a common issue that restricts how browsers access resources from a different origin. 💡 Simply put: CORS is a browser security feature that prevents front-end applications (like React) from calling APIs hosted on another domain unless the server explicitly allows it. 🧩 Installing the CORS Package To easily handle CORS in your Node.js app, install the CORS middleware: npm install cors Then configure it in your Express server: const express = require("express"); const cors = require("cors"); const app = express(); // Enable CORS for all routes app.use(cors()); app.get("/", (req, res) => { res.send("CORS is enabled!"); }); app.listen(8000, () => console.log("Server running on port 8000")); ⚙️ Why It Matters When your React frontend (http://localhost:3000) tries to fetch data from your Node.js backend (http://localhost:8000) — the browser blocks it unless CORS is enabled. The CORS middleware makes your API accessible in a secure and controlled way. 🧠 Pro Tip Instead of allowing all origins (*), always specify trusted domains in production for better security: app.use(cors({ origin: ["https://yourapp.com"] })); 💬 Have you faced CORS issues in your projects? Share how you handled them in the comments! #NodeJS #Express #WebDevelopment #MERN #JavaScript #CORS #APIs #Coding #PiyushMishra

𝗢𝗻𝗲 𝗹𝗶𝗻𝗲 𝗼𝗳 𝗰𝗼𝗱𝗲 𝗰𝗮𝗻 𝗳𝗿𝗲𝗲𝘇𝗲 𝘆𝗼𝘂𝗿 𝗲𝗻𝘁𝗶𝗿𝗲 𝗡𝗼𝗱𝗲.𝗷𝘀 𝗮𝗽𝗽. It is not a memory leak. It's not a slow database query. It is a silent killer, a single innocent-looking `JSON.parse()` call on a large payload. Node.js thrives on its non-blocking event loop. But `JSON.parse` is a synchronous, CPU-bound operation. When you feed it a large JSON object (say, 50MB), it takes full control of the main thread. While it is busy parsing, your server can't do anything else. • No new requests are handled. • Health checks fail. • Timeouts start piling up. It's a classic trap because it works perfectly fine in dev with small payloads, only to break completely when used in real-world conditions. So, how do we handle large JSON payloads safely? 1. 𝗦𝘁𝗿𝗲𝗮𝗺 𝘁𝗵𝗲 𝗽𝗮𝘆𝗹𝗼𝗮𝗱: Instead of buffering the entire thing into memory, use a streaming parser like `clarinet` or `JSONStream`. This processes the data in chunks, keeping the event loop free to handle other work. 2. 𝗢𝗳𝗳𝗹𝗼𝗮𝗱 𝘁𝗼 𝗮 𝗪𝗼𝗿𝗸𝗲𝗿 𝗧𝗵𝗿𝗲𝗮𝗱: For cases where streaming isn't feasible, move the parsing logic into a `worker_thread`. This isolates the blocking operation from your main application thread, protecting its responsiveness. 3. 𝗩𝗮𝗹𝗶𝗱𝗮𝘁𝗲 𝘀𝗶𝘇𝗲 𝗳𝗶𝗿𝘀𝘁: As a simple guardrail, always check the `Content-Length` header. If it’s unreasonably large, reject the request immediately—before you even start reading the body. The takeaway isn't that `JSON.parse` is bad. It's that we must be relentlessly mindful of synchronous operations in a single-threaded environment. Just one blocking call can stop everything. #NodeJS #JavaScript #Backend #Performance

React Context vs. Redux: Stop Over-Engineering Your State! Choosing the right state management tool is not about "which is better," but "which is right for my app's complexity." This simple chart explains the core trade-off: 🟢 React Context API: Your go-to for simple data that changes infrequently (like a UI theme or user profile). It's built-in and easy to start, but its re-render mechanism can hurt performance on frequently changing data. 🔴 Redux (with RTK): Necessary for large, complex apps with data that changes frequently. It’s more boilerplate, but the use of Selectors gives you highly optimized performance and DevTools provide unmatched debugging power. The Takeaway: Start with Context. Only move to Redux when you face performance bottlenecks or need its advanced debugging and middleware features. Which one do you rely on for your current project? Let me know in the comments! 👇 #ReactJS #Redux #ContextAPI #FrontendDevelopment #JavaScript #WebDevelopment

𝗘𝘃𝗲𝗿𝘆𝗼𝗻𝗲 𝗰𝗮𝗻 𝘀𝗲𝗲 𝘆𝗼𝘂𝗿 𝗦𝘁𝗿𝗶𝗽𝗲/𝗢𝗔𝘂𝘁𝗵 𝘀𝗲𝗰𝗿𝗲𝘁 𝗸𝗲𝘆𝘀 your react app's secrets are public. they're in the bundle, waiting to be read by claude or gpt. we moved sensitive configs out of the build entirely. people generally do this .env → webpack → bundle.js → "STRIPE_API_KEY": "sk-abc123" (plaintext) i propose (and am using) app start → fetch encrypted config from /api/config → decrypt in memory → never gets written to files interestingly, the decryption is done in the browser, not the server. the backend sends an encrypted payload that requires multiple runtime components to decrypt. the decryption key gets assembled from different sources: the user's auth token provides one component, a device fingerprint provides another, and the current time window provides a third. each piece alone is useless. no single component can decrypt alone. an attacker would need: • valid auth session • correct device fingerprint • current time window • the encrypted payload • the combination algorithm not to mention all of this decryption code is minified and obfuscated. in doing so, we have introduced a lot of complexity into fetching the relevant secrets for our runtime. we now also have a way to detect if someone is trying to access the config. of course, this is not bulletproof, JavaScript in the browser can always be reverse engineered with enough effort. but there's a huge difference between: "found your API key in 5 seconds with grep" vs "spent hours reverse engineering your runtime decryption." for most applications, that's the difference between leaked keys on day one and practical security. in combination to this, we should also implement rate limiting, request signatures, and canary tokens. defense in depth. are you still storing your stripe keys in .env.production and hoping for the best? #WebSecurity #Frontend #JavaScript #DevSecOps

𝗧𝗿𝗮𝗻𝘀𝗳𝗼𝗿𝗺 𝘆𝗼𝘂𝗿 𝗹𝗲𝗴𝗮𝗰𝘆 𝘀𝘆𝘀𝘁𝗲𝗺 𝘄𝗶𝘁𝗵 𝘁𝗵𝗲 𝗿𝗶𝗴𝗵𝘁 𝘀𝘁𝗿𝗮𝘁𝗲𝗴𝘆. That’s exactly what one of our clients needed. Their platform was built on outdated technologies like Backbone and jQuery. It still worked - but maintaining it was a nightmare. Impossible to scale, and vulnerable to security risks. The codebase was massive - a mix of CoffeeScript, JavaScript, and TypeScript. They knew it was a big challenge. That’s where we came in. During the transition, our goal was to: - Keep the app stable. - Keep it running. - Modernize without disruption. How? ✅ Work side-by-side with their team ✅ Introduce changes incrementally ✅ Avoid big rewrites that break things By documenting the entire process transparently, we gave other teams a clear path to follow. After 2 years of careful migration, we: ✔️ Replaced Backbone Router with React Router ✔️ Transitioned data stores to GraphQL ✔️ Shifted state management to React Hooks Curious how we did it? I’ll leave the full case study in the comments 🔗 #softwareengineering #programming #technology #casestudy

💡 Understanding Pure Components in React — With a Simple Real-Life Example Have you ever noticed how React re-renders a component even when the data doesn’t really change? That’s where Pure Components come to the rescue! 🚀 👉 What is a Pure Component? A Pure Component in React is like a smart component that only re-renders when there’s an actual change in the data (props or state). Note:- It helps improve performance by avoiding unnecessary re-renders. 🧠 Real-Life Example: Imagine you have a digital clock app that shows: • Current Time • User’s Name If your name doesn’t change but the time updates every second, React re-renders everything — including your name — again and again. That’s wasteful! 😅 Now, if your Name component is a Pure Component, React will check: > “Has the name changed?” If No, it won’t re-render that part — saving time and improving performance. 💻 Example Code: import React, { PureComponent } from 'react'; class Name extends PureComponent { render() { console.log("Rendering Name..."); return <h2>Hello, {this.props.name}</h2>; } } class Clock extends React.Component { state = { time: new Date().toLocaleTimeString() }; componentDidMount() { setInterval(() => { this.setState({ time: new Date().toLocaleTimeString() }); }, 1000); } render() { return ( <div> <Name name="Amit" /> <p>Time: {this.state.time}</p> </div> ); } } 🧩 In this example, even though the time changes every second, `<Name />` won’t re-render again and again — because it’s a Pure Component and the `name` prop never changes. 🚀 In short: ✅ React.PureComponent = React.Component + automatic “shouldComponentUpdate” check ✅ Improves performance ✅ Ideal for components that depend only on props and don’t change often #ReactJS #WebDevelopment #Frontend #JavaScript #Coding #LearnReact #PureComponent

Ever see a React list that just won't re-render correctly? The culprit might be simpler than you think. I once spent hours debugging a list where items kept the wrong state after being reordered. Turns out, I was using the classic anti-pattern: `key={index}`. 🤦♂️ While it seems harmless, an item's index isn't a stable identifier. React uses the `key` prop to track identity across renders. When the order changes, the index changes, and React can get confused, leading to weird state bugs. 🐛 The fix is always using a 𝐬𝐭𝐚𝐛𝐥𝐞, 𝐮𝐧𝐢𝐪𝐮𝐞 𝐢𝐝𝐞𝐧𝐭𝐢𝐟𝐢𝐞𝐫 from your data itself, like `item.id`. This gives React a reliable way to know which item is which, no matter its position. 💡 Always reach for a stable ID for your keys. It’s a small detail that prevents huge headaches. Have you struggled with this before? #ReactJS #FrontendDevelopment #DeveloperTips

💡 Server Actions in Next.js 14 — Explained Next.js 14 introduces one of the most exciting updates yet — Server Actions. These are special functions that let you run server-side logic directly from your React components, without needing a traditional API route. Here’s why this matters 👇 ⚙️ 1. No more separate API routes You can now call server code straight from your components. This reduces complexity and improves developer productivity. ⚡ 2. Built-in security and type safety Server Actions automatically run on the server — never exposed to the client — so your environment variables and secrets stay protected. 🚀 3. Faster and more efficient apps By skipping network calls and using React’s server components, your app becomes significantly faster and lighter. 🧠 Example use case: Form submissions, database operations, or AI API calls — all can be handled directly via Server Actions. Next.js continues to blur the line between backend and frontend — making full-stack development simpler than ever. 👉 Have you tried Server Actions in your Next.js project yet? What’s your experience? #Nextjs #React #WebDevelopment #FullStack #Nodejs #JavaScript #Nextjs14 #AI #Automation

React 19 introduces useActionState — and it's a game changer for form handling. For years, we handled form submissions like this: useState for result useState for loading onSubmit manually handled try/catch for errors Extra logic for API or server calls Too much boilerplate for a simple form, right? Meet useActionState It combines state + loading + async submit + error handling — all in one hook. const [state, formAction, isPending] = useActionState(async (prevState, formData) => { const email = formData.get("email"); if (!email.includes("@")) { return { error: "Invalid Email" }; } return { success: true, message: "Email accepted" }; }, {}); <form action={formAction}> <input name="email" /> <button disabled={isPending}> {isPending ? "Submitting..." : "Submit"} </button> {state?.error && <p>{state.error}</p>} </form> Why this is exciting? 1. No more manual useState for loading/error 2. Native <form action> support 3. Perfectly aligned with Next.js 14 Server Actions 4. Cleaner, predictable, future-ready React code React is moving toward server-first, zero-boilerplate development — and useActionState is a big step forward. Would you like me to share a full real-world login example next? (With toast, validation & server-side action)