diff --git a/absolute-beginners/full-stack/career/freelancing.mdx b/absolute-beginners/full-stack/career/freelancing.mdx
index e345ed2..bebc707 100644
--- a/absolute-beginners/full-stack/career/freelancing.mdx
+++ b/absolute-beginners/full-stack/career/freelancing.mdx
@@ -1 +1,69 @@
-
\ No newline at end of file
+---
+title: "Starting Your Freelance Career"
+sidebar_label: "6. Freelancing"
+sidebar_position: 6
+description: "A guide to finding clients, pricing your work, and managing full-stack projects independently."
+tags: ["freelancing", "career", "full-stack"]
+keywords: ["freelancing", "client acquisition", "pricing strategies", "project management", "scaling a freelance business"]
+---
+
+Freelancing allows you to work from anywhere in the world—whether you are in Mandsaur or Mumbai. But to succeed, you must move beyond the "per hour" mindset and start delivering "Value."
+
+## 1. Identifying Your "Niche"
+
+Don't try to be a "General Web Developer." The market is crowded. "A Master" specializes in a specific high-value area.
+
+* **Bad Niche:** "I build websites."
+* **Good Niche:** "I build automated management systems for small banks (PACS)."
+* **Good Niche:** "I build custom educational platforms for coaching institutes."
+
+By specializing, you become the **expert** instead of just another worker.
+
+## 2. Finding Your First Clients
+
+You don't always need a fancy website to start. Use your existing network first.
+
+1. **The "Local" Strategy:** Look around your city. Does a local business need a digital service portal like "Ajay Online"? Offer to build it.
+2. **The Open-Source Strategy:** Use **CodeHarborHub**. When people see your high-quality tutorials and code, they will naturally reach out to ask if you can build something similar for them.
+3. **Freelance Platforms:** Use sites like **Upwork**, **Fiverr**, or **Toptal**.
+ * *Master Tip:* Start with small projects to build your "Rating," then quickly move to fixed-price high-value contracts.
+
+## 3. Pricing Your Mastery
+
+How much should you charge?
+
+| Pricing Model | When to Use It |
+| :--- | :--- |
+| **Hourly Rate** | For maintenance work or vague projects where the scope might change. |
+| **Fixed Project Price** | For clearly defined projects (e.g., "Build a landing page"). |
+| **Value-Based** | Based on how much money the client will make or save. (e.g., "This automation software will save you 10 hours a week, so it costs ₹X"). |
+
+**Master Rule:** Never compete on being the "cheapest." Compete on being the **most reliable**.
+
+## 4. Managing the Project (The "Master" Workflow)
+
+To prevent "Scope Creep" (when a client keeps asking for "just one more thing"), follow this process:
+
+1. **Discovery:** Understand their business problem.
+2. **Proposal & Contract:** Write down exactly what you will build and **what you won't build**.
+3. **Milestones:** Break the project into phases (e.g., UI Design, Backend API, Deployment). Get paid a percentage at each phase.
+4. **Handoff:** Provide documentation and a 30-day "bug-fix" guarantee.
+
+## 5. Scaling: From Freelancer to Agency
+
+Once you have too many clients, you have reached the "Master" bottleneck.
+* **Outsource:** Hire a junior developer from the CodeHarborHub community to handle the basic CSS while you focus on the System Architecture.
+* **Productize:** Can you turn a custom solution you built into a "Software as a Service" (SaaS) that many people can pay for?
+
+## Practice: Your Freelance "Pitch"
+
+Write down a 3-sentence pitch for a client.
+* **The Hook:** What problem do they have?
+* **The Solution:** How does your Full-Stack skill fix it?
+* **The Proof:** Mention CodeHarborHub or a previous project.
+
+*Example:* "I help rural businesses digitize their manual records using secure, custom cloud software. I recently built a bank automation system in MP that reduced paperwork by 50%. I’d love to see if I can do the same for your business."
+
+:::info The Legal Side
+As a freelancer, you are a business. Keep your receipts, pay your taxes, and always use a contract. A Master protects their time and their legal standing!
+:::
\ No newline at end of file
diff --git a/absolute-beginners/full-stack/career/github-profile.mdx b/absolute-beginners/full-stack/career/github-profile.mdx
index e345ed2..0ee788f 100644
--- a/absolute-beginners/full-stack/career/github-profile.mdx
+++ b/absolute-beginners/full-stack/career/github-profile.mdx
@@ -1 +1,70 @@
-
\ No newline at end of file
+---
+title: "Optimizing Your GitHub Profile"
+sidebar_label: "4. GitHub Profile"
+sidebar_position: 4
+description: "How to turn your GitHub profile into a powerful tool for landing developer roles."
+tags: ["GitHub", "developer portfolio", "open source", "full-stack developer", "career"]
+keywords: ["GitHub profile optimization", "GitHub README for developers", "GitHub pinned repositories", "GitHub contribution graph", "open source contributions", "GitHub best practices for developers"]
+---
+
+In the tech world, your GitHub "green squares" are a sign of your passion and discipline. But a great profile is more than just a high contribution count—it's about clarity, documentation, and professionalism.
+
+:::info
+Don't worry about having a "perfect" GitHub profile. Recruiters understand that students are learning. The key is to show **progress** and **potential**. Even if you have only 3 projects, make sure they are well-documented and polished!
+:::
+
+## 1. The "Readme" Revolution (Profile Bio)
+
+GitHub allows you to create a special repository with the same name as your username (e.g., `ajay-dhangar/ajay-dhangar`). The `README.md` in this repo becomes your profile landing page.
+
+**What to include in your Profile README:**
+* **A Professional Intro:** "Full-Stack Developer | Founder of CodeHarborHub | Building Open-Source Education."
+* **Tech Stack Badges:** Use visual icons for your skills (React, Node, AWS, Docker).
+* **Live Stats:** Use tools like `github-readme-stats` to show off your top languages and total stars.
+* **Current Focus:** "Currently deep-diving into Agentic AI and Cloud Architecture."
+
+## 2. Pinning Your "Masterpieces"
+
+Don't let your best work get buried. GitHub allows you to **Pin** up to 6 repositories.
+* **Pin 1:** Your most complex Full-Stack project (e.g., CodeHarborHub).
+* **Pin 2:** A specialized tool or library you built.
+* **Pin 3:** A project that shows off your DevOps/Cloud skills (e.g., an automated deployment template).
+* **The Rule:** Every pinned project **MUST** have a description and a "Topic" tag (like #javascript, #aws).
+
+## 3. The Perfect Repository README
+
+A recruiter will click on your projects. If they see a blank page, they will leave. A "Master" project README follows this structure:
+
+| Section | What it explains |
+| :--- | :--- |
+| **Title & Demo** | What is the project? (Include a link to the live site). |
+| **Features** | A bulleted list of what the app actually does. |
+| **Tech Stack** | Why did you choose these specific tools? |
+| **System Architecture** | A diagram showing how the Frontend, API, and DB connect. |
+| **Setup Guide** | Steps to run the project locally (e.g., `npm install`, `npm start`). |
+
+## 4. Code Quality & Commits
+
+"A Master" doesn't just push code once a week with a message like `"update."`
+* **Commit Messages:** Use **Conventional Commits**.
+ * *Good:* `feat: add user authentication with JWT`
+ * *Bad:* `fixed things`
+* **Branching:** Use branches like `feature/login-page` instead of pushing everything to `main`.
+* **Clean Code:** Ensure your code is formatted (Prettier) and commented where necessary.
+
+## 5. Contributing to Open Source
+
+Since you are the founder of **CodeHarborHub**, you already know the power of Open Source.
+* **Contribute back:** Fix a bug in a library you use (like a small CSS fix in a React UI kit).
+* **Maintainer Mindset:** Show that you can handle **Pull Requests (PRs)** and **Issues**. This proves you can work in a professional team environment.
+
+## Practice: The "GitHub Cleanup"
+
+Do this today to upgrade your profile:
+1. **Delete/Private** the "Tutorial" repos (e.g., `my-first-html-page`).
+2. **Add a License:** Every repo should have an MIT License (it shows you understand legalities).
+3. **Check your 404s:** Ensure all "Live Demo" links in your descriptions are still working.
+
+:::info The "Social" GitHub
+Follow other developers, "Star" repositories you genuinely find useful, and participate in GitHub Discussions. This makes your profile feel like it belongs to a real, active member of the global engineering community!
+:::
\ No newline at end of file
diff --git a/absolute-beginners/full-stack/career/interview-prep.mdx b/absolute-beginners/full-stack/career/interview-prep.mdx
index e345ed2..e481f19 100644
--- a/absolute-beginners/full-stack/career/interview-prep.mdx
+++ b/absolute-beginners/full-stack/career/interview-prep.mdx
@@ -1 +1,68 @@
-
\ No newline at end of file
+---
+title: "Cracking the Full-Stack Interview"
+sidebar_label: "5. Interview Prep"
+sidebar_position: 5
+description: "A comprehensive guide to mastering behavioral, technical, and system design interviews."
+tags: ["interview preparation", "coding interviews", "system design interviews", "behavioral interviews", "full-stack developer interview"]
+keywords: ["full-stack interview preparation", "coding challenge strategies", "system design interview tips", "behavioral interview techniques", "mock interviews for developers"]
+---
+
+The interview process for a Full-Stack role usually happens in three stages. To pass, you must demonstrate a balance of "Computer Science Fundamentals" and "Real-World Engineering."
+
+## 1. The Coding Challenge (DS & Algo)
+
+Most companies start with a Data Structures and Algorithms (DSA) test.
+* **The Master's Strategy:** Don't just memorize LeetCode. Focus on **Patterns**.
+* **Key Patterns to Know:** Two Pointers, Sliding Window, Recursion, and Breadth-First Search (BFS).
+* **Language Choice:** Use the language you are most comfortable with (JavaScript or Java/C++).
+
+## 2. The Technical Deep Dive (The "How" and "Why")
+
+This is where they test your Full-Stack knowledge. Expect questions like:
+* **Frontend:** "What is the Virtual DOM in React?" or "How does UseEffect handle the component lifecycle?"
+* **Backend:** "Explain the difference between a PUT and a PATCH request."
+* **Database:** "What is an Index, and how does it speed up a query?"
+
+**The Master's Answer Technique:**
+1. **Define the concept.**
+2. **Explain the benefit.**
+3. **Give a real-world example from CodeHarborHub.**
+ * *Example:* "I used Indexes in the CodeHarborHub tutorial database to reduce search latency for students by 60%."
+
+## 3. The System Design Round
+
+For intermediate or "Master" level roles, you will be asked to design a system on a whiteboard.
+* **Common Question:** "Design a URL Shortener" or "Design a Notification System."
+
+**Follow the "Master" Blueprint:**
+1. **Requirements:** Ask questions! (How many users? Do links expire?)
+2. **High-Level Design:** Draw the flow (User -> Load Balancer -> Web Server -> DB).
+3. **Deep Dive:** Discuss Caching (Redis), Database Scaling (Sharding), and Bottlenecks.
+
+## 4. The Behavioral Round (The "STAR" Method)
+
+Culture fit is just as important as code. Use the **STAR** method for questions like "Tell me about a time you disagreed with a teammate."
+
+* **S**ituation: Set the scene.
+* **T**ask: What was the goal?
+* **A**ction: What did **you** do specifically? (Talk about leadership/mentorship).
+* **R**esult: What was the positive outcome? (Use numbers!).
+
+## 5. Questions to Ask the Interviewer
+
+At the end, "A Master" always asks smart questions to show they care about the engineering culture:
+1. "What does the CI/CD pipeline look like here? How often do you deploy to production?"
+2. "How does the team handle technical debt vs. building new features?"
+3. "What is the biggest architectural challenge the team is currently facing?"
+
+## Practice: The Mock Interview
+
+Before the real day, do a 30-minute mock session with a friend or use an AI tool:
+1. **Record yourself:** Are you speaking clearly?
+2. **Think out loud:** In a coding interview, **silence is the enemy**. Explain your logic while you type.
+3. **Handle Failure:** If you don't know an answer, don't guess. Say: *"I haven't used that specific tool yet, but based on my experience with [Related Tool], I would assume it works by..."*
+
+
+:::success The "Master" Mindset
+Remember, the interview is not just about getting the right answer. It's about showing your thought process, your communication skills, and your ability to learn. Even if you don't know something, how you handle that moment can turn a potential failure into a success.
+:::
\ No newline at end of file
diff --git a/absolute-beginners/full-stack/career/linkedin.mdx b/absolute-beginners/full-stack/career/linkedin.mdx
index e345ed2..b96179e 100644
--- a/absolute-beginners/full-stack/career/linkedin.mdx
+++ b/absolute-beginners/full-stack/career/linkedin.mdx
@@ -1 +1,67 @@
-
\ No newline at end of file
+---
+title: "Optimizing LinkedIn for Developers"
+sidebar_label: "3. LinkedIn Strategy"
+sidebar_position: 3
+description: "How to leverage LinkedIn to build a personal brand, network with engineers, and attract recruiters."
+tags: ["LinkedIn", "personal branding", "networking", "job search", "full-stack developer"]
+keywords: ["LinkedIn profile optimization", "LinkedIn headline for developers", "LinkedIn summary for developers", "LinkedIn experience section", "LinkedIn content strategy", "LinkedIn checklist for developers"]
+---
+
+If your LinkedIn profile is empty, you are invisible to 90% of recruiters. To be "A Master," you must treat your profile like a product: it needs to be optimized, updated, and user-friendly.
+
+## 1. The "A Master" Profile Essentials
+
+### The Visuals
+* **Profile Picture:** A clear, high-resolution headshot. You don't need a suit, but you do need good lighting and a smile.
+* **Banner Image:** Don't leave it blank! Use an image related to CodeHarborHub, a clean shot of your code editor, or a professional graphic showing your tech stack (React, Node, AWS).
+
+### The Headline
+Don't just put "Student." Use keywords that recruiters search for.
+* **Noob:** Student at XYZ College.
+* **Master:** Full-Stack Developer | Founder of CodeHarborHub | React, Node.js, AWS | B.Tech Computer Science.
+
+## 2. The "About" Section: Your Story
+This is your elevator pitch. Instead of a boring summary, talk about your mission.
+
+> "I am a Full-Stack Developer on a mission to make technical education accessible. As the Founder of **CodeHarborHub**, I’ve built an open-source ecosystem that helps students transition from code to cloud. I specialize in building scalable systems with **React** and **Node.js**, and I’m passionate about **DevOps** and **System Design**."
+
+## 3. Showcasing Experience & Projects
+
+### Experience
+Even if you haven't had a "Job," your work on CodeHarborHub **is** experience.
+* **Title:** Founder & Lead Developer
+* **Company:** CodeHarborHub (Open Source)
+* **Bullet Points:**
+ * "Designed and deployed a full-stack educational platform using **Next.js** and **PostgreSQL**."
+ * "Managed a community of contributors, performing code reviews and maintaining documentation."
+ * "Automated deployment pipelines using **GitHub Actions**, achieving 100% uptime."
+
+### Featured Section
+Pin your best work here:
+1. A link to your **Portfolio Site**.
+2. Your most popular **CodeHarborHub** repository.
+3. A post where you explained a complex concept (like Docker or RDS).
+
+## 4. The "Master" Content Strategy
+LinkedIn is an algorithm. To get noticed by "Big Tech" recruiters, you need to be active.
+
+* **Share the Journey:** Post about a bug you fixed today or a new feature you added to CodeHarborHub.
+* **Teach Others:** Write a "Mini-Tutorial." (e.g., "3 reasons why I chose PostgreSQL over MongoDB for my latest project").
+* **Engage:** Don't just post; comment on posts by Senior Engineers at companies you like. Ask smart questions about their architecture.
+
+## 5. LinkedIn Checklist for Success
+
+* [ ] **Custom URL:** Change your URL to `linkedin.com/in/ajay-dhangar` instead of random numbers.
+* [ ] **Skills Section:** Add at least 20 skills. Ask friends from CodeHarborHub to **endorse** you for React and Node.js.
+* [ ] **Open to Work:** Set your "Open to Work" preferences to "Full-Stack Developer" and "Backend Engineer" roles.
+* [ ] **Recommendations:** Ask a fellow contributor or a mentor to write a 2-line recommendation about your technical skills.
+
+## Practice: The Connection Request
+
+When you connect with a Senior Engineer, **never** send a blank request. Send a "Master" note:
+
+> "Hi [Name], I’m Ajay, a Full-Stack dev and founder of CodeHarborHub. I saw your post about [Topic] and loved your insight on [Specific Detail]. I’m currently deep-diving into AWS architecture and would love to follow your updates!"
+
+:::tip The "Founder" Advantage
+Being a founder of an open-source project is a huge advantage. It shows initiative, leadership, and real-world experience. Make sure to highlight this in your LinkedIn headline and summary. Recruiters love self-starters who can build and maintain a project from scratch.
+:::
\ No newline at end of file
diff --git a/absolute-beginners/full-stack/career/portfolio.mdx b/absolute-beginners/full-stack/career/portfolio.mdx
index e345ed2..05a77bf 100644
--- a/absolute-beginners/full-stack/career/portfolio.mdx
+++ b/absolute-beginners/full-stack/career/portfolio.mdx
@@ -1 +1,69 @@
-
\ No newline at end of file
+---
+title: "Building a High-Impact Portfolio"
+sidebar_label: "2. The Portfolio"
+sidebar_position: 2
+description: "How to build a high-impact portfolio site that showcases your full-stack and cloud expertise."
+---
+
+Your portfolio is more than a list of links; it is a live demonstration of your skills. If you say you know **AWS**, but your portfolio is hosted on a basic drag-and-drop builder, it doesn't look like "A Master's" work.
+
+## 1. The Tech Stack of Your Portfolio
+
+Since you are a Full-Stack Master, build your portfolio using the tools you want to be hired for:
+* **Frontend:** Next.js (for SEO and speed) or React.
+* **Styling:** Tailwind CSS (clean, modern, and responsive).
+* **Deployment:** Host it on **AWS (S3 + CloudFront)** or **Vercel**.
+* **Custom Domain:** Use a professional domain like `ajay-master.dev` or `codeharbor-ajay.in`.
+
+## 2. The "Quality over Quantity" Rule
+
+Don't show 20 tiny "noob" projects. Show **3 high-quality systems**. For each project, include:
+
+1. **A Compelling Thumbnail:** A high-quality screenshot or a short GIF of the app in action.
+2. **The Problem:** What issue does this app solve? (e.g., "Students struggle to find structured cloud roadmaps.")
+3. **The Tech Stack:** Use icons for React, Node.js, Docker, etc.
+4. **The "System Architecture" Diagram:** **(Crucial for Masters!)** Show a small diagram of how the data flows from the Frontend to the Database.
+5. **Links:** One button for the **Live Demo** and one for the **GitHub Repo**.
+
+## 3. Structure of the Portfolio Page
+
+### The Hero Section
+Keep it bold. "Full-Stack Developer | Founder of CodeHarborHub | Scaling Ideas into Infrastructure."
+
+### The "Knowledge Base" (Skills)
+Instead of a boring list, group your skills by how they fit into a system.
+* **Building:** React, Next.js, TypeScript.
+* **Powering:** Node.js, PostgreSQL, Redis.
+* **Shipping:** Docker, GitHub Actions, AWS.
+
+### The CodeHarborHub Spotlight
+Since this is your major project, give it its own section.
+* Mention that it's **Open Source**.
+* Highlight the **number of contributors** or **stars**.
+* Talk about the **impact** (how many students have used it).
+
+## 4. The "Master" Feature: The Technical Blog
+
+A Master doesn't just write code; they explain *why* they wrote it.
+Integrating a blog into your portfolio shows:
+1. **Communication Skills:** You can explain complex topics to juniors.
+2. **Deep Knowledge:** Writing a post about *"How I optimized my RDS queries"* proves you actually understand databases.
+
+## 5. Portfolio Checklist
+
+* [ ] **Responsive:** Does it look perfect on a mobile phone?
+* [ ] **Fast:** Run a Google Lighthouse test. Your score should be 90+.
+* [ ] **Contact Form:** Does it actually send you an email? (Use a service like Formspree or an AWS Lambda function).
+* [ ] **Analytics:** Add Google Analytics or Vercel Analytics to see who is visiting (and from which companies!).
+
+## Practice: The "README" Polish
+
+The portfolio is the "Front Door," but the **GitHub README** is the "Engine Room."
+For your top project:
+1. Add a **"Features"** list.
+2. Add a **"Lessons Learned"** section (talk about a bug you fixed).
+3. Add a **"Future Improvements"** section (shows you are thinking about scaling).
+
+:::tip Social Proof
+If you have helped anyone on CodeHarborHub, ask them for a small testimonial. "Ajay's tutorials helped me understand Docker in 10 minutes." Adding 2-3 of these to your portfolio makes you 10x more hireable!
+:::
\ No newline at end of file
diff --git a/absolute-beginners/full-stack/career/resume.mdx b/absolute-beginners/full-stack/career/resume.mdx
index e345ed2..b09eeda 100644
--- a/absolute-beginners/full-stack/career/resume.mdx
+++ b/absolute-beginners/full-stack/career/resume.mdx
@@ -1 +1,66 @@
-
\ No newline at end of file
+---
+title: "Resume Building Guide"
+sidebar_label: "1. The Resume"
+sidebar_position: 1
+description: "How to showcase your full-stack projects and technical skills to land your first developer role."
+tags: ["resume", "career", "job search", "full-stack developer"]
+keywords: ["resume", "CV", "full-stack developer resume", "technical resume", "project descriptions", "skills section", "ATS optimization"]
+---
+
+Think of your resume like a **README.md** for your career. It needs to be clean, easy to scan, and "bug-free" (no typos!). Recruiters look at a resume for about **6 seconds** before deciding to keep it or bin it. You have to make those seconds count.
+
+## 1. The "A Master" Layout
+
+Don't use fancy, colorful templates with "Skill Bars" (e.g., "React: 80%"). Computers (ATS - Applicant Tracking Systems) hate those. Use a clean, single-column layout.
+
+**The Order of Operations:**
+1. **Header:** Name, Phone, Email, Location (City/State), and links to your **GitHub** and **LinkedIn**.
+2. **Summary:** 2 sentences about who you are.
+ * *Example:* "Full-Stack Developer and Founder of CodeHarborHub. Passionate about building scalable educational tools using React, Node.js, and AWS."
+3. **Skills:** Group them by category (Languages, Frontend, Backend, Cloud/Tools).
+4. **Projects:** (This is the most important part if you're a new grad!).
+5. **Education:** B.Tech details, graduation year, and GPA (if 7.0+).
+
+## 2. Formatting Your Skills
+
+Don't just list every word you've ever heard. Categorize them so a recruiter can find what they need in 1 second.
+
+| Category | What to include |
+| :--- | :--- |
+| **Languages** | JavaScript (ES6+), TypeScript, HTML5, CSS3, Java, C++. |
+| **Frontend** | React, Next.js, Redux, Tailwind CSS, Bootstrap. |
+| **Backend** | Node.js, Express, REST APIs, WebSockets. |
+| **Databases** | PostgreSQL (SQL), MongoDB (NoSQL), Redis. |
+| **Cloud/DevOps** | AWS (EC2, S3, RDS), Docker, Git, GitHub Actions (CI/CD). |
+
+## 3. How to Describe Your Projects
+
+Don't just say *"I built a chat app."* Use the **STAR** method (Situation, Task, Action, Result) or the **"X-Y-Z"** formula.
+
+> **Formula:** "Accomplished **X** as measured by **Y**, by doing **Z**."
+
+* **Noob way:** "Made a tutorial site using React."
+* **Master way:** "Architected **CodeHarborHub**, an open-source learning platform, serving **X+ students** by implementing a **React** frontend and a **Node.js** backend deployed on **AWS EC2**."
+
+## 4. The "DevOps" Edge
+
+Since you've been learning Cloud and System Design at CodeHarborHub, you have a massive advantage. **Highlight it!**
+
+Include bullet points like:
+* "Containerized application using **Docker** for consistent development and production environments."
+* "Automated deployment workflows using **GitHub Actions**, reducing manual deploy time by 100%."
+* "Optimized data retrieval speed by 40% by implementing **Redis Caching** for frequently accessed API endpoints."
+
+## 5. Resume Checklist (Before you hit 'Send')
+
+* [ ] **PDF Format:** Never send a `.docx` or `.txt`.
+* [ ] **Hyperlinks Work:** Click your GitHub and Project links. If they lead to a 404, you won't get the job.
+* [ ] **No Fluff:** Remove "Hardworking," "Team player," or "Quick learner." Prove these through your projects instead.
+* [ ] **Keywords:** Does the job description say "PostgreSQL"? Make sure "PostgreSQL" is in your skills list.
+
+## Practice: The "GitHub" Audit
+
+Before you submit your resume, a Master ensures their GitHub looks professional:
+1. **Pinned Repos:** Pin your best 3-4 projects.
+2. **READMEs:** Every pinned project must have a screenshot and a clear "How to Run" section.
+3. **Green Squares:** Try to keep your contribution graph active. It shows you are consistently building!
\ No newline at end of file
diff --git a/absolute-beginners/full-stack/cloud/aws-overview.mdx b/absolute-beginners/full-stack/cloud/aws-overview.mdx
index e345ed2..8492cd4 100644
--- a/absolute-beginners/full-stack/cloud/aws-overview.mdx
+++ b/absolute-beginners/full-stack/cloud/aws-overview.mdx
@@ -1 +1,65 @@
-
\ No newline at end of file
+---
+title: "AWS: The Cloud Giant"
+sidebar_label: "2. AWS Overview"
+sidebar_position: 2
+description: "An introduction to Amazon Web Services and the core services every full-stack developer should know."
+tags: ["aws", "cloud computing", "ec2", "s3", "rds", "lambda"]
+keywords: ["aws", "cloud computing", "ec2", "s3", "rds", "lambda", "regions", "availability zones", "iam", "free tier"]
+---
+
+If the Cloud is a kitchen you rent, **AWS** is a massive industrial kitchen with every tool ever invented. It powers everything from Netflix to NASA. For a beginner, the goal isn't to learn every tool, but to learn how to use the "Stove" and the "Fridge."
+
+## 1. Why AWS?
+
+* **Market Leader:** Most high-paying tech jobs require AWS knowledge.
+* **The Free Tier:** AWS offers a "Free Tier" for 12 months, allowing you to run small servers and databases for $0.
+* **Global Reach:** You can host your CodeHarborHub site in Mumbai, Virginia, or London with one click to keep it fast for local users.
+
+## 2. The "Big 4" Services You Must Know
+
+As a Full-Stack developer, 90% of your work will involve these four services:
+
+### 1. EC2 (Elastic Compute Cloud) - The Server
+Think of this as a **Virtual Computer** in the sky. You choose the RAM, CPU, and OS (usually Ubuntu), and you get full control to install Node.js and run your code.
+
+
+### 2. S3 (Simple Storage Service) - The Hard Drive
+This is where you store **Files**. If your users upload profile pictures or if you have static PDF tutorials, you put them here. It's virtually "infinite" storage.
+
+
+### 3. RDS (Relational Database Service) - The Database
+Instead of installing MongoDB or PostgreSQL on your server (which is hard to manage), AWS manages it for you. They handle backups and security updates automatically.
+
+### 4. Lambda - The "Function" (Serverless)
+This is for "Master" level efficiency. You don't even rent a whole server; you just upload a single function (like "Send Email"), and AWS only runs it (and charges you) when someone calls it.
+
+## 3. Regions and Availability Zones
+
+AWS infrastructure is organized geographically:
+* **Regions:** Physical locations in the world (e.g., `ap-south-1` is Mumbai).
+* **Availability Zones (AZ):** Discrete data centers within a Region.
+* **Master Strategy:** You should host your app in the Region closest to your users. If most CodeHarborHub users are in India, use the Mumbai region!
+
+## 4. The AWS Management Console
+
+This is the web-based "Dashboard" where you manage your services.
+1. **Search Bar:** Your best friend. Type "EC2" or "S3" to find services quickly.
+2. **IAM (Identity and Access Management):** This is where you create "User Accounts" for your team.
+ * **CRITICAL:** Never use your "Root" (main) account for daily work. Create an IAM user with limited permissions to keep your account safe.
+
+## 5. Understanding the Free Tier
+
+AWS has three types of free offers:
+* **12-Months Free:** Includes EC2 and RDS (with limits).
+* **Always Free:** Includes Lambda and some DynamoDB storage.
+* **Short-term Trials:** Specialized services for 30-60 days.
+
+## Practice: The AWS Tour
+
+1. Create an **AWS Free Tier** account (you will need a credit/debit card for verification, but they won't charge you if you stay in the limits).
+2. Search for **"Billing Dashboard"** and set up a **Budget Alert** for $1.00. This ensures you never get a surprise bill.
+3. Navigate to the **S3** console and try creating a "Bucket"—it's like a folder for the whole internet!
+
+:::danger The "API Key" Trap
+If you ever create an AWS Access Key, **NEVER** push it to GitHub. Hackers scan GitHub every second for AWS keys so they can use your account to mine Bitcoin, leaving you with a bill for thousands of dollars! Always use `.env` files and `.gitignore`.
+:::
\ No newline at end of file
diff --git a/absolute-beginners/full-stack/cloud/cloudfront.mdx b/absolute-beginners/full-stack/cloud/cloudfront.mdx
index e345ed2..ff43d2c 100644
--- a/absolute-beginners/full-stack/cloud/cloudfront.mdx
+++ b/absolute-beginners/full-stack/cloud/cloudfront.mdx
@@ -1 +1,65 @@
-
\ No newline at end of file
+---
+title: "AWS CloudFront: The Speed Demon"
+sidebar_label: "6. CloudFront (CDN)"
+sidebar_position: 6
+description: "Learn how to use a Content Delivery Network (CDN) to make your CodeHarborHub site fast globally."
+tags: ["aws", "cloudfront", "cdn", "content delivery network", "edge locations", "caching", "ssl"]
+keywords: ["aws", "cloudfront", "cdn", "content delivery network", "edge locations", "caching", "ssl", "https", "invalidation", "ttl", "performance optimization"]
+---
+
+**CloudFront** is what we call a **CDN** (Content Delivery Network).
+
+Think of it like a **Chain of Convenience Stores**.
+* **The Origin (S3/EC2):** This is the giant main warehouse (factory) where your website is built.
+* **Edge Locations:** These are small local shops in every city.
+Instead of every customer driving to the main warehouse to get milk, you send a truck to all the local shops once. Now, the customer just walks to the corner store!
+
+## 1. How it works (The Magic of Caching)
+
+When a user visits your site for the first time:
+1. They ask CloudFront for `logo.png`.
+2. CloudFront doesn't have it yet, so it goes to your **S3 bucket** to get it.
+3. CloudFront gives the image to the user **AND keeps a copy** for itself in that city.
+4. When the *next* user in that same city asks for the image, CloudFront gives it to them instantly without ever bothering your S3 bucket. This is called **Caching**.
+
+## 2. Why "A Master" uses CloudFront
+
+| Feature | Without CloudFront | With CloudFront |
+| :--- | :--- | :--- |
+| **Speed** | Slow for users far from the server. | Fast for everyone, everywhere. |
+| **Server Load** | Your server has to work for every hit. | Your server "rests" while the CDN works. |
+| **Security** | Your S3 bucket is exposed to the web. | You can hide S3 behind a "CloudFront Shield." |
+| **Cost** | You pay for "Outbound Data" from S3. | CDN data is often cheaper and more efficient. |
+
+## 3. Edge Locations vs. Regions
+
+AWS has about 30+ **Regions** (Large data centers), but they have **450+ Edge Locations**.
+* There are Edge Locations in almost every major city (Mumbai, Delhi, Bangalore, Chennai, etc.).
+* This means your CodeHarborHub tutorials will load in milliseconds, regardless of where your students are.
+
+## 4. Using CloudFront for HTTPS (SSL)
+
+In the modern web, "HTTP" is not enough. You need the green padlock (**HTTPS**).
+* Setting up SSL certificates on a raw Linux server is a headache.
+* **The Master Way:** You connect your domain to CloudFront. CloudFront gives you a free SSL certificate (via AWS Certificate Manager).
+* Now, your site is secure and fast with zero manual server configuration!
+
+## 5. What is "Invalidation"?
+
+The only downside to a CDN is that it's "stubborn." If you change your `styles.css` file, CloudFront might still show the *old* version because it has it saved in its memory.
+
+To fix this, you perform an **Invalidation**. It's like sending a message to all the local shops saying: *"The old milk is expired! Throw it away and come get the fresh batch from the warehouse."*
+
+## Practice: Speed up your S3 Site
+
+1. Open the **CloudFront** console.
+2. Click **Create Distribution**.
+3. For "Origin Domain," select the **S3 Bucket** you created in the last lesson.
+4. Under "Viewer Protocol Policy," select **Redirect HTTP to HTTPS**.
+5. Click **Create**.
+6. Wait about 5 minutes. You will get a `xxxx.cloudfront.net` URL.
+7. Open that URL—your image/site is now being served from a global network!
+
+:::info TTL (Time to Live)
+You can set a **TTL** on your files. A TTL of `86400` means CloudFront will keep your file in its memory for 24 hours before checking the warehouse for a new version. For a static logo, set a high TTL. For a news feed, set a low TTL!
+:::
\ No newline at end of file
diff --git a/absolute-beginners/full-stack/cloud/deployment.mdx b/absolute-beginners/full-stack/cloud/deployment.mdx
index e345ed2..24b9eae 100644
--- a/absolute-beginners/full-stack/cloud/deployment.mdx
+++ b/absolute-beginners/full-stack/cloud/deployment.mdx
@@ -1 +1,97 @@
-
\ No newline at end of file
+---
+title: "Automated Deployment Strategies"
+sidebar_label: "7. Deployment"
+sidebar_position: 7
+description: "Learn how to move code from your CI pipeline to production servers using professional deployment techniques."
+tags: ["deployment", "ci/cd", "github actions", "ssh", "automated deployment"]
+keywords: ["deployment", "ci/cd", "github actions", "ssh", "automated deployment"]
+---
+
+Deployment is the final stage of the CI/CD pipeline. In this lesson, we explore how to ship code reliably and how to handle updates without interrupting your users.
+
+## 1. Manual vs. Automated Deployment
+
+* **Manual:** You SSH into the server, run `git pull`, and restart PM2. This is slow and prone to human error.
+* **Automated:** Your GitHub Action uses a "Deploy Key" to securely connect to your server and run the update script for you.
+
+## 2. Common Deployment Patterns
+
+Depending on your project size, you might choose one of these "Master" strategies:
+
+### A. Recreate (The Basic Way)
+
+The old version is stopped, and the new version is started.
+* **Downside:** There is a few seconds/minutes of downtime.
+* **Best for:** Dev environments or low-traffic internal tools.
+
+### B. Rolling Deployment
+
+You update servers one by one. If you have 3 servers, you update Server 1, then Server 2, then Server 3.
+* **Benefit:** The site stays online because at least two servers are always running.
+* **Best for:** Scaled applications using Load Balancers.
+
+### C. Blue-Green Deployment
+
+You have two identical environments: **Blue** (Live) and **Green** (New Version).
+1. You deploy the code to Green and test it.
+2. You switch the "Traffic Switch" (Load Balancer) from Blue to Green.
+3. If anything goes wrong, you just switch back to Blue instantly.
+
+## 3. Visualizing the Deployment Flow
+
+```mermaid
+graph TD
+ A[Build & Test Passed] --> B{Choose Strategy}
+ B -->|Simple| C[SSH & Script]
+ B -->|Zero-Downtime| D[Blue-Green Switch]
+ C --> E[Restart PM2/Docker]
+ D --> F[Update Load Balancer]
+ E --> G[Production Live]
+ F --> G
+
+```
+
+## 4. Deploying via GitHub Actions (SSH)
+
+The most common way for absolute beginners to automate a VPS (like DigitalOcean) is using an SSH action.
+
+```yaml title=".github/workflows/deploy.yml"
+- name: Deploy to Server
+ uses: appleboy/ssh-action@master
+ with:
+ host: ${{ secrets.SERVER_IP }}
+ username: ${{ secrets.SERVER_USER }}
+ key: ${{ secrets.SSH_PRIVATE_KEY }}
+ script: |
+ cd /home/ajay/codeharbor-api
+ git pull origin main
+ npm install --omit=dev
+ pm2 restart ecosystem.config.js
+
+```
+
+## 5. Database Migrations during Deployment
+
+Deploying code is easy; deploying **data changes** is hard.
+
+* **The Master Rule:** Never delete columns in a deployment. Always add new columns first, then migrate data, then delete old columns in a *future* deployment.
+* **Automation:** Your script should run `npx knex migrate:latest` or `npx prisma migrate deploy` *before* restarting the application.
+
+## 6. Post-Deployment Smoke Tests
+
+A "Master" doesn't just assume the deployment worked. You should add a final step to your pipeline:
+
+1. Wait 10 seconds for the app to start.
+2. Run a `curl` command to your health-check endpoint (`/api/health`).
+3. If it returns `200 OK`, the deployment is a success. If it fails, automatically roll back to the previous version.
+
+## Practice: The "No-Touch" Deploy
+
+1. Set up an SSH key on your server and add the private key to GitHub Secrets.
+2. Create a `deploy.yml` that triggers only when you push to the `main` branch.
+3. Push a small change (like changing a "Hello" message).
+4. Wait for the Action to finish and refresh your website. You should see the update without ever opening your terminal!
+
+:::info Rollbacks
+Always keep the previous version of your code or Docker image tagged. If your smoke test fails, your script should automatically run the `pm2 restart` command for the previous working version.
+:::
\ No newline at end of file
diff --git a/absolute-beginners/full-stack/cloud/ec2.mdx b/absolute-beginners/full-stack/cloud/ec2.mdx
index e345ed2..74f9e6e 100644
--- a/absolute-beginners/full-stack/cloud/ec2.mdx
+++ b/absolute-beginners/full-stack/cloud/ec2.mdx
@@ -1 +1,84 @@
-
\ No newline at end of file
+---
+title: "AWS EC2: Your Computer in the Sky"
+sidebar_label: "3. EC2 (Virtual Servers)"
+sidebar_position: 3
+description: "A human-friendly guide to launching and managing your first virtual server on AWS."
+tags: ["aws", "ec2", "virtual servers", "cloud hosting", "linux", "ssh"]
+keywords: ["aws", "ec2", "virtual servers", "cloud hosting", "linux", "ssh", "key pairs", "security groups", "instance types", "free tier"]
+---
+
+**EC2** stands for **Elastic Compute Cloud**.
+* **Elastic:** You can make it bigger or smaller (more RAM/CPU) whenever you want.
+* **Compute:** It's a computer that does "math" and runs code.
+* **Cloud:** It lives in an Amazon data center, not under your desk.
+
+Think of it like renting a "Virtual Laptop" that lives in a giant warehouse. You connect to it using your keyboard, but the "brain" is miles away.
+
+:::info EC2 in Simple Terms
+EC2 is like renting a computer in the sky. You can install anything on it (Node.js, databases, games) and it runs 24/7. You can log in from anywhere and control it like it's your own machine.
+:::
+
+## 1. Why not just use "Free Hosting" (like Vercel)?
+
+Services like Vercel or Netlify are amazing, but they are like **hotels**: everything is set up for you, but you can't change the wallpaper or rebuild the kitchen.
+
+**EC2 is like renting an empty apartment.**
+* You get the keys.
+* You decide which OS to install (usually Linux).
+* You decide where the database goes.
+* **You have 100% control.** This is where "A Master" learns how servers *actually* work.
+
+## 2. Choosing your "Instance Type" (The Hardware)
+
+When you launch an EC2, AWS asks what "Instance Type" you want. This is just a fancy way of asking, *"How powerful do you want this computer to be?"*
+
+* **t2.micro / t3.micro:** The "Free Tier" special. It’s not a beast, but it’s perfect for hosting your first CodeHarborHub portfolio or a small Node.js API.
+* **c6g.large:** A high-power machine for heavy math. (Expensive!)
+* **p4d.24xlarge:** A monster machine with 8 GPUs for training AI. (Costs thousands of dollars!)
+
+:::tip
+Always stick to **t2.micro** (or t3.micro) while learning so you don't get charged.
+:::
+
+## 3. The "Key Pair" (Your Digital Key)
+
+Since your EC2 instance is in a data center, you can't walk up to it and type a password. Instead, AWS gives you a **Key Pair** (a `.pem` or `.ppk` file).
+
+* This file is your **ONLY** way into the server.
+* If you lose it, you are locked out forever.
+* If you share it, anyone can delete your work.
+* **Treat this file like your house keys!**
+
+## 4. Security Groups (The Bouncer)
+
+Imagine your server is a club. A **Security Group** is the bouncer standing at the door with a list. By default, **everyone is blocked.**
+
+You have to tell the bouncer:
+* "Allow **SSH** (Port 22) so I can log in."
+* "Allow **HTTP** (Port 80) so the world can see my website."
+
+## 5. How to "Talk" to your EC2
+
+Once your server is running, you use a tool called **SSH** (Secure Shell) to talk to it. You type commands on your laptop, and they execute on the server in the cloud.
+
+```bash
+# How a Master logs in
+ssh -i "my-key-pair.pem" ubuntu@your-ec2-ip-address
+```
+
+Once you're in, the screen will change, and you'll be staring at a Linux terminal. From here, you can install Node.js, Git, and start your CodeHarborHub project!
+
+## Practice: The Launch Checklist
+
+If you're feeling brave and want to launch your first instance, follow these "Noob-friendly" steps in the AWS Console:
+
+1. **Name:** Give it a cool name like `CodeHarbor-Server-01`.
+2. **OS:** Choose **Ubuntu** (it has the most tutorials online).
+3. **Instance Type:** Select **t2.micro** (Look for the "Free tier eligible" label).
+4. **Key Pair:** Create a new one and download it immediately.
+5. **Network:** Tick the boxes for "Allow HTTP traffic from the internet."
+6. **Launch:** Click the big orange button!
+
+:::warning STOP your instances
+The Cloud is like a taxi—the meter is always running. Even if you aren't using the server, if it is "Running," it counts toward your free hours. If you are done for the day, **Stop** or **Terminate** the instance to keep your bill at $0.
+:::
\ No newline at end of file
diff --git a/absolute-beginners/full-stack/cloud/intro.mdx b/absolute-beginners/full-stack/cloud/intro.mdx
index e345ed2..369fa1e 100644
--- a/absolute-beginners/full-stack/cloud/intro.mdx
+++ b/absolute-beginners/full-stack/cloud/intro.mdx
@@ -1 +1,69 @@
-
\ No newline at end of file
+---
+title: "Cloud Computing for Beginners"
+sidebar_label: "1. What is the Cloud?"
+sidebar_position: 1
+description: "A beginner-friendly introduction to cloud computing and why it's essential for modern full-stack developers."
+---
+
+If you are a "noob" coder, you might think: *"Why can't I just leave my laptop on and let people access my website through my IP address?"*
+
+Technically, you could! But what if your cat trips over the power cord? Or your Wi-Fi goes down? Or 1,000 people visit at once and your laptop starts smoking? **The Cloud** solves all of this.
+
+:::info The Cloud Explained in Simple Terms
+The "Cloud" is just a fancy word for "Other People's Computers." When you host your website on the cloud, it means your code is running on powerful servers owned by companies like Amazon, Google, or DigitalOcean. You can control these servers from anywhere in the world, and they are designed to be super reliable and fast.
+:::
+
+## 1. What exactly is "The Cloud"?
+
+In simple terms, Cloud Computing is the **on-demand delivery** of computing power, database storage, and applications over the internet.
+
+Imagine you want to start a pizza business:
+* **The Old Way:** You buy a building, buy the ovens, and pay for electricity. (Expensive and risky!)
+* **The Cloud Way:** You rent a kitchen only when you have orders. If you have no orders, you pay nothing. If you have a million orders, you rent 100 kitchens instantly.
+
+## 2. Why do we need it? (The 3 Pillars)
+
+### 1. Reliability (It never sleeps)
+Companies like Google, Amazon, and Microsoft have massive data centers with backup power. If one computer fails, another one instantly takes over. Your **CodeHarborHub** projects stay online 24/7.
+
+### 2. Pay-as-you-go
+You don't need to buy a $2,000 server. You can rent a tiny piece of a server for $5 a month (or even for free on "Free Tiers"). You only pay for what you use.
+
+### 3. Scalability
+If your app goes viral, you don't need to run to the store to buy more RAM. You just click a button (or let an automated script do it) to add more power.
+
+## 3. The "Service Models" (Simplified)
+
+You will hear these acronyms a lot. Let’s break them down for a "noob" dev:
+
+* **IaaS (Infrastructure):** You rent the "Raw Metal." You get a blank computer and you install everything (OS, Node.js, DB).
+ * *Examples:* DigitalOcean Droplets, AWS EC2.
+* **PaaS (Platform):** You just give them your code. They handle the server, the OS, and the scaling.
+ * *Examples:* Heroku, Render, Vercel.
+* **SaaS (Software):** You just use the app over the web.
+ * *Examples:* Gmail, Slack, Figma.
+
+## 4. Common Cloud Providers
+
+As a student at **CodeHarborHub**, you will likely start with one of these:
+
+1. **AWS (Amazon Web Services):** The giant. Has everything, but can be complex for beginners.
+2. **Google Cloud (GCP):** Great for AI and data-heavy apps.
+3. **DigitalOcean:** The favorite for "Noob" devs because it is simple and has a clean UI.
+4. **Vercel / Netlify:** The easiest way to host your Frontend (React/Next.js).
+
+## 5. Shared Responsibility Model
+
+A "Master" knows that even though the cloud is powerful, **you are still responsible for your code.**
+* **Cloud Provider handles:** The physical server, the cooling, the electricity, and the hardware.
+* **You (The Developer) handle:** The security of your code, your database passwords, and who has access to your account.
+
+## Practice: The "Cloud Hunt"
+
+1. Go to [AWS](https://aws.amazon.com/) or [DigitalOcean](https://www.digitalocean.com/).
+2. Look for their **"Free Tier"** or **"Student Credits"** page. (GitHub Student Developer Pack is a goldmine for this!).
+3. Identify one service that lets you host a website for free.
+
+:::tip The "Bill" Shock
+The biggest mistake "noob" devs make is leaving a powerful database running and forgetting about it. **Always set up "Billing Alerts"** so the cloud provider sends you an email if you spend more than $1!
+:::
\ No newline at end of file
diff --git a/absolute-beginners/full-stack/cloud/rds.mdx b/absolute-beginners/full-stack/cloud/rds.mdx
index e345ed2..29558fb 100644
--- a/absolute-beginners/full-stack/cloud/rds.mdx
+++ b/absolute-beginners/full-stack/cloud/rds.mdx
@@ -1 +1,91 @@
-
\ No newline at end of file
+---
+title: "AWS RDS: Databases without the Headache"
+sidebar_label: "5. RDS (Managed Databases)"
+sidebar_position: 5
+description: "Learn how to set up and manage professional relational databases using Amazon RDS."
+tags: ["aws", "rds", "managed databases", "mysql", "postgresql", "multi-az", "database security"]
+keywords: ["aws", "rds", "managed databases", "mysql", "postgresql", "multi-az", "database security", "database engines", "scaling", "backups", "snapshots"]
+---
+
+**RDS** stands for **Relational Database Service**.
+
+In the "Old Days," you had to install MySQL or PostgreSQL on your own server, set up backups, manage security patches, and pray that the hard drive didn't fill up. With RDS, you just tell Amazon: *"I want a MySQL database,"* and they give you a link to connect to. Done.
+
+## 1. Why use RDS instead of installing it on EC2?
+
+As "A Master," you want to focus on building features for CodeHarborHub, not fixing servers at 3 AM.
+
+| Feature | Database on EC2 (Manual) | AWS RDS (Managed) |
+| :--- | :--- | :--- |
+| **Setup** | You install and configure everything. | One-click setup. |
+| **Backups** | You have to write scripts to do it. | Automated daily backups. |
+| **Security** | You have to update the OS yourself. | Amazon handles security patches. |
+| **Scaling** | Very hard to add more RAM/CPU. | Click a button to scale up. |
+| **Price** | Slightly cheaper. | Slightly more expensive (but worth it). |
+
+## 2. Choosing your "Engine"
+
+RDS supports all the popular database "languages" (engines) you already know:
+* **PostgreSQL:** Great for complex data and "A Master's" favorite.
+* **MySQL:** The most popular choice for beginners.
+* **MariaDB:** A community-developed branch of MySQL.
+* **Microsoft SQL Server / Oracle:** Usually used by big corporate companies.
+
+## 3. The "Multi-AZ" Magic (High Availability)
+
+Imagine the data center where your database lives gets hit by a power outage.
+* **Without RDS:** Your website is dead until the power comes back.
+* **With RDS Multi-AZ:** Amazon keeps a "standby" copy of your database in a completely different building. If the first building fails, RDS automatically switches to the second one in seconds. Your users won't even notice.
+
+## 4. Connecting your App to RDS
+
+When you create an RDS instance, you don't get a computer you can log into. Instead, you get an **Endpoint** (a URL).
+
+In your Node.js `.env` file, it would look like this:
+
+```env title="Example .env file for RDS connection"
+DB_HOST=codeharbor-db.xyz123.ap-south-1.rds.amazonaws.com
+DB_USER=master_ajay
+DB_PASS=never_use_password123
+DB_NAME=codeharbor_main
+```
+
+Then in your code, you use these environment variables to connect to the database. For example, using the `mysql` package in Node.js:
+
+```javascript title="Example Node.js code to connect to RDS"
+const mysql = require('mysql');
+const connection = mysql.createConnection({
+ host: process.env.DB_HOST,
+ user: process.env.DB_USER,
+ password: process.env.DB_PASS,
+ database: process.env.DB_NAME
+});
+
+connection.connect((err) => {
+ if (err) {
+ console.error('Error connecting to RDS:', err);
+ return;
+ }
+ console.log('Connected to RDS!');
+});
+```
+
+## 5. Security: Don't open the gates!
+
+By default, RDS is locked down.
+
+* **Private Subnets:** A "Master" puts the database in a private area where the public internet can't touch it.
+* **Security Groups:** You should configure the "Bouncer" to **only** allow connections from your **EC2 instance**. This means even if someone has your password, they can't connect unless they are inside your network.
+
+## Practice: The "Free Tier" Database
+
+1. Search for **RDS** in the AWS Console.
+2. Click **Create Database**.
+3. Choose **MySQL**.
+4. Under "Templates," select **Free Tier** (This is crucial to avoid charges!).
+5. Set your "Master Username" and "Password."
+6. Launch it and wait about 5-10 minutes for it to be "Available."
+
+:::info Snapshots
+Before you do something risky (like running a big data migration), take a **Manual Snapshot** of your RDS. It’s like a "Save Point" in a video game. If you break the data, you can restore the entire database back to that exact second.
+:::
\ No newline at end of file
diff --git a/absolute-beginners/full-stack/cloud/s3.mdx b/absolute-beginners/full-stack/cloud/s3.mdx
index e345ed2..be3a5d6 100644
--- a/absolute-beginners/full-stack/cloud/s3.mdx
+++ b/absolute-beginners/full-stack/cloud/s3.mdx
@@ -1 +1,65 @@
-
\ No newline at end of file
+---
+title: "AWS S3: The Infinite Hard Drive"
+sidebar_label: "4. S3 (Cloud Storage)"
+sidebar_position: 4
+description: "Learn how to store and serve files like images, videos, and static websites using Amazon S3."
+tags: ["aws", "s3", "cloud storage", "file hosting", "static website hosting", "storage classes"]
+keywords: ["aws", "s3", "cloud storage", "file hosting", "static website hosting", "storage classes", "buckets", "objects", "public vs private", "versioning"]
+---
+
+**S3** stands for **Simple Storage Service**.
+
+Think of it like a **Google Drive for your code.** While you *could* save images directly on your EC2 server, that's a bad idea (if the server crashes, you lose the photos!). Instead, a "Master" developer puts the files in S3 and just keeps a link to them in their database.
+
+## 1. Buckets and Objects
+
+To understand S3, you only need to know two words:
+
+1. **Buckets:** Think of these as "Root Folders." Every bucket name must be **unique in the entire world.** You might name yours `codeharborhub-user-assets-2026`.
+2. **Objects:** These are the "Files" (images, videos, PDFs, or HTML files). Each object gets its own unique URL.
+
+## 2. Why is S3 better than a regular folder?
+
+* **99.999999999% Durability:** Amazon spreads your file across multiple data centers. The chance of losing a file is basically zero.
+* **Static Website Hosting:** You can put an `index.html` file in a bucket, click a button, and boom—you have a live website without needing a server!
+* **Infinite Space:** You don't have to worry about "running out of disk space." S3 grows as you add more files.
+* **Cheap:** You only pay for the megabytes people actually download.
+
+## 3. Public vs. Private (The "Oops" Factor)
+
+By default, everything in S3 is **Private**. This is good! You don't want the whole world seeing your private data.
+
+However, if you are hosting profile pictures for **CodeHarborHub**, you need to make them "Publicly Readable" so users can see them on your site.
+
+:::warning The Data Leak
+Many big companies have accidentally left their S3 buckets "Public," allowing hackers to steal customer data. **Always double-check your "Block Public Access" settings!**
+:::
+
+## 4. How to use S3 in your App
+
+As a developer, you won't usually upload files through the AWS website. You will use the **AWS SDK** in your Node.js code.
+
+The logic looks like this:
+1. User uploads a photo on your website.
+2. Your Node.js server sends that photo to an **S3 Bucket**.
+3. S3 sends back a **URL** (e.g., `https://my-bucket.s3.amazonaws.com/photo.jpg`).
+4. You save that **URL** in your database.
+
+## 5. Storage Classes (Saving Money)
+
+S3 has different "levels" based on how often you need the files:
+* **S3 Standard:** For files you need instantly and often (like website images).
+* **S3 Glacier:** For "Cold Storage" (like backups you might only need once a year). It's much cheaper, but it takes minutes or hours to get the file back.
+
+## Practice: Create your first Bucket
+
+1. Log in to the **AWS Console** and search for **S3**.
+2. Click **Create Bucket**.
+3. Give it a unique name (try adding your name and the date).
+4. Upload an image from your computer.
+5. Try to open the "Object URL." (Note: It will likely give you an "Access Denied" error—this means the security is working!)
+6. Go to the **Permissions** tab and see if you can figure out how to make that one specific image public.
+
+:::tip Versioning
+You can turn on **Versioning** in S3. This means if you upload a new version of `logo.png`, S3 keeps the old one hidden in the background. If you accidentally delete a file, you can "roll back" to the previous version!
+:::
\ No newline at end of file
diff --git a/absolute-beginners/full-stack/devops/apis/_category_.json b/absolute-beginners/full-stack/devops/apis/_category_.json
new file mode 100644
index 0000000..84ada06
--- /dev/null
+++ b/absolute-beginners/full-stack/devops/apis/_category_.json
@@ -0,0 +1,13 @@
+{
+ "label": "1. APIs & DevOps",
+ "position": 1,
+ "link": {
+ "type": "generated-index",
+ "title": "API Management & DevOps",
+ "description": "Learn the professional 'Master' way to design, document, and manage your APIs. From RESTful principles to versioning and automated documentation with Swagger."
+ },
+ "customProps": {
+ "icon": "api",
+ "description": "Master the art of API design and management. Learn how to create robust, scalable APIs that adhere to industry standards. From RESTful principles to versioning and automated documentation with Swagger, this category covers everything you need to know to become an API pro."
+ }
+}
\ No newline at end of file
diff --git a/absolute-beginners/full-stack/devops/apis/api-design.mdx b/absolute-beginners/full-stack/devops/apis/api-design.mdx
index e440e5c..23a65dc 100644
--- a/absolute-beginners/full-stack/devops/apis/api-design.mdx
+++ b/absolute-beginners/full-stack/devops/apis/api-design.mdx
@@ -1 +1,102 @@
-3
\ No newline at end of file
+---
+title: "Professional API Design"
+sidebar_label: "5. API Design"
+sidebar_position: 5
+description: "Learn high-level design patterns for creating professional, intuitive, and robust APIs."
+tags: ["API design", "RESTful APIs", "best practices", "full-stack development"]
+keywords: ["API design principles", "RESTful API best practices", "resource hierarchy", "filtering and pagination", "error handling", "HATEOAS", "Node.js", "Express"]
+---
+
+Design is about making choices that help other developers understand your system without reading a 100-page manual.
+
+## 1. The Principle of Least Astonishment
+
+Your API should behave exactly how a developer expects it to.
+* If I `GET /users`, I expect a list of users, not a single user or a list of orders.
+* If I send a `DELETE` request, I expect the resource to be gone.
+
+**Consistency is King:** If you use `camelCase` for your JSON keys in one endpoint, use it in all of them.
+
+## 2. Resource Hierarchy & Nesting
+
+In a complex app like CodeHarborHub, data is related. You should reflect these relationships in your URLs, but don't go too deep.
+
+**The "Rule of Two":** Try not to nest resources more than two levels deep.
+
+* **Good:** `/courses/:courseId/lessons` (Clear relationship)
+* **Good:** `/lessons/:lessonId/comments` (Clear relationship)
+* **Bad:** `/categories/:catId/courses/:courseId/lessons/:lessonId/comments` (Too complex!)
+
+:::tip
+If you find yourself going deep, flatten the API. Use `/lessons/:lessonId/comments` instead of nesting it under courses.
+:::
+
+## 3. Filtering, Sorting, and Pagination
+
+When you have thousands of courses, you can't send them all at once. It would crash the browser!
+
+### Pagination
+
+Use `limit` and `page` (or `offset`) to send data in chunks.
+* `GET /courses?page=2&limit=10`
+
+### Filtering
+
+Use query parameters to let users find exactly what they need.
+* `GET /courses?category=javascript&level=beginner`
+
+### Sorting
+
+Allow users to define the order.
+* `GET /courses?sort=newest` or `GET /courses?sort=-price` (The minus sign often indicates descending order).
+
+## 4. Meaningful Error Responses
+
+A "Master" developer never sends a generic "Error occurred." You should provide a clear, JSON-formatted error object so the frontend can show a helpful message to the user.
+
+**The Professional Error Format:**
+
+```json title="Professional Error Response"
+{
+ "status": "error",
+ "code": 404,
+ "message": "Course not found.",
+ "suggestion": "Check if the course ID is correct or if the course has been deleted.",
+ "docs": "https://codeharborhub.github.io/docs/errors/404"
+}
+```
+
+## 5. Using "Hateoas" (Optional but Pro)
+
+**HATEOAS** (Hypermedia as the Engine of Application State) is a fancy term for including "links" in your API response so the client knows what it can do next.
+
+**Example Response:**
+
+```json title="HATEOAS Example"
+{
+ "id": 101,
+ "title": "React for Beginners",
+ "links": [
+ { "rel": "self", "href": "/courses/101" },
+ { "rel": "lessons", "href": "/courses/101/lessons" },
+ { "rel": "enroll", "href": "/courses/101/enroll", "method": "POST" }
+ ]
+}
+
+```
+
+## Practice: The API Architect Challenge
+
+Imagine you are designing the API for **CodeHarborHub's Library**.
+
+1. How would you write the URL to get the 3rd page of "Open Source" books, with 5 books per page, sorted by title?
+2. How would you structure the error message if a user tries to borrow a book that is already checked out?
+
+**Answers:**
+
+1. `GET /books?category=open-source&page=3&limit=5&sort=title`
+2. Status `409 Conflict` with a body explaining "Book currently unavailable."
+
+:::info Input Validation
+Never trust the data sent by the client. Use libraries like **Joi** or **Zod** in your Node.js backend to validate that the "email" is actually an email and the "age" is a number before it ever touches your database.
+:::
\ No newline at end of file
diff --git a/absolute-beginners/full-stack/devops/apis/crud.mdx b/absolute-beginners/full-stack/devops/apis/crud.mdx
index d8263ee..76266cf 100644
--- a/absolute-beginners/full-stack/devops/apis/crud.mdx
+++ b/absolute-beginners/full-stack/devops/apis/crud.mdx
@@ -1 +1,99 @@
-2
\ No newline at end of file
+---
+title: "CRUD Operations in REST"
+sidebar_label: "4. CRUD Operations"
+sidebar_position: 4
+description: "Master the mapping of CRUD actions to HTTP methods and learn how to handle data flow in a professional API."
+tags: ["CRUD", "HTTP methods", "API design", "full-stack development"]
+keywords: ["CRUD operations", "HTTP methods", "POST", "GET", "PUT", "PATCH", "DELETE", "API design", "Node.js", "Express"]
+---
+
+CRUD is the foundation of data management. As a developer, your job is to provide a bridge between the **User's Intent** (Frontend) and the **Database Action** (Backend). When a user clicks "Submit," they are trying to **Create** something. When they load a page, they want to **Read** data. When they edit their profile, they want to **Update** their information. And when they click "Delete," they want to remove something permanently.
+
+## 1. Mapping CRUD to HTTP
+
+Professional APIs use specific HTTP methods to indicate which CRUD operation is being performed.
+
+| CRUD Action | HTTP Method | Example Endpoint | SQL/NoSQL Action |
+| :--- | :--- | :--- | :--- |
+| **Create** | `POST` | `POST /courses` | `INSERT` / `.save()` |
+| **Read** | `GET` | `GET /courses/1` | `SELECT` / `.find()` |
+| **Update** | `PUT` / `PATCH` | `PUT /courses/1` | `UPDATE` / `.update()` |
+| **Delete** | `DELETE` | `DELETE /courses/1` | `DELETE` / `.remove()` |
+
+## 2. Detailed Breakdown
+
+### CREATE (POST)
+Used to send data to the server to create a new resource.
+* **Success Code:** `201 Created`.
+* **Body:** Required (The data for the new resource).
+* **Note:** If you send the same POST request twice, it will usually create two separate entries.
+
+### READ (GET)
+Used to retrieve data. This should be a "safe" operation—meaning it never changes the data on the server.
+* **Success Code:** `200 OK`.
+* **Types:**
+ * `GET /users` (List all users).
+ * `GET /users/101` (Get one specific user).
+
+### UPDATE (PUT vs. PATCH)
+There are two ways to update data, and a "Master" knows the difference:
+* **PUT:** Replaces the **entire** resource. You must send all fields.
+* **PATCH:** Updates only the **specific fields** you send (e.g., just changing a user's profile picture).
+* **Success Code:** `200 OK` or `204 No Content`.
+
+### DELETE (DELETE)
+Used to remove a resource from the database.
+* **Success Code:** `200 OK` or `204 No Content`.
+* **Important:** Once it's gone, it's gone! Always verify authentication before allowing a delete.
+
+## 3. Data Flow Example: CodeHarborHub
+
+Imagine a student wants to post a comment on a lesson. Here is the CRUD flow:
+
+1. **Create:** User types a comment and hits "Submit" → `POST /comments`.
+2. **Read:** The page refreshes and fetches all comments → `GET /comments`.
+3. **Update:** User fixes a typo in their comment → `PATCH /comments/id_123`.
+4. **Delete:** User decides to remove the comment → `DELETE /comments/id_123`.
+
+## 4. Handling Responses
+
+When performing CRUD, your API should talk back to the frontend clearly:
+
+```javascript title="Example Express Controller for Deleting a Course"
+exports.deleteCourse = async (req, res) => {
+ try {
+ const course = await Course.findByIdAndDelete(req.params.id);
+
+ if (!course) {
+ return res.status(404).json({ message: "Course not found!" });
+ }
+
+ res.status(200).json({ message: "Course deleted successfully!" });
+ } catch (error) {
+ res.status(500).json({ message: "Server Error", error: error.message });
+ }
+};
+
+```
+
+## Practice: The CRUD Logic Check
+
+Imagine you are building a "Library Management System." Write down the 5 endpoints you would need to:
+
+1. Add a new book.
+2. See all books.
+3. Search for one book by ID.
+4. Update the "status" of a book (Available/Borrowed).
+5. Remove a book from the system.
+
+**Answers:**
+
+1. `POST /books`
+2. `GET /books`
+3. `GET /books/:id`
+4. `PATCH /books/:id`
+5. `DELETE /books/:id`
+
+:::info Response Bodies
+When you `POST` a new item, it is a best practice to return the **newly created object** (including its new `_id`) in the response body. This allows the frontend to update the UI instantly without having to do another `GET` request!
+:::
\ No newline at end of file
diff --git a/absolute-beginners/full-stack/devops/apis/documentation.mdx b/absolute-beginners/full-stack/devops/apis/documentation.mdx
index 62f9457..647b50b 100644
--- a/absolute-beginners/full-stack/devops/apis/documentation.mdx
+++ b/absolute-beginners/full-stack/devops/apis/documentation.mdx
@@ -1 +1,101 @@
-6
\ No newline at end of file
+---
+title: "API Documentation with Swagger and OpenAPI"
+sidebar_label: "8. API Documentation"
+sidebar_position: 8
+description: "Learn how to use Swagger and OpenAPI to create interactive and professional documentation for your APIs."
+tags: ["API documentation", "Swagger", "OpenAPI", "interactive docs", "full-stack development"]
+keywords: ["API documentation", "Swagger", "OpenAPI", "interactive API docs", "API design", "Node.js", "Express", "API testing", "Postman collections"]
+---
+
+A professional API should be "self-documenting." This means another developer should be able to understand your endpoints, required parameters, and response formats without ever looking at your backend source code.
+
+## 1. What is OpenAPI and Swagger?
+
+* **OpenAPI Specification (OAS):** The industry-standard "language" used to describe REST APIs. It’s a set of rules for writing a JSON or YAML file that describes your API.
+* **Swagger:** The set of tools that uses the OpenAPI spec to generate beautiful, interactive UI pages.
+
+## 2. Why use Interactive Docs?
+
+1. **Try it Out:** Swagger allows users to send real requests to your API directly from the documentation page. No Postman required!
+2. **Consistency:** It forces you to define your data models (Schemas), ensuring your API is consistent.
+3. **Client Generation:** You can use your Swagger file to automatically generate frontend code (SDKs) in various languages.
+
+## 3. Implementing Swagger in Node.js
+
+We use `swagger-jsdoc` to read our code comments and `swagger-ui-express` to serve the interactive page.
+
+### Installation
+
+```bash
+npm install swagger-jsdoc swagger-ui-express
+```
+
+### Basic Configuration
+
+```javascript title="Basic Swagger Setup in Express"
+const express = require('express');
+const swaggerJsdoc = require('swagger-jsdoc');
+const swaggerUi = require('swagger-ui-express');
+
+const options = {
+ definition: {
+ openapi: '3.0.0',
+ info: {
+ title: 'CodeHarborHub API',
+ version: '1.0.0',
+ description: 'The official API for the CodeHarborHub platform',
+ },
+ servers: [{ url: 'http://localhost:5000' }],
+ },
+ apis: ['./routes/*.js'], // Path to the API docs (where your comments are)
+};
+
+const specs = swaggerJsdoc(options);
+app.use('/api-docs', swaggerUi.serve, swaggerUi.setup(specs));
+
+```
+
+## 4. Documenting an Endpoint
+
+You write the documentation directly above your routes using JSDoc comments. This ensures your docs are always close to your logic!
+
+```javascript title="Example of Swagger Documentation for a GET Route"
+/**
+ * @openapi
+ * /api/courses:
+ * get:
+ * summary: Retrieve a list of all courses
+ * responses:
+ * 200:
+ * description: A list of courses.
+ * content:
+ * application/json:
+ * schema:
+ * type: array
+ * items:
+ * type: object
+ * properties:
+ * id: { type: string }
+ * title: { type: string }
+ */
+router.get('/courses', getCourses);
+
+```
+
+## 5. Best Practices for Great Docs
+
+* **Be Descriptive:** Don't just say `200 OK`. Say `200 OK - Returns an array of course objects`.
+* **Document Errors:** Always include common error codes like `401 Unauthorized` or `404 Not Found` so frontend developers can handle them.
+* **Use Tags:** Group your routes (e.g., "Authentication", "Courses", "Users") to keep the UI organized.
+* **Keep it Updated:** If you change a parameter in your route, update the comment immediately!
+
+## Practice: The Documentation Audit
+
+1. Set up Swagger in your current project.
+2. Navigate to `http://localhost:5000/api-docs`.
+3. Click the **"Try it out"** button on one of your GET routes.
+4. Examine the response. Does it match what you expected?
+
+:::info Postman Collections
+While Swagger is great for public documentation, you can also export your Swagger file and import it into **Postman**. This gives you a "Master" workspace where you can save tests and share them with your team!
+:::
\ No newline at end of file
diff --git a/absolute-beginners/full-stack/devops/apis/introduction.mdx b/absolute-beginners/full-stack/devops/apis/introduction.mdx
new file mode 100644
index 0000000..78f2e98
--- /dev/null
+++ b/absolute-beginners/full-stack/devops/apis/introduction.mdx
@@ -0,0 +1,59 @@
+---
+title: "Introduction to API Strategy"
+sidebar_label: "1. Introduction"
+sidebar_position: 1
+description: "Understand the role of APIs in the DevOps lifecycle and why professional API design matters."
+tags: ["api", "rest", "graphql", "gRPC", "webhooks", "devops", "full-stack development"]
+keywords: ["api", "rest", "graphql", "gRPC", "webhooks", "devops", "full-stack development", "api design", "versioning", "documentation", "security", "performance"]
+---
+
+In professional software development, we don't just "make routes." We design **API Interfaces** that are meant to last for years. As a "Master" developer, you must think about how other developers (and your future self) will interact with your server.
+
+## 1. What is an API in the Full-Stack World?
+
+An API is a set of rules that allows one piece of software to talk to another. In our MERN or SQL-based stacks, the API is usually a **REST API** that sends and receives data in **JSON** format.
+
+### The Request-Response Cycle:
+
+1. **Client (Frontend):** "Hey Server, give me the details for the 'React 101' course."
+2. **Server (Backend):** Checks the database, finds the course, and packages it into JSON.
+3. **Response:** "Here you go: `{ "id": 1, "title": "React 101", ... }`"
+
+## 2. Why "Strategy" Matters (The DevOps Perspective)
+
+In a DevOps environment, we care about **Stability**. If you change an API route today, you might break the mobile app that thousands of people are using.
+
+A solid API strategy focuses on:
+* **Consistency:** Using the same naming conventions everywhere.
+* **Versioning:** Providing a way to update the API without breaking old versions.
+* **Documentation:** Making it easy for others to understand how to use your API.
+* **Security:** Ensuring only authorized "Masters" can access sensitive data.
+
+## 3. The 4 Pillars of a Professional API
+
+| Pillar | Meaning |
+| :--- | :--- |
+| **Predictability** | `GET /users` should return users. `POST /users` should create one. No surprises! |
+| **Idempotency** | Doing the same thing twice (like deleting a user) shouldn't break the server. |
+| **Error Handling** | Instead of a "Server Error," send helpful messages like "Invalid Email Format." |
+| **Performance** | Using tools like **Redis** (which we just learned!) to make responses instant. |
+
+## 4. Common API Architectures
+
+While we focus on **REST** at the Hub, a "Master" should know the alternatives:
+
+1. **REST (Representational State Transfer):** The most common. Uses standard HTTP methods (GET, POST, PUT, DELETE).
+2. **GraphQL:** Allows the client to ask for *exactly* the data they need (no more, no less).
+3. **gRPC:** Used for ultra-fast communication between internal microservices.
+4. **Webhooks:** An API that works in reverse—the server "calls" the client when something happens.
+
+## Practice: The "API Discovery" Task
+
+1. Open your browser and go to the [GitHub API](https://api.github.com/users/ajay-dhangar).
+2. Look at the JSON data returned.
+3. Notice how clean the keys are (`name`, `bio`, `public_repos`).
+4. This is a **Professional API**. Your goal in this track is to learn how to build something of this quality for **CodeHarborHub**.
+
+:::info
+A great API is like a good joke: if you have to explain it too much, it’s probably not that good. Aim for "Self-Documenting" code where the route names make the functionality obvious.
+:::
\ No newline at end of file
diff --git a/absolute-beginners/full-stack/devops/apis/rate-limiting.mdx b/absolute-beginners/full-stack/devops/apis/rate-limiting.mdx
index 7813681..57c6126 100644
--- a/absolute-beginners/full-stack/devops/apis/rate-limiting.mdx
+++ b/absolute-beginners/full-stack/devops/apis/rate-limiting.mdx
@@ -1 +1,98 @@
-5
\ No newline at end of file
+---
+title: "API Rate Limiting & Throttling"
+sidebar_label: "7. Rate Limiting"
+sidebar_position: 7
+description: "Protect your API from brute-force attacks and denial-of-service (DoS) by limiting user requests."
+tags: ["API rate limiting", "throttling", "express-rate-limit", "Node.js", "Express", "full-stack development"]
+keywords: ["API rate limiting", "throttling", "express-rate-limit", "Node.js", "Express", "429 Too Many Requests", "Retry-After header", "Redis", "scalable rate limiting", "API security"]
+---
+
+Rate limiting is the practice of limiting the number of requests a user can make to your API within a specific timeframe (e.g., 100 requests every 15 minutes). This is crucial for protecting your server from abuse, preventing brute-force attacks, and managing costs when using third-party APIs.
+
+## 1. Why do we need Rate Limiting?
+
+1. **Prevent Abuse:** Stop bots from "scraping" all your course data from CodeHarborHub.
+2. **Brute Force Protection:** Prevent hackers from trying millions of passwords on your login route.
+3. **Cost Management:** If you use paid third-party APIs (like OpenAI), rate limiting saves you from huge bills.
+4. **Server Stability:** Ensures that one heavy user doesn't slow down the experience for the "Masters" using your site.
+
+## 2. Rate Limiting vs. Throttling
+
+While often used interchangeably, there is a slight difference:
+* **Rate Limiting:** Hard limit. Once you hit the limit, you get an error (429 Too Many Requests).
+* **Throttling:** Soft limit. The server slows down your connection speed instead of blocking you entirely.
+
+## 3. Implementing Rate Limiting in Node.js
+
+We use the popular `express-rate-limit` package to handle this easily.
+
+### Installation
+
+```bash
+npm install express-rate-limit
+```
+
+### Basic Setup
+
+You can apply a global limit to your entire API:
+
+```javascript title="Basic Express Rate Limiting Setup"
+const rateLimit = require('express-rate-limit');
+
+const globalLimiter = rateLimit({
+ windowMs: 15 * 60 * 1000, // 15 minutes
+ max: 100, // Limit each IP to 100 requests per windowMs
+ message: {
+ status: 429,
+ message: "Too many requests from this IP, please try again later."
+ },
+ standardHeaders: true, // Return rate limit info in the `RateLimit-*` headers
+ legacyHeaders: false, // Disable the `X-RateLimit-*` headers
+});
+
+// Apply to all requests
+app.use('/api/', globalLimiter);
+
+```
+
+## 4. Tiered Rate Limiting
+
+As a "Master" architect, you shouldn't treat all routes equally.
+
+### Example Strategy:
+
+* **Login/Signup:** Very strict (e.g., 5 attempts per hour) to prevent hacking.
+* **Search/Courses:** Medium (e.g., 100 requests per 15 minutes).
+* **Public Landing Page:** Very loose or no limit.
+
+```javascript title="Tiered Rate Limiting Example"
+const authLimiter = rateLimit({
+ windowMs: 60 * 60 * 1000, // 1 hour
+ max: 5,
+ message: "Too many login attempts. Take a break!"
+});
+
+app.use('/api/auth/login', authLimiter);
+
+```
+
+## 5. Handling the "429 Too Many Requests"
+
+When a user hits the limit, your API should return a **429 status code**. It is also a best practice to include a `Retry-After` header telling the client exactly how many seconds to wait before trying again.
+
+## 6. Using Redis for Scalability
+
+In a professional "Master" setup with multiple servers, `express-rate-limit` (which stores data in RAM) won't work well because different servers won't know about each other's limits.
+
+**The Pro Solution:** Use **Redis** as a central store for rate-limit data. This way, if a user hits Server A or Server B, their total count is tracked in one place.
+
+## Practice: The Stress Test
+
+1. Apply a limit of **5 requests per minute** to your project.
+2. Open your browser and refresh the page 6 times quickly.
+3. Did you see your custom error message?
+4. Check the "Network" tab in your DevTools—can you see the `RateLimit-Limit` and `RateLimit-Remaining` headers?
+
+:::info Whitelisting
+Always provide a "Whitelist" for your own IP address or internal services (like your monitoring tools) so you don't accidentally lock yourself out of your own API!
+:::
\ No newline at end of file
diff --git a/absolute-beginners/full-stack/devops/apis/rest-basics.mdx b/absolute-beginners/full-stack/devops/apis/rest-basics.mdx
index 56a6051..0245bc5 100644
--- a/absolute-beginners/full-stack/devops/apis/rest-basics.mdx
+++ b/absolute-beginners/full-stack/devops/apis/rest-basics.mdx
@@ -1 +1,85 @@
-1
\ No newline at end of file
+---
+title: "REST Basics: Requests & Responses"
+sidebar_label: "3. REST Basics"
+sidebar_position: 3
+description: "Learn the structure of HTTP requests and responses, headers, and the importance of JSON in RESTful communication."
+tags: ["APIs", "REST", "HTTP requests", "HTTP responses", "JSON", "full-stack development"]
+keywords: ["REST basics", "HTTP requests", "HTTP responses", "JSON", "Content-Type", "Authorization header", "query parameters", "path parameters", "API communication", "Node.js", "Express"]
+---
+
+Every time your app communicates, it sends an **HTTP Request** and receives an **HTTP Response**. As a developer, you need to be able to "read" these messages to debug and build features effectively.
+
+## 1. The Anatomy of a Request
+
+When you call `fetch()` or `axios.get()` in React, you are constructing an HTTP Request. It consists of four main parts:
+
+1. **URL (Endpoint):** Where is the request going? (e.g., `https://api.codeharborhub.com/v1/users`)
+2. **Method:** What action are we taking? (GET, POST, etc.)
+3. **Headers:** Meta-information about the request (e.g., "I am sending JSON," or "Here is my Secret Token").
+4. **Body (Payload):** The actual data being sent (used in POST, PUT, and PATCH).
+
+## 2. The Anatomy of a Response
+
+Once the server processes your request, it sends back a response. It consists of:
+
+1. **Status Code:** A numerical code telling you if the request succeeded or failed (e.g., `200`, `404`).
+2. **Headers:** Information about the server and the data being sent back.
+3. **Body:** The data you asked for, almost always in **JSON** format.
+
+## 3. Why JSON? (JavaScript Object Notation)
+
+In the past, APIs used XML, which was bulky and hard to read. Modern REST APIs use **JSON** because:
+* It looks exactly like a JavaScript Object.
+* It is lightweight and fast to send over the network.
+* It is easy for both humans to read and machines to parse.
+
+**Example of a JSON Resource:**
+
+```json title="jsonExample.json"
+{
+ "id": "ch-101",
+ "title": "Mastering Node.js",
+ "author": "Ajay Dhangar",
+ "isPublished": true,
+ "tags": ["backend", "javascript", "devops"]
+}
+
+```
+
+## 4. Essential HTTP Headers
+
+Headers act like the "labels" on a shipping box. Here are the ones you will use most:
+
+* **Content-Type:** Tells the receiver what kind of data is in the body (e.g., `application/json`).
+* **Authorization:** Used to send your **JWT** (e.g., `Bearer `).
+* **Accept:** Tells the server what format the client wants to receive (e.g., `application/json`).
+* **User-Agent:** Identifies the browser or tool making the request.
+
+## 5. Query Parameters vs. Path Parameters
+
+How do you tell the server *which* specific data you want?
+
+### Path Parameters (Identity)
+
+Used to identify a **specific resource**.
+
+* URL: `/api/users/123`
+* In Express: `app.get('/api/users/:id', ...)`
+
+### Query Parameters (Filtering/Sorting)
+
+Used to **modify** the results of a collection.
+
+* URL: `/api/courses?category=javascript&sort=popular`
+* In Express: Accessed via `req.query.category`.
+
+## Practice: The Postman Challenge
+
+1. Download and open **Postman** or **Insomnia**.
+2. Make a `GET` request to `https://jsonplaceholder.typicode.com/posts/1`.
+3. Look at the **Headers** tab in the response. Can you find the `Content-Type`?
+4. Now make a `POST` request to the same URL with a JSON body: `{"title": "My New Post"}`. Look at the status code—did you get a `201 Created`?
+
+:::info Idempotency
+A "Master" developer ensures that `GET`, `PUT`, and `DELETE` requests are **Idempotent**. This means that if you click "Delete" five times, the result is the same as clicking it once (the item is gone). `POST` is **not** idempotent because clicking "Create" five times creates five different items!
+:::
\ No newline at end of file
diff --git a/absolute-beginners/full-stack/devops/apis/rest-principles.mdx b/absolute-beginners/full-stack/devops/apis/rest-principles.mdx
new file mode 100644
index 0000000..28e1922
--- /dev/null
+++ b/absolute-beginners/full-stack/devops/apis/rest-principles.mdx
@@ -0,0 +1,95 @@
+---
+title: "RESTful Principles & Best Practices"
+sidebar_label: "2. REST Principles"
+sidebar_position: 2
+description: "Master the core constraints of REST architecture to build predictable and scalable APIs."
+tags: ["APIs", "REST", "RESTful principles", "HTTP methods", "status codes", "full-stack development"]
+keywords: ["REST principles", "client-server separation", "statelessness", "cacheability", "uniform interface", "layered system", "code on demand", "HTTP methods", "status codes", "API design", "Node.js", "Express"]
+---
+
+REST was designed to take advantage of the existing protocols of the internet (HTTP). As a "Master" developer, you don't need to reinvent the wheel—you just need to follow the standards.
+
+## 1. The 6 Constraints of REST
+
+To be truly RESTful, an API must follow these six guiding principles:
+
+### 1. Client-Server Separation
+The frontend (Client) and the backend (Server) are independent. You can change your React UI completely without touching your Node.js logic, as long as the API interface stays the same.
+
+### 2. Statelessness
+The server does not "remember" the user between requests. Every single request from the client must contain all the information needed to understand and process it (e.g., the **JWT** in the header).
+
+### 3. Cacheability
+Responses must define themselves as cacheable or not. This allows browsers or tools like **Redis** to store data and improve performance.
+
+### 4. Uniform Interface
+This is the most important part! It means:
+* **Resources** are identified by URLs (e.g., `/users/101`).
+* **Actions** are performed using standard HTTP methods.
+* **Self-descriptive messages:** The response tells you how to process it (usually via `Content-Type: application/json`).
+
+### 5. Layered System
+A client cannot tell if it is connected directly to the end server or an intermediary like a Load Balancer or a Cache (like a "Master" setup using Nginx).
+
+### 6. Code on Demand (Optional)
+The server can occasionally send executable code (like JavaScript) to the client.
+
+## 2. Resource-Based Naming
+
+In REST, we focus on **Resources** (Nouns), not **Actions** (Verbs).
+
+| The Wrong Way (Action-based) | The RESTful Way (Resource-based) |
+| :--- | :--- |
+| `GET /getAllUsers` | `GET /users` |
+| `POST /createUser` | `POST /users` |
+| `POST /updateUser/101` | `PUT /users/101` |
+| `GET /deleteUser?id=101` | `DELETE /users/101` |
+
+## 3. Using HTTP Methods Correctly
+
+As a professional, you must use the right tool for the job:
+
+* **GET:** Retrieve data. (Should never change data on the server).
+* **POST:** Create a new resource.
+* **PUT:** Update an *entire* resource (Replace).
+* **PATCH:** Update *part* of a resource (e.g., just changing a user's bio).
+* **DELETE:** Remove a resource.
+
+## 4. HTTP Status Codes: The Server's Voice
+
+Don't just return `200 OK` for everything. Use specific codes so the frontend knows exactly what happened:
+
+* **2xx (Success):**
+ * `200 OK`: Standard success.
+ * `201 Created`: Successfully created a new resource (e.g., after a POST).
+* **4xx (Client Error):**
+ * `400 Bad Request`: The frontend sent invalid data.
+ * `401 Unauthorized`: User needs to log in.
+ * `404 Not Found`: That URL or resource doesn't exist.
+* **5xx (Server Error):**
+ * `500 Internal Server Error`: Your code crashed.
+ * `503 Service Unavailable`: The server is overloaded or down.
+
+## 5. Handling Relationships
+
+How do you get all lessons for a specific course at CodeHarborHub? Use sub-resources:
+
+`GET /courses/react-101/lessons`
+
+This structure makes the relationship between data clear and hierarchical.
+
+## Practice: The "REST" Redesign
+
+Look at these "Bad" API routes and rewrite them in your mind to be RESTful:
+1. `GET /search_results?type=blog`
+2. `POST /edit_comment_id_50`
+3. `GET /api/v1/save_new_user_profile`
+
+**Answers:**
+1. `GET /blogs`
+2. `PATCH /comments/50`
+3. `POST /users`
+
+:::info Plural Nouns
+Always use plural nouns for your resources (`/users` instead of `/user`). it's more consistent and follows the industry standard for collections.
+:::
\ No newline at end of file
diff --git a/absolute-beginners/full-stack/devops/apis/validation.mdx b/absolute-beginners/full-stack/devops/apis/validation.mdx
index bf0d87a..dfd8bd6 100644
--- a/absolute-beginners/full-stack/devops/apis/validation.mdx
+++ b/absolute-beginners/full-stack/devops/apis/validation.mdx
@@ -1 +1,107 @@
-4
\ No newline at end of file
+---
+title: "API Validation & Sanitization"
+sidebar_label: "6. API Validation"
+sidebar_position: 6
+description: "Learn how to protect your database and server by validating and sanitizing incoming API requests."
+tags: ["API validation", "data sanitization", "Joi", "Node.js", "Express", "full-stack development"]
+keywords: ["API validation", "data sanitization", "Joi", "Node.js", "Express", "validation schema", "input validation", "security best practices", "backend development"]
+---
+
+Validation is the process of ensuring that the data sent to your API meets your requirements. Sanitization is the process of cleaning that data to prevent security risks like Script Injection.
+
+## 1. Why Validate?
+
+Without validation, your application is vulnerable to:
+* **Database Corruption:** Saving "None" or "Undefined" in required fields.
+* **Crashes:** Your code trying to perform math on a string.
+* **Security Flaws:** Hackers sending malicious code in a `username` field.
+
+## 2. Validation vs. Sanitization
+
+| Process | Goal | Example |
+| :--- | :--- | :--- |
+| **Validation** | Check if data is correct. | Is this a valid email address? |
+| **Sanitization** | Clean the data. | Remove `