How to Fix CORS Error in Your API

🚀 Node.js Tip You Probably Haven’t Seen in Production Yet Many devs still talk about fetch() or ESM support, but one of the biggest hidden gems in Node.js v20+ is the experimental Permission Model. 🔐 What is it? It lets you control exactly what your Node process can access — like files, child processes, or worker threads. You can now “sandbox” your app from the inside. Example use case: You can restrict access to specific directories or APIs using flags such as: --allow-fs-read --allow-fs-write --allow-child-process And inside your code, you can check permissions like this: process.permission.has('fs.write', '/tmp/') If the permission isn’t granted, you can block that action safely. ✨ Why this matters - Increases runtime security - Prevents malicious or accidental file writes - Great for multi-tenant apps or plugin-based systems - Reduces attack surface in production ⚙️ How to try it 1️⃣ Upgrade to Node 20 or later 2️⃣ Run your app with: node --experimental-permission --allow-fs-read=./data index.js 3️⃣ Use process.permission.has(...) to check access in your code 💡 It’s still experimental, but this is the direction Node.js is heading — towards safer, permission-aware environments. Have you tried the Permission Model yet? What’s your take on it? #NodeJS #JavaScript #BackendDevelopment #WebSecurity

🧠 If you're a front end dev and don’t fully get JSON yet… you’re flying blind. Here’s why JSON isn’t just data, it’s the backbone of your front end. It’s how your app talks to APIs, stores state, configures features, and passes info everywhere. JSON (JavaScript Object Notation) is universal, human-readable, and language-agnostic. But it’s also stricter than it looks. -No comments -No trailing commas -No functions -Duplicate keys? Undefined behaviour -Dates? Just plain strings -Parse errors? App crash 🧩 In JavaScript, we use: JSON.parse() // from string → object   JSON.stringify() // from object → string But you must be careful: ✅ Always wrap response.json() in try/catch ✅ Validate data (with JSON Schema or Zod) ✅ Align JSON contracts early with your backend ✅ Post-process dates or special types after parsing Why does it matter? Because strong JSON skills help you: -Decode API payloads confidently -Shape state & configs with clarity -Debug faster and write safer front end code 🚀 Want to dive deeper into front end best practices? 👉https://lnkd.in/gP7p5U8i #frontenddevelopment #webdevelopment #javascript #json #apidevelopment 

🚀 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

✅ Day 141 of #200DaysOfTechTalk 🎯 Today's Topic: Controller Functions in Express.js When you’re building APIs with Express.js, controller functions are what keep your code clean, organized, and easy to manage. Let’s break it down 👇 💡 What’s a Controller Function? A controller function is simply a function that handles what happens when someone hits an API route. It decides what to do with the request and what to send back as a response. Think of it like this: The route tells your app where to go, and the controller tells it what to do once it gets there. ⚙️ Basic Example: // controller/userController.js const getUserData = (req, res) => { const userData = { name: 'John Doe', age: 30 }; res.json(userData); }; module.exports = { getUserData }; // routes/userRoutes.js const express = require('express'); const { getUserData } = require('../controller/userController'); const router = express.Router(); router.get('/users', getUserData); module.exports = router; ✅ Now your routes file only handles the path — and your controller handles the logic. 🚀 Why Use Controller Functions? 1. Cleaner Code – Routes stay simple and readable. 2. Easy to Maintain – Logic is separated, so you can update features without breaking everything. 3. Reusable – You can use the same controller in multiple routes. 4. Easy to Test – Testing becomes much simpler since your logic isn’t tangled in route definitions. 🔥 In Short: 🔹 Routes = Define where things happen. 🔹 Controllers = Define what happens there. 🔹 Keep them separate — your future self (and your team) will thank you. 💭 Question for you: Do you separate your route logic into controllers, or do you keep everything in one file? 👇 Drop your approach — I’d love to hear how you organize your backend code. #ExpressJS #NodeJS #BackendDevelopment #JavaScript #WebDevelopment #FullStackDev #CleanCode #BuildInPublic #200DaysOfTechTalk

Tired of spinning up a whole fetch() request just to check if your API endpoint even breathes? Time to appreciate the unsung hero: curl. If you write JavaScript, you’re basically in a long-term relationship with APIs. curl is the tiny command-line powerhouse that lets you poke, prod, and interrogate your endpoints before you write a single line of JS. Think of it like Postman, stripped down and caffeinated, living inside your terminal. It’s my go-to “is this thing actually alive?” tool. Before pointing fingers at axios configs or async chaos, curl helps you confirm whether the endpoint itself is behaving or if you’ve just angered the JavaScript gods again. Why devs love curl: • Instant API checks: curl http://localhost:3000/api/users • See raw headers (perfect for CORS meltdowns): curl -i https://lnkd.in/dMX8-Vsd • Fire off POST requests without building UI or JS: curl -X POST -H "Content-Type: application/json" -d '{"username":"dev","build":"lego_millennium_falcon"}' http://localhost:3000/api/submit curl won’t replace fetch() or axios — it’s what you use to prove the problem isn’t your code. It saves time, isolates issues, and honestly makes you feel like a backend wizard. Curious: what’s your quick-test weapon of choice? curl? Postman? Thunder Client? Something more chaotic? #JavaScript #API #WebDevelopment #NodeJS #curl #DeveloperTools #Programming #Tech

Your entire source code can be exposed in production because of one file you probably ignored. I'm talking about .js.map files. You know those random .js and .js.map files that appear after running npm run build? I always saw them sitting there in the dist folder. Never questioned it. Never opened them. Then one day, my app broke in production. Console error said: "Error in index.abc123.js:12764" Line 12764 of a minified file. Great. Super helpful. Here's what I didn't understand: when you build your app, all your clean React components and readable JavaScript gets crushed into one ugly minified file. No spaces, no variable names you recognize, just random letters and numbers squeezed together. The browser loves it because it's fast. You hate it because you can't read it. That's the .js file. That's what actually runs in production. The .js.map file is basically a translator. It maps that ugly minified code back to your original source files. So when something breaks, your browser DevTools can show you "App.jsx line 45" instead of "index.abc123.js:12764." Without it, debugging production is like trying to read a book where every word has been replaced with random symbols. Here's the catch though: you don't want .js.map files in production. They expose your entire source code to anyone who opens DevTools. Anyone can see how you built everything. Keep them in development. Delete them before deploying. Once I understood this, debugging became way less painful. Turns out ignoring build files just makes your life harder later. #anchors

Still writing all your logic inside your React components? I’ve been there, and it gets messy fast. My "aha" moment came when a component hit 400 lines. It was a tangled mess of `useState` and `useEffect` hooks for fetching data, handling form state, and managing a timer. The real problem? It was impossible to test or reuse any of it. 🧠 The solution was simple: custom hooks. By extracting logic into functions like `useUserData()` or `useFormInput()`, my components became lean, readable, and focused only on the 𝐕𝐈𝐄𝐖. It’s a pattern that feels like a superpower for clean code. ⚡️ If you’re repeating stateful logic, extract it. Your future self will thank you. What small change made a huge impact in your workflow? #ReactJS #FrontendDevelopment #DeveloperTips

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

LLM dev tools keep steering straight into React. System prompts hardwire it. Generated code defaults to it. The result? A feedback loop. Tools crank out React, models get trained on more React, and newcomers inherit the bias. What’s changing: React isn’t just a framework anymore. It’s sliding into invisible infrastructure. That shift sidelines native platform features and chokes off room for alternatives. https://lnkd.in/diDDf6j7 --- Enjoyed this? Sign up 👉 https://faun.dev/join

Error Handling in Async/Await (try...catch in JavaScript) When using Async/Await, handling errors properly is just as important as handling data. That’s where the try...catch block shines It helps you catch and manage errors without crashing your app. Definition: try — contains the code that may throw an error. catch — handles the error gracefully when something goes wrong. Example: function fetchData(success) { return new Promise((resolve, reject) => { setTimeout(() => { if (success) resolve("✅ Data fetched successfully"); else reject("❌ Failed to fetch data"); }, 1000); }); } async function getData() { try { console.log("Fetching data..."); const result = await fetchData(false); // change to true to test success console.log(result); } catch (error) { console.error("Error caught:", error); } finally { console.log("Operation completed ✅"); } } getData(); Output (if failed): Fetching data... Error caught: ❌ Failed to fetch data Operation completed ✅ ⚙️ Why it’s useful: ✅ Prevents app crashes ✅ Keeps async code clean ✅ Helps in debugging network/API issues ✅ Works beautifully with multiple awaits 🔖 #JavaScript #AsyncAwait #ErrorHandling #TryCatch #WebDevelopment #Frontend #CodingTips #AsyncProgramming #JSConcepts #100DaysOfCode #LearnsJS #DeveloperJourney #WebDevCommunity