API Resource Management Prompt

prompt.md

You are a senior full-stack engineer/architect. Build a fully runnable API Resources Management System — a metadata-driven platform where admins define dynamic resource types and users manage records of those types through a generated CRUD UI.

No TODOs, placeholder returns, or // implement later comments — every layer must be complete. Before writing code:

1. Verify the latest stable versions and apply current official best practices for each technology in the stack. Document versions, best-practice decisions, and reference links in the README.
2. If this prompt runs against any existing code (single file, snippet, or full repository), update that code in place to meet the same latest-stable-version and best-practice requirements — do not leave outdated code alongside the new implementation.

---

Stack (minimum versions)

Layer	Tech
Backend	Java 21 · Spring Boot 3.x · Maven · OpenAPI/Swagger · Flyway
DB	PostgreSQL 16 · JSONB + GIN indexes
Auth	Keycloak 24+ (OIDC, JWT)
Frontend	Angular 18+ (standalone components) · npm
Runtime	Node 22 LTS
E2E	Playwright (video recording on)
Infra	Docker Compose · plain Kubernetes manifests

Concept

Admins define dynamic resource types (fields, validations, field-level permissions, lifecycle status). Users manage records of those types through a metadata-driven CRUD UI.

Project structure

backend/     Spring Boot · PostgreSQL · OpenAPI · Flyway · Maven · unit + integration tests
frontend/    Angular standalone · npm
e2e/         Playwright · video on (output = demo video)
k8s/         Plain production Kubernetes manifests
keycloak/    realm-export.json (auto-imported on first boot)
./           Docker Compose · .env.example · README

Auth — Keycloak

Include in Docker Compose and K8s. Mount keycloak/realm-export.json to auto-import a realm with roles ADMIN / USER on first boot. Demo accounts: admin / admin123, user / user123. Backend: validate JWTs, enforce role + field-level permissions, configure CORS. Frontend: login/logout, route guards, Bearer HTTP interceptor, silent token refresh.

Dynamic field types

text · textarea · number · decimal · boolean · date · datetime · email · url · enum · multi-select · reference · attachment Per-field metadata: required · default · options · unique · searchable · filterable · sortable · readRoles · writeRoles + validation rules (min/max, pattern, …).

• reference = typed lookup to another resource type.
• attachment = binary blob in object storage (local volume in dev).

Data model & schema evolution

• Schema storage: relational tables for resource types and field definitions.
• Record storage: PostgreSQL jsonb with GIN indexes; one row per record in a single records table keyed by resource_type_id.
• Schema change policy (must implement): each field change declares an on_change rule — nullable (set null) · default (fill default) · migrate:<expr> (run expression) · restrict (block if non-conforming data exists). Removing a field drops the key from stored JSONB via a data migration.
• Delete semantics: records = soft delete (deleted_at); resource types = archive by default, hard delete only after admin purges all records.
• Concurrency: optimistic locking via version column on resource types and records; HTTP 409 on conflict.

Backend requirements

• Base path /api/v1; all endpoints versioned.
• Admin APIs: create/update/archive/delete resource types; manage fields, validations, permissions, lifecycle.
• User APIs: CRUD / search / filter / sort / paginate records, keyed by resource name. Pagination defaults: page=1, size=20, max=100; sort by any indexed field.
• Server-side metadata-driven validation is the source of truth.
• Field-level permissions enforced server-side via readRoles / writeRoles.
• Events: emit record.created/updated/deleted via Spring ApplicationEventPublisher + optional webhook registry per resource type.
• Rate limiting: per-user on management APIs (Bucket4j or Spring Cloud Gateway); configurable per role.
• Caching: cache compiled resource-type schemas (TTL 60s, invalidate on admin change).
• Bulk import/export: CSV + JSON at /api/v1/{resource}/import and /export.
• Audit logging (who/when/before/after), Spring Boot Actuator (health/readiness/liveness), Micrometer metrics.
• Swagger UI with JWT bearer auth enabled.
• Integration tests use Testcontainers (PostgreSQL — no H2).
• Seed: one sample resource type + sample records on startup.

Frontend requirements

• Admin screens: manage resources, fields, validations, permissions, lifecycle; live form preview; schema-change preview with on_change rule selector.
• User screens: list resources; dynamic forms and tables per resource; inline edit, bulk select, import/export buttons.
• Extract dynamic form renderer and dynamic table renderer as Web Components via Angular Elements.
• Responsive; loading / empty / error states throughout; i18n-ready (Angular i18n); theming via CSS variables.
• Handle 409 conflict and 422 validation errors with user-friendly messages.

Infrastructure

Docker Compose: PostgreSQL · Keycloak · backend · frontend — all locally accessible (frontend, backend API, Swagger UI, Keycloak admin). Every service declares a healthcheck; backend and frontend use depends_on: condition: service_healthy. Kubernetes: namespace · ConfigMaps/Secrets · PostgreSQL PVC · Keycloak · backend · frontend · Services · Ingress · liveness/readiness probes · resource limits · NetworkPolicies.

E2E — one recorded demo flow

1. Log in as admin via Keycloak OIDC redirect.
2. Admin creates and enables a resource type with fields (include a reference and an enum).
3. Admin edits a field with on_change: default and confirms existing records are migrated.
4. Log out; log in as user via Keycloak OIDC redirect.
5. User creates a record → edits it → searches for it → deletes it.
6. Assert record is gone (soft-deleted; hidden from default list).
7. Trigger and assert a field validation error.
8. Trigger and assert a field-level permission error (e.g. user writes a writeRoles: [ADMIN] field).

README

Architecture diagram · local setup · service URLs · demo users · API docs link · run/test/demo commands · K8s deployment steps · versions + reference links · known limitations · future improvements.

---

Finish with a concise summary: features built, commands to run/test/demo, versions used, reference links, known limitations.