Cursor Rules Template: Node Express PostgreSQL Community Platform

Overview

This Cursor Rules Template provides a complete, copyable configuration for building a community platform with memberships, discussions, events, payments, and moderation tools using a Node.js/Express backend and PostgreSQL as the data store. It includes a direct answer style summary for quick reference and a comprehensive set of rules to guide architecture, security, testing, and Cursor AI usage in production.

Direct answer: Paste the .cursorrules block from the Copyable Configuration section into the root of your project to enforce stack-specific conventions, security patterns, and integration guidelines for a Node.js/Express + PostgreSQL community platform powered by Cursor AI.

When to Use These Cursor Rules

Starting a new community platform with tiered memberships and paid events.
Implementing discussions, threads, and event scheduling with reliable data models.
Integrating payments (Stripe) for memberships and event tickets.
Enforcing moderation workflows and audit logging to protect users.
Ensuring secure authentication, token handling, and API design.

Copyable .cursorrules Configuration

// Cursor Rules Template for Node.js/Express + PostgreSQL Community Platform
framework: Node.js (Express) + PostgreSQL + Stripe + Redis
roles: Architect, Backend Lead, Security Engineer
context: Build a membership-based community platform with discussions, events, payments, and moderation tools; Cursor AI should guide safe coding and architecture.
codeStyle: TypeScript, ESLint, Prettier; strict DTOs; explicit types; no any
architecture:
  - apps/api: Express API server
  - apps/web: Next.js frontend
  - libs/db: PostgreSQL data access layer
  - libs/auth: authentication & authorization
  - libs/payments: Stripe integration
  - libs/moderation: moderation and auditing
  - tests: unit & integration tests
directoryRules:
  - place DB access in libs/db; API routes in apps/api; UI in apps/web
  - service/business logic belongs in libs (not in routes)
  - avoid circular imports; centralize config in environment files
authenticationSecurity:
  - use JWTs with RS256; store access tokens in httpOnly cookies
  - implement token rotation for refresh tokens
  - CSRF protection for web flows; enforce sameSite=lax/strict
  - forbid secret keys in logs; load via environment vars
databasePattern:
  - PostgreSQL 12+; use connection pooling; migrations via migrations/ directory
  - schemas: public.members, public.discussions, public/posts, public/events, public/payments, public/moderation_logs
  - use transactions for multi-step updates; index foreign keys and search columns
  - parameterized queries; avoid string concatenation in SQL
testingLinting:
  - unit tests for utilities and services (Jest + ts-jest)
  - integration tests for API endpoints (supertest)
  - lint with ESLint + Prettier; type checks with TypeScript; CI runs on push/PR
securityProduction:
  - enforce TLS; secrets stored in environment; rotate keys regularly
  - rate limiting; input validation; output encoding; CSP where applicable
  - log only non-sensitive data; redact PII in logs
prohibitedActions:
  - do not log secrets or tokens
  - do not bypass authentication checks
  - do not use eval or dynamic code execution
antiPatterns:
  - avoid monolithic routes; prefer modular services
  - avoid embedding secrets in code or client bundles
  - avoid performing business logic in route handlers

Recommended Project Structure

Stack-specific directory tree for a Node.js/Express + PostgreSQL community platform:

project-root/
  apps/
    api/
      src/
        controllers/
        routes/
        services/
        middlewares/
        database/
      package.json
    web/
      src/
        pages/
        components/
      next.config.js
      package.json
  libs/
    db/
      migrations/
      src/
    auth/
    payments/
    moderation/
  tests/
  .env.example

Core Engineering Principles

Security by default: TLS, secret management, and asset protection
Modularity: clear separation between API, frontend, and shared libs
Testability: unit, integration, and end-to-end tests with CI
Observability: structured logs, metrics, and tracing
Reliability: idempotent endpoints and robust error handling

Code Construction Rules

API routes live under apps/api/src; business logic in libs; controllers call services
Use TypeScript types for request/response DTOs; validate with runtime schemas
All database access uses parameterized queries; avoid string interpolation
Transactions must wrap multi-step writes (e.g., membership purchase + event registration)
Authentication middleware enforces access control for protected routes
Payments flows use idempotent operations and Webhook verification
Cursor AI rules guide data handling, logging, and safe feature usage
Do not rely on client-side tokens for authorization; always verify on server

Security and Production Rules

Store secrets in environment variables; never commit them
Use httpOnly secure cookies for access tokens
Rotate refresh tokens and implement token revocation lists
Enforce input validation, output encoding, and CSRF protection
Apply rate limiting, IP blocking, and monitoring for abuse
Audit moderation actions and maintain an immutable log where feasible

Testing Checklist

Unit tests for utilities, DTOs, and services
Integration tests for API endpoints with realistic payloads
End-to-end tests for membership checkout flow and event creation
Linting and type checks in CI; run migrations against a test DB
Security tests: CSRF, token rotation, and permission checks

Common Mistakes to Avoid

Overly permissive authorization checks or missing role validation
Hardcoding secrets or keys in code or client bundles
String-concatenated SQL that risks injection; prefer parameterized queries
Neglecting input validation and server-side validation requirements
Ignoring moderation audit trails and event logging

Related Cursor rules templates

Explore adjacent Cursor rules templates for similar stacks, workflows, and production constraints.

FAQ

What stack is this Cursor Rules Template designed for?

This template targets a Node.js/Express backend with PostgreSQL, a Next.js frontend, Stripe for payments, and Cursor AI rules to guide safe AI-assisted development.

How do I use the copyable .cursorrules block?

Copy the block from the Copyable Configuration section and place it in a file named .cursorrules at the project root. It enforces architecture, security, and workflow conventions for this stack.

How are memberships and events modeled?

Memberships map to a public.memberships-like table with tiered access, while events are modeled in public.events with registrations. Transactions are atomic and rolled back on failure.

What about moderation and auditing?

Moderation actions are recorded in a separate moderation_logs table, with immutable, timestamped records and role-based access controls to protect integrity.

What should I test before deployment?

Run unit and integration tests, perform API security checks, verify payment workflows, and ensure migrations run in CI against a test database before deployment.

Target User

Use Cases