DEV Community: Taufiqul Islam

This is What AI Development Actually Looks Like in 2026 - Stop Prompting. Start Directing.

Taufiqul Islam — Mon, 15 Jun 2026 10:45:02 +0000

I want to be honest about something upfront.
Most "I built [anything] with AI" posts are actually "I prompted AI and fixed whatever came out." That is not a workflow. That is improvisation with extra steps.

This post is about a structured approach - one that works whether you are building a frontend portfolio, a full-stack SaaS, a REST API, or a microservice. The phases are the same. The discipline is the same. The results are the same.

Where We Are Right Now

As of 2026, Claude Code has crossed 500,000 active developer users worldwide. GitHub Copilot has over 1.8 million paid subscribers. A Stack Overflow survey found that 76% of developers are now using or planning to use AI tools in their development process.

But here is the uncomfortable number: 42% of developers said AI-generated code introduced bugs they had to spend significant time debugging. Another 38% said the code did not match their project's conventions.

Fast but wrong. That is the current state of AI-assisted development for most teams.

The problem is not the tools. The problem is the workflow - or the lack of one.

The Real Problem - AI Forgets Everything

Open a new chat. Paste an error. Get a fix. Copy it back.

Open another chat tomorrow. Explain the whole project again. Paste another error. Get another fix.

Every session starts from zero. The AI has no memory of your folder structure, your naming conventions, your design tokens, your API patterns. You spend half your time giving context instead of building.

This is the chatbox trap. It feels like using AI. It is actually just a slower Stack Overflow.

Before You Write a Single Command - The Design Foundation

This step happens before opening any terminal. It is what makes everything else work.

Take screenshots of your design. Figma, Adobe XD, Canva, PDF mockup - it does not matter. Export screenshots per feature, per page, per state. Close-up screenshots of specific components. Wide screenshots for layout. Light mode and dark mode both.

Organize them like this:

docs/
└── designs/
    ├── system-design.md     ← all design tokens
    └── ss/
        ├── hero-light.png
        ├── hero-dark.png
        └── dashboard-light.png

Write your system-design.md. Every color token with its hex value. Every font family, font size, font weight. Every spacing value. Every border radius. Light mode and dark mode separately.

## Colors
--color-bg-page:      #f7f7f2   (light) / #0d0d0d (dark)
--color-text-primary: #111111   (light) / #f0f0f0 (dark)
--color-accent:       #2d6a4f   (light) / #84cc16 (dark)

## Typography
--font-serif: Playfair Display
--font-sans:  Geist Sans
--font-mono:  Geist Mono

## Spacing
--spacing-section: 80px
--spacing-content: 40px

This file is what the AI reads to understand your visual language. Without it the AI guesses. With it every component uses your exact tokens.

Write CLAUDE.md. The project bible. Tech stack, folder structure, naming conventions, every rule the AI should follow. You write this once. The AI reads it every session and never forgets.

Write CONTEXT.md. The domain language. What are things actually called in your project? What is the difference between a User and a Consultant? What does assign mean versus link? When terminology is written down the AI uses it consistently across every file it touches.

With these four things in place - screenshots, system-design.md, CLAUDE.md, CONTEXT.md - the AI has permanent memory of your project. No more explaining from scratch every session.

The Four-Phase Loop

Four hard stops. Nothing moves forward until the current phase is complete. The stops are not bureaucracy - they are the entire point.

Phase 1 - Grilling

Triggered by: /grill-with-docs build <feature>

The AI reads all your documentation - system-design.md, CLAUDE.md, CONTEXT.md, the relevant screenshots - then interrogates you about the feature. One question at a time. It waits for your answer before asking the next.

For a frontend feature:
What font size is the heading? What happens on hover? What does empty state look like? Which screenshot does this match?

For a backend feature:
What does the request body look like? What HTTP status does a validation error return? Is this endpoint authenticated? What happens when the foreign key does not exist?

For a full-stack feature:
What is the API contract between frontend and backend? Who owns error handling? What does the frontend show when the request is pending? When it fails?

Every question answered here is a bug that never gets written in Phase 3. The phase ends when a task spec file is written at docs/tasks/<feature>.md. Then a hard stop. No code, nothing in src/.

"Every question answered in Phase 1 is a bug that never gets written in Phase 3."

Phase 2 - PRD

Triggered by: /prd or /to-prd

The AI synthesizes everything from the grilling session into a Product Requirements Document. Problem statement, user stories, implementation decisions, API contracts, data shapes, what is explicitly out of scope.

You review it. If something is wrong you flag it. If it aligns you say so. Then another hard stop.

With GitHub MCP connected, the PRD is automatically submitted as a GitHub issue. Every feature becomes a tracked issue before a single line of code is written.

# Connect GitHub MCP once
claude mcp add --transport http github https://api.githubcopilot.com/mcp/ \
  --header "Authorization: Bearer YOUR_GITHUB_TOKEN"

Now /prd creates the spec and opens the issue. When Phase 3 finishes, the AI automatically creates a PR linked to that issue. Your entire feature lifecycle - spec, implementation, review, merge - tracked in GitHub without leaving the terminal.

Phase 3 - TDD

Triggered by: /tdd build <feature>

All the code is written here. The cycle is red → green → refactor. Write a failing test, write the minimum code to pass it, clean up, move to the next behavior.

For a frontend component:
Types first, then data, then component, then wired into the page. After build passes, Playwright MCP opens the browser automatically, takes a screenshot, compares it against your design reference, lists every discrepancy, fixes them, re-screenshots. Repeats until it matches both light and dark mode.

For a backend endpoint:
Types first, then service logic, then controller, then route registration. Tests cover happy path, validation errors, authentication failures, and edge cases from the PRD.

For an API integration:
Service layer built and tested first with mocked responses. Real API connected. Error states, loading states, empty states all verified against the PRD.

Nothing is committed yet. Phase 4 happens first.

Phase 4 - Review

Triggered by: /review

After /tdd finishes the AI audits everything it just built against your CLAUDE.md rules.

Hardcoded values that should be tokens? Flagged.
Missing TypeScript types? Flagged.
Components that duplicate existing primitives? Flagged.
API calls missing error handling? Flagged.
Accessibility issues? Flagged.

Then it fixes everything it flagged. The diff you approve is clean code - not just working code.

After /review passes, the AI proposes a commit message, shows the full diff, and waits. You review, approve, and it commits - or creates a PR linked to the GitHub issue automatically.

The Full Setup

Install once globally:

# Claude Code CLI
npm install -g @anthropic-ai/claude-code

# Matt Pocock's skills - /grill-with-docs, /tdd, /prd, /review
npx openskills install mattpocock/skills --global

# Playwright MCP - real browser for visual verification
claude mcp add --transport stdio playwright -- npx -y @playwright/mcp@latest

# GitHub MCP - optional, for automatic issues and PRs
claude mcp add --transport http github https://api.githubcopilot.com/mcp/ \
  --header "Authorization: Bearer YOUR_TOKEN"

Per project - four files:

docs/designs/system-design.md   ← design tokens
docs/designs/ss/*.png            ← feature screenshots
CLAUDE.md                        ← project rules
CONTEXT.md                       ← domain language

Per feature - four commands:

/grill-with-docs build <feature>   # questions + task spec → STOP
/prd                                # PRD + GitHub issue   → STOP
/tdd build <feature>                # build + Playwright   → STOP
/review                             # quality gate → commit approval

What This Looks Like End to End

# Building a user management feature

/grill-with-docs build user management
# AI reads CLAUDE.md, CONTEXT.md, system-design.md
# Asks: what fields does a user have? what roles exist?
# what does the list page look like? (reads screenshot)
# what happens when you delete a user with active sessions?
# ... 10 questions total, you answer each one
# writes docs/tasks/user-management.md
# STOP

/prd
# synthesizes task spec into full PRD
# creates GitHub issue #47 automatically
# STOP

/tdd build user management
# writes failing tests
# builds UserService, UserController, routes
# builds UserTable, UserForm components
# Playwright screenshots list page, compares against design
# fixes spacing mismatch on row height
# re-screenshots, matches - done
# STOP

/review
# flags: UserForm missing loading state from PRD
# flags: one hardcoded hex color in UserTable
# fixes both
# proposes commit: "feat: add user management (#47)"
# you approve
# PR created, linked to issue #47

One feature. Four commands. Complete audit trail. Zero surprises.

Why The Hard Stops Matter

Most AI-assisted workflows fail because the AI keeps moving. It generates code while you are still figuring out what you want. By the time you realize the direction is wrong there is significant code to undo.

Forcing a stop after grilling means the spec is locked before implementation. Forcing a stop after the PRD means the contract is signed before code runs. Forcing a stop after TDD means the code is reviewed before it is committed.

By Phase 4 there are no open questions - just a quality check on clean execution.

The Playwright visual check closes the quality loop for frontend. The test suite closes it for backend. The /review phase closes it for code quality. Without automated verification "looks good" and "seems to work" are the standards. With it the check is objective and repeatable.

The Numbers

Gartner predicts that by 2028, 75% of enterprise software engineers will use AI coding assistants daily, up from roughly 25% in 2025. Claude Code usage has grown 340% year over year according to Anthropic's 2026 developer report. The percentage of professional developers using AI in their daily workflow crossed 60% in Q1 2026 for the first time.

But the shift that is coming is not about more developers using AI. It is about developers using AI differently - moving from ad-hoc prompting to structured workflows, from chatbox conversations to disciplined collaboration.

The four-phase loop is one version of that structure. The specific commands will evolve. Better tools will emerge. But the underlying discipline - front-load decisions, lock the spec, verify automatically, review before committing - that will remain.

Because that discipline is not about AI. It is about how good software gets built. AI just makes the execution faster.

The Honest Part

This workflow only works if you can answer the grilling questions. Phase 1 exposes every gap in your thinking. If you do not know what you are building the AI cannot figure it out for you.

AI removes friction between thinking and shipping. It does not replace the thinking.

We spent years learning to write code. The next skill is learning to direct it.

Start Here

Take screenshots of your current project's designs
Write a system-design.md extracting the tokens
Write a CLAUDE.md - ten minutes, basics only
Run /grill-with-docs on your next feature
Answer every question honestly

The first session will feel slower than prompting and copying. The second will feel natural. By the third you will not want to go back.

Software engineer, 4+ years building web applications.

GitHub · LinkedIn

How Software Engineers Can Stay Relevant in the Age of AI

Taufiqul Islam — Mon, 08 Dec 2025 05:59:56 +0000

📌 This blog lays the foundation. After reading it, check out my updated article to see how AI workflows (/grill, /prd, /tdd, /review) are changing the way we build software.

Imagine waking up one day to find that the skills you’ve spent years mastering are suddenly being performed faster, cheaper, and more efficiently by AI. This isn’t science fiction - it’s the reality facing software engineers today.

In 2001, a professor told his students that software engineering was a golden ticket to job security. Fast forward to 2025, and the CEO of GitHub declared that the future of programming is natural language. The prediction came true - but not in the way anyone expected. AI is now capable of writing code, fixing bugs, and even generating entire projects from natural language prompts. Tools like GitHub Copilot and ChatGPT are changing the game, raising a critical question:
How can software engineers stay relevant in an era where AI is becoming a co-pilot- or even a competitor?⛔

Don’t be afraid, this isn’t the end of software engineering. It’s the beginning of a new chapter. Let’s explore how you can not only stay relevant but thrive in the age of AI.

🧠 1. AI’s Capabilities and Limitations: What You Need to Know

💪 What AI Can Do

Generate code fast: Can produce large, functional codebases within seconds.
Translate languages: Converts code between languages (e.g., Python ⇄ JavaScript).
Automate fixes & tasks: Helps with debugging, testing, repetitive work, and UI generation.

🙏 What AI Can’t Do

Understand the “why”: Lacks human intuition and real context.
Think strategically: Can’t handle long-term planning, trade-offs, or ethics well.
Communicate & collaborate: Cannot replace human empathy or teamwork.
Be fully reliable: May hallucinate or produce incorrect code; most AI code still needs human review.

📌 AI is like a brilliant junior developer, it can do a lot quickly, but it’s up to us to define the vision, validate the results, and ensure what we’re building is good for society.

🛠️ 2. The Evolving Role of Software Engineers: Beyond Coding

Software engineering has never been just about writing code. It’s about solving problems, understanding user needs, and making tough decisions.

In the AI era, the role of engineers is evolving:

Look at the image, and you’ll understand why engineers are still essential.

Understanding AI: Engineers don’t just prompt AI - they understand the models, data pipelines, and risks.
Building Better Software: Anyone can prototype a demo with AI, but engineers build scalable, maintainable, and secure systems.
Improving AI: Engineers fine-tune models, optimize performance, and make AI accessible to everyone.

📌 We’re not just building software anymore - we’re building the future of intelligence itself.

📚 3. How to Prepare for the Future: Foundations & Practical Steps

Master the Foundations

Data Structures and Algorithms: These are the bedrock of adaptability. Spend time mastering them.
Full-Stack Thinking: The days of specializing in just frontend or backend are fading. Future engineers must be versatile, bridging gaps between design, product management, and data.

Develop Soft Skills

Communication and Collaboration: AI can’t replace human connection. Engineers who can explain complex ideas and work well in teams will stand out.
Leadership: Engineers are becoming leaders - not just of teams, but of AI itself.

Embrace AI as a Creative Partner

Use AI to prototype, automate repetitive tasks, and explore generative tools.
Treat AI like a teammate discuss projects, delegate work, and iterate together.

Stay Adaptable

Tools change, but principles like critical thinking and problem-solving endure.
Focus on learning how to learn. Adaptability will define leadership in the AI era.

📌 In the future, engineers won’t just lead teams - they’ll lead AI too.

Final Thoughts: Are You an AI Zombie or an AI Master?

So, here’s the deal: AI isn’t just knocking on the door - it’s already inside, raiding your fridge and rearranging your code. The question is, are you using AI, or is AI using you?

Let’s talk numbers, because numbers don’t lie (unless they’re generated by AI, of course):

55% of developers are using tools like GitHub Copilot. If you’re not in that 55%, congratulations! You’re officially a manual laborer in a world of cyborgs. Enjoy your handwritten loops and debugging marathons.
Only 30% of those developers accept AI - generated code without changes. If you’re in that 30%, you’re in danger, my friend.

68% of developers (per Stack Overflow 2025) use AI tools daily, cutting repetitive tasks by 40%.

📌 The future isn’t about fearing AI - it’s about mastering it.

Share your thoughts: How are you adapting to AI in your work? Let’s discuss in the comments!
Stay curious: Follow tech blogs, attend webinars, and experiment with AI tools.
Keep learning: The best engineers never stop growing.

Next.js 15 Authentication with nextAuth.js , App Router and Middleware

Taufiqul Islam — Thu, 29 May 2025 15:07:21 +0000

Here's a comprehensive guide to setting up authentication in Next.js 15 using the App Router, middleware, and NextAuth.js.

Folder Structure
Here's a visual representation of the folder structure :

/src/
├── app/
│   ├── auth/
│   │   ├── login/
│   │   │   └── page.tsx
│   │   └── register/
│   │       └── page.tsx
│   ├── dashboard/
│   │   └── page.tsx
│   ├── api/
│   │   └── auth/
│   │       └── [...nextauth]/
│   │           └── route.ts
│   ├── provider.tsx
│   ├── layout.tsx
│   └── page.tsx
├── middleware/
│   └── middleware.ts
├── lib/
│   ├── auth.ts
│   └── next-auth.d.ts

🔐 1. Authentication Setup : /app/api/auth/[...nextauth]/route.ts

Sets up the API route for NextAuth using handlers imported from the central auth config (/lib/auth.ts).

import { GET, POST } from "@/lib/auth";
export { GET, POST };

⚙️ 2. Auth Configuration : /lib/auth.ts
Defines NextAuth options, including the credentials provider, JWT/session callbacks, token refresh logic, and error handling.

import NextAuth, { type NextAuthOptions } from "next-auth";
import Credentials from "next-auth/providers/credentials";

import { AxiosError } from "axios";
import { post } from "./api/handlers";

type LoginResponse = {
  accessToken: string;
  refreshToken: string;

  user: {
    _id: string;
    stdId: string;
    name: string;
    email: string;
    hallName: string;
    description: string;
    role: string;
  };
};

const authOptions: NextAuthOptions = {
  providers: [
    Credentials({
      name: "Credentials",
      credentials: {
        email: { label: "Email", type: "email" },
        password: { label: "Password", type: "password" },
      },
      authorize: async (credentials) => {
        if (credentials === null) throw new Error("Missing credentials");

        try {
          const response = await post<LoginResponse>(
            "/api/auth/login",
            {
              email: credentials?.email,
              password: credentials?.password,
            },
            {
              "Content-Type": "application/json",
            },
          );
          console.log("API Response:", response);

          if (response.accessToken) {
            // Return an object that matches your User interface
            return {
              id: response.user._id,
              email: response.user.email,
              name: response.user.name,
              accessToken: response.accessToken,
              refreshToken: response.refreshToken,
              user: response.user,
            };
          }
          return null;
        } catch (error) {
          if (error instanceof AxiosError) {
            throw new Error(error.response?.data?.message || "Login failed");
          }
          console.error("Authentication error:", error);
          throw new Error("Login failed");
        }
      },
    }),
  ],
  callbacks: {
    jwt: async ({ token, user }) => {
      if (user) {
        // Include both the required fields and your custom data
        token.id = user.id;
        token.email = user.email;
        token.name = user.name;
        token.accessToken = user.accessToken;
        token.refreshToken = user.refreshToken;
        token.user = user.user;
        token.accessTokenExpires = Math.floor(Date.now() / 1000) + 60;
      }
      // Check if the current time is past the access token's expiry time
      const now = Math.floor(Date.now() / 1000);
      if (token.accessTokenExpires && now > token.accessTokenExpires) {
        try {
          // Attempt to refresh the access token
          const response = await post<{ accessToken: string }>(
            "/api/auth/refresh-token",
            {
              refreshToken: token.refreshToken,
            },
            {
              "Content-Type": "application/json",
            },
          );

          // Update the token with the new access token
          token.accessToken = response.accessToken;
          token.accessTokenExpires = now + 60; // Set new expiry time (1 minute from now)
        } catch (error) {
          console.error("Error refreshing access token", error);
          // Handle refresh token error (e.g., redirect to login)
          return { ...token, error: "RefreshAccessTokenError" };
        }
      }

      return token;
    },
    session: ({ session, token }) => {
      if (token) {
        session.user = {
          ...session.user,
          // id: token.id,
          email: token.email,
          name: token.name,
        };
        (session as any).accessToken = token.accessToken;
        (session as any).user = token.user;
      }
      return session;
    },
    redirect: async ({ url, baseUrl }) => {
      // Redirect to login page if there's an error with the refresh token
      if (url === baseUrl) {
        return `${process.env.NEXT_PUBLIC_BASE_URL}/login`;
      }
      return url;
    },
    // authorized: async ({ auth }) => {
    //   return !!auth;
    // },
  },
  pages: {
    signIn: "/login",
    error: "/login",
  },
  session: {
    strategy: "jwt" as const,
  },
  debug: process.env.NODE_ENV === "development",
  secret:
    process.env.NEXTAUTH_SECRET,
};

const handler = NextAuth(authOptions);

export { handler as GET, handler as POST, authOptions };
export const auth = handler.auth;

📄 3. Type Definitions: /lib/next-auth.d.ts
Extends NextAuth types (Session, User, and JWT) to include custom user data like role, hallName, and refreshToken.

import NextAuth from "next-auth";

declare module "next-auth" {
  interface Session {
    accessToken: string;
    refreshToken: string;
    user: {
      _id: string;
      stdId: string;
      name: string | null | undefined;
      email: string | null | undefined;
      hallName: string;
      description: string;
      role: string;
    };
  }

  interface User {
    id: string;
    accessToken: string;
    refreshToken: string;
    user: {
      _id: string;
      stdId: string;
      name: string;
      email: string;
      hallName: string;
      description: string;
      role: string;
    };
  }
}

declare module "next-auth/jwt" {
  interface JWT {
    id?: string;
    email?: string | null;
    name?: string | null;
    accessToken?: string;
    refreshToken?: string;
    accessTokenExpires?: number;
    error?: string;
    user?: {
      _id: string;
      stdId: string;
      name: string;
      email: string;
      hallName: string;
      description: string;
      role: string;
    };
  }
}

🧱 4. Middleware : /middleware/middleware.ts
Protects private routes by checking if the user is authenticated; redirects to login if no valid token is found.

import { NextResponse } from "next/server";
import type { NextRequest } from "next/server";
import { getToken } from "next-auth/jwt";

export async function middleware(request: NextRequest) {
  const token = await getToken({ req: request });

  // Check if the user is trying to access a protected route
  if (!token && !request.nextUrl.pathname.startsWith("/auth/login")) {
    // Redirect to login page if there is no token
    return NextResponse.redirect(new URL("/auth/login", request.url));
  }

  return NextResponse.next();
}

export const config = {
  matcher: [
    "/((?!api|_next/static|_next/image|favicon.ico).*)",
    "/dashboard/:path*",
  ],
};

🧪 5. Session Provider : /app/provider.tsx
Wraps the app with SessionProvider so session data is accessible in all client components.

"use client";

import { SessionProvider } from "next-auth/react";
import React from "react";

interface AuthProviderProps {
  children: React.ReactNode;
}

const AuthProvider: React.FC<AuthProviderProps> = ({ children }) => {
  return <SessionProvider>{children}</SessionProvider>;
};

export default AuthProvider;

🌐 6. Root Layout : /app/layout.tsx
Includes global providers (Auth, React Query, UI layout) and sets up the app’s foundational structure with session support.

// app/layout.tsx
import type { Metadata } from "next";
import { Inter } from "next/font/google";
import "./globals.css";

import { SessionProvider } from "next-auth/react";
import { Toaster } from "react-hot-toast";
import ReactQueryProvider from "@/providers/QueryClientProvider";
import LayoutProvider from "@/providers/LayoutProvider";
import AuthProvider from "./provider";

const inter = Inter({ subsets: ["latin"] });

export const metadata: Metadata = {
  title: "title",
  description: "description",
};

export default async function RootLayout({
  children,
}: Readonly<{
  children: React.ReactNode;
}>) {
  // const session = await auth();

  return (
    <html lang="en" suppressHydrationWarning>
      <head>
        <title>E Delivery Client</title>
      </head>
      <body className={inter.className}>
        <AuthProvider>
          <ReactQueryProvider>
            <LayoutProvider>{children}</LayoutProvider>
          </ReactQueryProvider>
        </AuthProvider>
        <Toaster position="top-right" />
      </body>
    </html>
  );
}

🧠 Accessing Session Data

🧾 Client Component Example:
Uses useSession hook from NextAuth to get and display user session data in client-side components.

"use client";
import { useSession } from "next-auth/react";

export default function DashboardPage() {
  const { data: session, status } = useSession();

  return (
    <div>
      {session ? (
        <p>
          Logged in as name: {session.user.name} Email: {session.user.email}
        </p>
      ) : (
        <p>Not logged in</p>
      )}
    </div>
  );
}

🧾 Server Component Example
Fetches the session using auth() in server components, redirecting unauthenticated users to the login page.

import { auth } from "@/lib/auth";
import { redirect } from "next/navigation";

export default async function ProfilePage() {
  const session = await auth();

  if (!session) {
    redirect("/auth/login");
  }

  return (
    <div className="p-4">
      <h1 className="text-2xl font-bold">Profile</h1>
      <div className="mt-4 space-y-2">
        <p>
          <span className="font-semibold">Email:</span> {session.user.email}
        </p>       
      </div>
    </div>
  );
}

📌 Key Features

✅ Credentials Auth: Uses email & password login via a custom backend.
🔁 Token Refresh: Automatically refreshes JWT access tokens using refresh tokens.
🔒 Protected Routes: Middleware blocks access to routes if not logged in.
🛡️ Type Safety: Custom types improve safety and developer experience.
🔍 Session Access: Available in both server and client components.
🧱 Provider Pattern: Clean separation of logic using dedicated providers.

⚠️ Implementation Notes

Make sure to configure your environment variables properly, especially NEXTAUTH_SECRET
.env example :

NEXT_PUBLIC_BASE_URL=your base url
NODE_ENVL=development
NEXTAUTH_SECRET=hbbinmkbnnkvdfjvskvnkvDDVVfvmndjbvshbvhbrvv=

The middleware checks for authentication status on every route change

The session data includes both standard fields (email, name) and custom fields (role, hallName, etc.)

Error handling is implemented for both login and token refresh operations

This setup provides a solid foundation for authentication in Next.js 15 applications using the App Router, with proper type safety and route protection.

Strapi API with PostgreSQL – Quick Reference 🚀

Taufiqul Islam — Thu, 17 Oct 2024 11:11:05 +0000

Strapi is an open-source headless CMS (Content Management System) built to work with any frontend and any database. It provides developers with a flexible and customizable solution for building content-rich applications, giving them full control over the API, data model, and platform.

Why Strapi? 🏗️

Strapi sets itself apart from other CMS solutions in several ways:

Open-source and Self-hosted: Unlike most CMS platforms, Strapi allows you to self-host your instance, offering greater flexibility, control, and security.
Headless by Design: Strapi is built as a headless CMS, meaning the frontend and backend are decoupled, giving you the freedom to use any frontend technology—React, Vue, Angular, or even native mobile apps.
Customizable APIs: Strapi lets you customize the API for your specific needs, whether it’s REST or GraphQL, making it ideal for projects requiring complex data structures.
Database Agnostic: You can use Strapi with multiple databases like PostgreSQL, MongoDB, MySQL, or SQLite, offering seamless flexibility for different use cases.

This guide provides an overview of basic operations for managing products and images using Strapi, with PostgreSQL as the database. Ensure you have PostgreSQL and PgAdmin 4 installed if you're using PostgreSQL for your Strapi setup.

Prerequisites 🛠️

Install and set up Strapi following the official Strapi Quick Start guide.
Ensure you have PostgreSQL installed in your system.

REST API Overview 🌳

For complete details, refer to the Strapi REST API documentation.

Products Collection API

Assume a Products collection with fields:

Product_name: String (Name of the product)
img: Media (Image ID associated with the product)
state: Boolean (Indicating product status)

1. Get All Products

Retrieve all products with their associated data (including images).

Endpoint:

GET http://localhost:1337/api/products?populate=*

populate=* ensures all relational data, including images, are properly fetched.

2. Upload an Image

Upload an image to the Strapi server.

Endpoint:

POST http://localhost:1337/api/upload/

Request Body: (form-data)

key = files (value is the image file uploaded from your browser).

3. Get All Uploaded Images

Retrieve all uploaded image files.

Endpoint:

GET http://localhost:1337/api/upload/files

4. Add a New Product

Create a new product entry in the Products collection.

Endpoint:

POST http://localhost:1337/api/products

Request Body:

{
    "data": {
        "Product_name": "Samsung S4 old colored",
        "state": true,
        "img": 3 
    }
}

The "img": 3 field refers to the ID of the uploaded image, in this case, image ID 3.

5. Update a Product

Update a specific product using its documentId.

Endpoint:

PUT http://localhost:1337/api/products/:documentId

Request Body:

{
    "data": {
        "Product_name": "Samsung S4 old updated",
        "state": true,
        "img": 3 
    }
}

Here, you update the product name while keeping the image ID (3), which represents the already uploaded image.

📚 This document should serve as a quick reference for managing products and images in Strapi with PostgreSQL. For further customization or detailed configurations, consult the official Strapi documentation.