Lionel-Dutrieux LunchLab .cursorrules file for C#

Thanks for the clarification! Since your frontend is using **Blazor** and is a separate project from your **headless CMS (Payload CMS 3.0)**, here's how your setup can be organized:

---

### **Tech Stack Overview**

**Backend (Payload CMS 3.0 and Next.js API)**

- **Payload CMS 3.0** will act as your **headless CMS** and handle content management, connected to a **MongoDB** database.
- **Next.js** API routes will serve as the middleware between your **Blazor frontend** and **Payload CMS** (for custom backend logic, if needed).

**Frontend (Blazor)**

- Your **Blazor** project will consume data from **Payload CMS 3.0** via **REST APIs** exposed by **Next.js API routes**.

---

### **Backend Setup (Payload CMS 3.0 & Next.js)**

**1. Content Management with Payload CMS 3.0:**
- Use **Payload CMS 3.0** to manage content like blogs, products, or other dynamic data. It will handle backend content creation, updating, and deletion.
- The **MongoDB** database will store all the content data managed by **Payload CMS**.
  
**2. Next.js API for Backend Logic:**
- Set up **Next.js API routes** to interact with **Payload CMS 3.0**:
    - These routes will fetch data from **Payload CMS** and serve it to the **Blazor frontend** via **RESTful API** calls.
    - Example: Create a route like `/api/posts` to fetch blog posts from **Payload CMS**.

**3. TypeScript for Type Safety:**
- Use **TypeScript** for your backend code (both in **Next.js API routes** and for managing data between **Payload CMS** and **MongoDB**).
- Ensure that types/interfaces are defined for API responses to make development smoother and avoid runtime errors.

---

### **Frontend (Blazor)**

**4. Data Fetching:**
- Your **Blazor** frontend will **consume REST APIs** provided by **Next.js** (e.g., `/api/posts`) to get the data from **Payload CMS**.
- Use **HttpClient** in **Blazor** to fetch data from the backend API.

**5. Styling with Tailwind CSS:**
- Style your **Blazor** components with **Tailwind CSS** for consistency across the frontend.
    - Tailwind can be set up in **Blazor** through CSS or through a framework like **Blazorise** (if you need additional UI components for Blazor).
    - Create reusable **Tailwind CSS** classes for layout, typography, and responsiveness.

**6. Authentication:**
- If you need to authenticate users, handle this either in **Blazor** using **JWT tokens** or via a centralized authentication service (like **OAuth** or **IdentityServer**).
- The **Next.js API routes** can also handle authentication if needed (e.g., for admin panels in Payload CMS).

---

### **API & Data Flow**

**7. Payload CMS & MongoDB:**
- Your **Payload CMS** will provide the data via a **REST API** (exposed through **Next.js API routes**).
- For instance:
    - **Blazor Frontend → Next.js API (e.g., /api/posts) → Payload CMS (MongoDB)**

**8. Next.js API Routes:**
- Use **Next.js API routes** to act as middleware, making sure to fetch data from **Payload CMS** and returning it in a REST-friendly format.
- Example: In your `pages/api/posts.ts` file, you might fetch posts from **Payload CMS** and return them to the **Blazor frontend**.

**9. Handling Requests & Data Fetching in Blazor:**
- In **Blazor**, you will send HTTP requests to the **Next.js API** to fetch data from **Payload CMS**. You can use `HttpClient` in Blazor to manage these calls.
  
```csharp
@inject HttpClient Http

@code {
    private List<Post> posts;

    protected override async Task OnInitializedAsync()
    {
        posts = await Http.GetFromJsonAsync<List<Post>>("/api/posts");
    }
}
```

---

### **Security Considerations**

**10. Secure Data Communication:**
- Ensure that your communication between **Blazor frontend** and **Next.js backend** (and between **Next.js API** and **Payload CMS**) is secure using **HTTPS**.
  
**11. Input Validation and Authentication:**
- If you have any user inputs or sensitive data, make sure to sanitize inputs and implement proper authentication strategies (e.g., JWT tokens, OAuth).
- Use **CORS** if your frontend and backend are hosted on different domains.

---

### **Deployment**

**12. Deployment Workflow:**
- **Frontend (Blazor):** Deploy your **Blazor** app separately. For example, you can deploy it to **Azure** or **Netlify**.
- **Backend (Next.js + Payload CMS):** Host your **Next.js** API on **Vercel** or **AWS**. Ensure **Payload CMS** and **MongoDB** are connected to production environments.

**13. Continuous Integration/Continuous Deployment (CI/CD):**
- Set up CI/CD pipelines for both the frontend and backend to ensure smooth deployment to production.
- Automate tests and deployments with tools like **GitHub Actions**, **GitLab CI**, or **CircleCI**.

---

### **Testing**

**14. Testing Strategies:**
- **Backend (Next.js API):** Test your API routes using **Jest** and **supertest**.
- **Frontend (Blazor):** Test **Blazor** components using **bUnit** or another Blazor testing library.
- Ensure both frontend and backend are covered for unit tests and integration tests.

---

### **Performance & Optimization**

**15. Optimizing API Calls:**
- Use **Next.js's static generation** (`getStaticProps`/`getServerSideProps`) for pages that don’t require frequent real-time updates.
- Optimize **REST API** responses to reduce unnecessary data fetching.

**16. Caching and Lazy Loading:**
- Implement caching on the backend if needed (e.g., caching REST API responses) to improve performance.
- Implement **lazy loading** for images and components in **Blazor** and **Next.js** to improve initial load time.

---

### **Git Commit Message Prompt:**

"Create a **short, concise commit message** in English, utilizing **emojis** to clearly indicate the type of change. The message should briefly describe the change, focusing on the **what** and **why** in one sentence. Follow these guidelines:

1. **Start with an emoji**: Use one of the following emojis based on the change type:
   - `:sparkles:` **for new features or improvements** (e.g., adding a new functionality or enhancing an existing one).
   - `:bug:` **for bug fixes** (e.g., fixing a problem or an error).
   - `:memo:` **for documentation updates** (e.g., updating the README or adding comments).
   - `:art:` **for code refactor** (e.g., cleaning up code, improving structure without changing behavior).
   - `:zap:` **for performance improvements** (e.g., optimizing code for faster execution).
   - `:rocket:` **for deployment or release-related changes** (e.g., preparing for or pushing a release).
   - `:wrench:` **for configuration changes** (e.g., modifying setup files or adjusting settings).
   - `:tada:` **for project initialization or setup** (e.g., creating a new repository or starting a new project).
   - `:lock:` **for security-related changes** (e.g., addressing vulnerabilities or adding authentication).
   - `:heavy_plus_sign:` **for adding dependencies** (e.g., installing a new package or library).
   - `:hammer:` **for heavy changes or refactoring** (e.g., major architectural changes or overhauling code).

2. **Describe the change**: After the emoji, provide a short description of what was changed, added, or fixed. Keep it brief but clear, using **imperative verbs** (e.g., "Add", "Fix", "Update", "Refactor").

### Example Commit Messages:
- `:sparkles: Add user authentication feature`
- `:bug: Fix crash on login screen`
- `:memo: Update README with new API documentation`
- `:art: Refactor user profile component for better readability`
- `:zap: Optimize image loading performance`
- `:rocket: Deploy version 1.0 to production`
- `:wrench: Update config file for CI/CD pipeline`
- `:tada: Initialize project with basic structure`
- `:lock: Add password hashing for enhanced security`
- `:heavy_plus_sign: Add axios package for API requests`

### Best Practices:
- **Be descriptive but concise**: Keep the message under 50 characters, if possible.
- **Avoid vague messages**: Instead of "Fixed issue", specify the actual issue, like "Fix broken navigation bar".
- **Use the emoji to categorize** the commit, making it easy to understand the type of change at a glance.

---