| Dimension | Shared | Only in A | Only in B | Overlap |
|---|---|---|---|---|
| Sections | 0 | 1 | 1 | 0% |
| Commands | 0 | 0 | 8 | 0% |
| Section tags | 0 | 1 | 0 | 0% |
What each file covers
Sections
0 shared · 1 only in A · 1 only in B- − ClickHouse Conventions
- + Infrastructure
Commands
0 shared · 0 only in A · 8 only in B- + docker compose -f docker/local/docker-compose.yml up -d
- + docker compose -f docker/local/docker-compose.agent.yml up -d
- + pnpm start:api:dev
- + pnpm start:worker
- + pnpm start:ws
- + docker compose
- + pnpm build
- + pnpm build:agents
Section tags
0 shared · 1 only in A · 0 only in B- − code-style
Line diff
novuhq/novu · .cursor/rules/clickhouse.mdc
@@ −1 @@
1---
2description: Rules for working with ClickHouse analytics and trace logging
3globs:
4 - "**/analytic-logs/**"
5 - "**/clickhouse-migrations/**"
6alwaysApply: false
7---
8
9### ClickHouse Conventions
10
11**Service layer**
12- Use `ClickHouseService` for single queries/inserts and `ClickHouseBatchService` for high-throughput writes.
13- Both are registered as custom providers (`clickHouseService`, `clickHouseBatchService`) in each app's `shared.module.ts`.
14- Never instantiate ClickHouse clients directly — always inject the providers.
15
16**Repositories**
17- All ClickHouse repositories extend `LogRepository` in `libs/application-generic/src/services/analytic-logs/`.
18- Each repository has a corresponding schema file defining the table columns and types.
19- Always include `_environmentId` and `_organizationId` in queries for tenant isolation (same pattern as MongoDB DAL).
20
21**Migrations**
22- ClickHouse migrations are numbered `.sql` files in `apps/api/migrations/clickhouse-migrations/`.
23- Run locally with `cd apps/api && pnpm run clickhouse:migrate:local`.
24- New migrations must be additive — never alter or drop columns that existing queries depend on. Use temp tables and exchange patterns for schema refactors (see migration 4/5 for the established pattern).
25
26**Feature flags**
27- Gate new ClickHouse-dependent behavior behind a feature flag (see `packages/shared/src/types/feature-flags.ts` for existing flags like `IS_CLICKHOUSE_BATCHING_ENABLED`).
28
novuhq/novu · .cursor/rules/infrastructure.mdc
@@ +1 @@
1---
2description: Infrastructure setup, Docker services, and environment configuration
3globs:
4 - "docker/**/*"
5 - "*.env*"
6 - ".env*"
7 - "**/docker-compose*"
8alwaysApply: false
9---
10
11## Infrastructure
12
13**Start all services:** `docker compose -f docker/local/docker-compose.yml up -d`
14
15**Agent environments** use a separate compose file — restart after a reboot with:
16`docker compose -f docker/local/docker-compose.agent.yml up -d`
17
18| Service | Port | Purpose |
19|---------|------|---------|
20| MongoDB | 27017 | Primary database |
21| Redis | 6379 | Caching + Bull queues |
22| ClickHouse | 8123 (HTTP) / 9000 (native) | Analytics, activity feed, traces |
23| LocalStack | 4566 | S3 emulation (optional) |
24
25**Services needed per task:**
26- Dashboard UI only: nothing (user has it running on port 4201)
27- API endpoints: `pnpm start:api:dev`
28- Notification flows: API + `pnpm start:worker`
29- Real-time features: API + Worker + `pnpm start:ws`
30- Full stack: `docker compose` + all of the above
31
32Run `pnpm build` before starting services only if changes were made to `libs/`, `packages/`, or `enterprise/`. Cloud agent install/update uses `pnpm build:agents`, which skips full app builds but still runs `@novu/api-service:build:metadata` (apps otherwise build when their dev servers start).
@@ −1 +1 @@
11 ---
2−description: Rules for working with ClickHouse analytics and trace logging
2+description: Infrastructure setup, Docker services, and environment configuration
33 globs:
4− - "**/analytic-logs/**"
5− - "**/clickhouse-migrations/**"
4+ - "docker/**/*"
5+ - "*.env*"
6+ - ".env*"
7+ - "**/docker-compose*"
68 alwaysApply: false
79 ---
810
9−### ClickHouse Conventions
11+## Infrastructure
1012
11−**Service layer**
12−- Use `ClickHouseService` for single queries/inserts and `ClickHouseBatchService` for high-throughput writes.
13−- Both are registered as custom providers (`clickHouseService`, `clickHouseBatchService`) in each app's `shared.module.ts`.
14−- Never instantiate ClickHouse clients directly — always inject the providers.
13+**Start all services:** `docker compose -f docker/local/docker-compose.yml up -d`
1514
16−**Repositories**
17−- All ClickHouse repositories extend `LogRepository` in `libs/application-generic/src/services/analytic-logs/`.
18−- Each repository has a corresponding schema file defining the table columns and types.
19−- Always include `_environmentId` and `_organizationId` in queries for tenant isolation (same pattern as MongoDB DAL).
15+**Agent environments** use a separate compose file — restart after a reboot with:
16+`docker compose -f docker/local/docker-compose.agent.yml up -d`
2017
21−**Migrations**
22−- ClickHouse migrations are numbered `.sql` files in `apps/api/migrations/clickhouse-migrations/`.
23−- Run locally with `cd apps/api && pnpm run clickhouse:migrate:local`.
24−- New migrations must be additive — never alter or drop columns that existing queries depend on. Use temp tables and exchange patterns for schema refactors (see migration 4/5 for the established pattern).
18+| Service | Port | Purpose |
19+|---------|------|---------|
20+| MongoDB | 27017 | Primary database |
21+| Redis | 6379 | Caching + Bull queues |
22+| ClickHouse | 8123 (HTTP) / 9000 (native) | Analytics, activity feed, traces |
23+| LocalStack | 4566 | S3 emulation (optional) |
2524
26−**Feature flags**
27−- Gate new ClickHouse-dependent behavior behind a feature flag (see `packages/shared/src/types/feature-flags.ts` for existing flags like `IS_CLICKHOUSE_BATCHING_ENABLED`).
25+**Services needed per task:**
26+- Dashboard UI only: nothing (user has it running on port 4201)
27+- API endpoints: `pnpm start:api:dev`
28+- Notification flows: API + `pnpm start:worker`
29+- Real-time features: API + Worker + `pnpm start:ws`
30+- Full stack: `docker compose` + all of the above
2831
32+Run `pnpm build` before starting services only if changes were made to `libs/`, `packages/`, or `enterprise/`. Cloud agent install/update uses `pnpm build:agents`, which skips full app builds but still runs `@novu/api-service:build:metadata` (apps otherwise build when their dev servers start).
