CLAUDE.md Template: SvelteKit + Redis + Custom JWT Memory Auth + RedisOM Pipeline
CLAUDE.md Template for a SvelteKit app using Redis, RedisOM Pipeline, and Custom JWT Memory Auth.
Target User
Frontend and backend developers building SvelteKit apps with Redis-backed authentication
Use Cases
- Build login/logout flows for SvelteKit apps
- Implement token issuance and in-memory token validation
- Leverage RedisOM Pipeline for multi-key fetches
- Orchestrate Redis-based session management
Markdown Template
CLAUDE.md Template: SvelteKit + Redis + Custom JWT Memory Auth + RedisOM Pipeline
# CLAUDE.md
Project role: You are a SvelteKit backend engineer with Redis experience, implementing a memory-based JWT auth flow and RedisOM Pipeline orchestration.
Architecture rules:
- Redis as the source of truth for user data and session state.
- In-memory JWT store per Node process; Redis stores refresh tokens and user metadata for recovery.
- Use RedisOM Pipeline to batch fetch user and permission data in a single round trip when possible.
- Do not bypass RedisOM for batched reads; prefer Pipeline whenever you can combine reads.
- All secrets come from environment variables; never hard-code.
File structure rules:
- src/routes/api/auth/login.ts
- src/routes/api/auth/logout.ts
- src/routes/api/auth/refresh.ts
- src/lib/redis.ts
- src/lib/redisom/models/User.ts
- src/lib/auth/memoryStore.ts
- src/lib/auth/jwtUtil.ts
- src/lib/auth/redisom.ts
- tests/
Authentication rules:
- Use a memory-based access token store (in-memory Map) per Node process.
- Access tokens are JWTs signed with HS256 using JWT_SECRET.
- Refresh tokens are persisted in Redis via RedisOM and rotated on each refresh.
- Do not expose tokens via localStorage; use HTTP-only cookies or Authorization headers as appropriate for your app design (document your choice).
Database rules:
- Use Redis as the main datastore; users, roles, and sessions are RedisOM models.
- Use Redis pipelines for batched reads to reduce round trips.
- Never store secrets in plain text in Redis; hash sensitive fields where possible and use proper expirations.
Validation rules:
- Validate payloads with Zod (login payload: { username, password }).
- Validate JWT structure and expiration on every request.
- Validate RedisOM model schemas before save.
Security rules:
- Do not store plaintext passwords; use password hashes and secure comparison.
- Use HttpOnly cookies or Authorization headers; set SameSite=Lax or Strict as appropriate.
- Rotate refresh tokens and invalidate old tokens.
- Enforce TLS in production.
Testing rules:
- Unit tests for jwtUtil.sign/verify, memoryStore token lifecycle, and RedisOM queries.
- Integration tests for login, refresh, and logout flows using a mocked Redis instance.
- End-to-end tests should cover the happy path and failure cases.
Deployment rules:
- Inject Redis connection details via environment variables (REDIS_HOST, REDIS_PORT, REDIS_PASSWORD).
- Enable Redis TLS in production; configure Redis client accordingly.
- Ensure Node process has enough memory for in-memory token storage and set appropriate memory limits.
- Run tests in CI and gate merges with test results.
Things Claude must not do:
- Do not bypass RedisOM or ignore Pipeline capability for batched reads.
- Do not store tokens in in-memory persistence across restarts without a Redis fallback.
- Do not implement insecure password handling or expose secrets.
- Do not generate code that leaks memory or grows unbounded in the token store.Overview
CLAUDE.md template for a SvelteKit stack using Redis, RedisOM, and a Custom JWT Memory Auth pattern. It targets a memory-based token store with Redis as the authoritative data layer and RedisOM for typed queries.
Direct answer: This CLAUDE.md Template provides a complete blueprint and a copyable Claude Code block to implement a SvelteKit app with Redis-backed auth, an in-memory JWT token store, and a RedisOM Pipeline for efficient data access.
When to Use This CLAUDE.md Template
- You are building a SvelteKit app that requires fast, Redis-backed authentication state while minimizing external dependencies.
- You want an in-process JWT memory store with a Redis fallback/refresh mechanism using RedisOM for multi-key fetches.
- You need a repeatable, copyable CLAUDE.md template to onboard teammates quickly.
- You require a clear architecture and file structure for a Redis-powered authentication flow in a SvelteKit project.
Copyable CLAUDE.md Template
# CLAUDE.md
Project role: You are a SvelteKit backend engineer with Redis experience, implementing a memory-based JWT auth flow and RedisOM Pipeline orchestration.
Architecture rules:
- Redis as the source of truth for user data and session state.
- In-memory JWT store per Node process; Redis stores refresh tokens and user metadata for recovery.
- Use RedisOM Pipeline to batch fetch user and permission data in a single round trip when possible.
- Do not bypass RedisOM for batched reads; prefer Pipeline whenever you can combine reads.
- All secrets come from environment variables; never hard-code.
File structure rules:
- src/routes/api/auth/login.ts
- src/routes/api/auth/logout.ts
- src/routes/api/auth/refresh.ts
- src/lib/redis.ts
- src/lib/redisom/models/User.ts
- src/lib/auth/memoryStore.ts
- src/lib/auth/jwtUtil.ts
- src/lib/auth/redisom.ts
- tests/
Authentication rules:
- Use a memory-based access token store (in-memory Map) per Node process.
- Access tokens are JWTs signed with HS256 using JWT_SECRET.
- Refresh tokens are persisted in Redis via RedisOM and rotated on each refresh.
- Do not expose tokens via localStorage; use HTTP-only cookies or Authorization headers as appropriate for your app design (document your choice).
Database rules:
- Use Redis as the main datastore; users, roles, and sessions are RedisOM models.
- Use Redis pipelines for batched reads to reduce round trips.
- Never store secrets in plain text in Redis; hash sensitive fields where possible and use proper expirations.
Validation rules:
- Validate payloads with Zod (login payload: { username, password }).
- Validate JWT structure and expiration on every request.
- Validate RedisOM model schemas before save.
Security rules:
- Do not store plaintext passwords; use password hashes and secure comparison.
- Use HttpOnly cookies or Authorization headers; set SameSite=Lax or Strict as appropriate.
- Rotate refresh tokens and invalidate old tokens.
- Enforce TLS in production.
Testing rules:
- Unit tests for jwtUtil.sign/verify, memoryStore token lifecycle, and RedisOM queries.
- Integration tests for login, refresh, and logout flows using a mocked Redis instance.
- End-to-end tests should cover the happy path and failure cases.
Deployment rules:
- Inject Redis connection details via environment variables (REDIS_HOST, REDIS_PORT, REDIS_PASSWORD).
- Enable Redis TLS in production; configure Redis client accordingly.
- Ensure Node process has enough memory for in-memory token storage and set appropriate memory limits.
- Run tests in CI and gate merges with test results.
Things Claude must not do:
- Do not bypass RedisOM or ignore Pipeline capability for batched reads.
- Do not store tokens in in-memory persistence across restarts without a Redis fallback.
- Do not implement insecure password handling or expose secrets.
- Do not generate code that leaks memory or grows unbounded in the token store.
Recommended Project Structure
src/
lib/
redis.ts # Redis client setup
redisom.ts # RedisOM helpers and models
auth/
memoryStore.ts # In-memory JWT store (per-process)
jwtUtil.ts # JWT signing/verification
redisom.ts # RedisOM pipeline helpers
routes/
api/
auth/
login.ts
refresh.ts
logout.ts
tests/
+layout.svelte
+page.svelte
vite.config.ts
package.json
Core Engineering Principles
- Single source of truth for user data in Redis; memory store is transient.
- Prefer RedisOM with Pipeline for efficient batched queries.
- Keep secrets in environment variables; never hard-code.
- Validate all inputs and handle errors gracefully without leaking internals.
- Favor explicit, typed contracts between layers (DTOs and models).
Code Construction Rules
- Use TypeScript strict mode; define interfaces for request/response payloads.
- Encapsulate JWT logic in a dedicated module (jwtUtil.ts).
- Encapsulate RedisOM pipeline usage in a dedicated module (redisom.ts).
- Do not mix in-memory tokens with Redis store across modules without clear boundaries.
- Keep API routes lean; delegate business logic to services in src/lib.
Security and Production Rules
- Protect in-memory tokens with process isolation; limit per-process memory growth.
- Use secure cookies or Authorization headers; set HttpOnly, Secure, SameSite attributes in production.
- Enable TLS, rotate JWT secret periodically, and implement token revocation strategy (via RedisOM).
- Audit Redis access with proper key namespaces and expirations.
Testing Checklist
- Unit tests for jwtUtil and memoryStore token lifecycle.
- Integration tests for login, refresh, and logout flows using a mocked Redis server.
- End-to-end tests that cover happy path and edge cases (expired tokens, revoked tokens).
- Performance checks for RedisOM PipelineBatch reads.
Common Mistakes to Avoid
- Storing tokens in memory without a Redis fallback in production.
- Ignoring RedisPipeline capabilities for batched reads.
- Weak password handling or missing token rotation on refresh.
- Hard-coding secrets or exposing them in client-side code.
Related implementation resources: AI Use Case for Software Agencies Using Github Copilot To Accelerate Boilerplate Code Generation for New Client Mvps and Identifying lookalike enterprise accounts with AI pipelines.
FAQ
What is this CLAUDE.md Template for SvelteKit with RedisOM Pipeline?
A copyable Claude Code blueprint to implement a Redis-backed SvelteKit app with in-memory JWT authentication and RedisOM Pipeline.
Should I rely on in-memory JWTs in production?
In-memory tokens are ephemeral per process. For production, plan a Redis-backed session or a token revocation strategy.
What benefits does RedisOM Pipeline provide here?
It batches multiple Redis calls to reduce latency and improve throughput for user data and permissions lookup.
How do I test the template's authentication flow?
Write unit tests for jwtUtil and memoryStore, integration tests for login/refresh/logout, and end-to-end tests for happy path and failure modes.