How 05t3/sigmarulegen works
1. Overall shape
- This is a small full-stack TypeScript web application for generating Sigma detection rules.
- The architecture is centered on a React/Vite SPA in client/, supported by a Node server in server/ that serves the app and exposes route-level behavior.
2. Primary user-facing flow
- The browser loads the SPA, the user fills out a Sigma rule form, and the app continuously converts that form state into a live YAML preview.
- The same generated rule can then be copied to clipboard or downloaded as a .yml file.
- So the core data flow is: form input → validated rule state → YAML rendering → export.
3. Frontend application boundary
- client/src/App.tsx and client/src/pages/sigma-generator.tsx appear to be the main entry points for the rule-building experience.
- The frontend is structured as a classic component-driven SPA with pages, reusable components, hooks, and shared utilities.
- There are additional pages for About and Not Found, indicating a small routed UI rather than a single-screen widget.
4. Form and rule-generation subsystem
- The main domain-specific subsystem is the Sigma rule generator form, centered around sigma-form.tsx and use-sigma-form.ts.
- This subsystem likely owns the structured rule fields, validation, and transformation into Sigma YAML.
- yaml-preview.tsx is the presentation layer for the generated rule output, keeping input editing and output rendering tightly coupled but still separated in components.
5. Shared domain model
- shared/schema.ts is the main boundary for shared validation/type definitions between client and server.
- drizzle.config.ts suggests the repo was set up with schema-driven data modeling, even though the tree does not show a full persistent database implementation.
- For an architecture diagram, treat shared/ as the contract layer that keeps client and server aligned on rule structure.
6. Server responsibilities
- The server side is relatively thin: server/index.ts, server/routes.ts, server/storage.ts, and server/vite.ts.
- Its likely responsibilities are:
- bootstrapping the Node process,
- wiring routes,
- serving the Vite-built frontend in production,
- and providing any minimal backend API or persistence abstraction.
- The presence of storage.ts suggests a storage interface, but the repository layout does not indicate a heavy backend datastore.
7. UI and design system
- The frontend uses a component library approach with many reusable UI primitives under client/src/components/ui/.
- theme-provider.tsx and the large set of UI components indicate a strong presentation layer built around reusable, composable controls.
- This is supported by Tailwind (tailwind.config.ts, postcss.config.js) and likely a shadcn-style component stack (components.json).
8. Client-side state and utilities
- client/src/hooks/ contains custom hooks for mobile responsiveness, toast notifications, and form logic.
- client/src/lib/ holds small shared utilities, constants, and query client setup.
- queryClient.ts indicates React Query is available, even if the app’s main workflow is mostly local UI state rather than server synchronization.
9. Static assets and visual output
- assets/ contains screenshots used in documentation, reinforcing that the app’s value is primarily in the generated rule preview and UI usability.
- The frontend includes a dedicated preview component and a theme switcher, so the UI is optimized for human review of generated YAML, not just data entry.
10. Runtime and deployment model
- The repo is built for local development and containerized deployment.
- There are Docker assets at the root and under Docker/, including separate compose files for normal use, dev mode, Traefik, and Loki-based logging.
- This suggests the app can run as a self-contained containerized service with optional reverse proxy and observability layers.
11. Build and packaging pipeline
- vite.config.ts, tsconfig.json, and the Dockerfiles show a standard TypeScript/Vite build pipeline.
- The root Dockerfile and Docker/Docker DEV/* separate production and development container flows.
- The application is meant to be built into static frontend assets plus a lightweight Node runtime for serving them.
12. Automation and security scanning
- .github/workflows/ includes image builds and multiple security checks: CodeQL, Snyk scans, and Trivy.
- This is a notable operational boundary: the repo is designed not just to run, but to be continuously scanned and published as container images.
13. What to show in an architecture diagram
- The main boxes should be:
- Browser / React SPA
- Form + YAML generation logic
- Shared schema/types
- Node server / route layer
- Container build and deployment
- The dominant data path is client-local rule generation, with the server mainly acting as the delivery/runtime shell rather than a complex business-logic backend.
Main entry points: App.tsx App shell · Dockerfile Dockerfile · index.ts Server entry · use-sigma-form.ts Form state
Components 31
Client app
React/Vite SPA for building and previewing Sigma rules.
- App shell · Top-level SPA composition and route wiring.
client/src/App.tsx - Boot entry · Client-side runtime entrypoint.
client/src/main.tsx - Rule page · Primary Sigma generator page and user flow container.
client/src/pages/sigma-generator.tsx - About page · Informational page for the app.
client/src/pages/about.tsx - 404 page · Fallback route for unmatched paths.
client/src/pages/not-found.tsx - Sigma form · Structured rule editor and field input layer.
client/src/components/sigma-form.tsx - YAML preview · Renders the generated Sigma YAML for review and export.
client/src/components/yaml-preview.tsx - Form state · Owns form state, validation, and rule generation logic.
client/src/hooks/use-sigma-form.ts - Mobile hook · Responsive UI behavior for smaller screens.
client/src/hooks/use-mobile.tsx - Toast hook · Client notification helper for copy/export feedback.
client/src/hooks/use-toast.ts - Theme provider · Theme and appearance context for the SPA.
client/src/components/theme-provider.tsx - UI primitives · Reusable shadcn-style controls and layout primitives.
client/src/components/ui/button.tsx - Query client · Shared client-side data/query configuration.
client/src/lib/queryClient.ts - Sigma utils · Rule-related helper functions and transformations.
client/src/lib/sigma-utils.ts - Sigma constants · Shared Sigma-specific option and value definitions.
client/src/lib/sigma-constants.ts
Server runtime
Node layer that serves the app and wires routes.
- Server entry · Starts the Node process and initializes the server.
server/index.ts - Routes · Defines server endpoints and request handling.
server/routes.ts - Storage · Abstraction for any backend storage behavior.
server/storage.ts - Vite bridge · Connects the server runtime to the Vite app build.
server/vite.ts
Shared contract
Common schema and types used across client and server.
- Schema types · Validation and type definitions shared by client and server.
shared/schema.ts
Packaging
Container and build assets for local and deployed runtime.
- Dockerfile · Production container image definition.
Dockerfile - Dev Dockerfile · Development container image definition.
Docker/Docker DEV/Dockerfile.dev - Compose stack · Production container composition for running the app.
docker-compose.yml - Dev compose · Development container composition.
Docker/Docker DEV/docker-compose.yml - Traefik stack · Reverse-proxy deployment variant.
Docker/Docker Compose/docker-compose-traefik.yml - Loki stack · Logging/observability deployment variant.
Docker/Docker Compose/docker-compose-loki.yml
Automation
CI workflows for image builds and security scanning.
- Build images · Automates container image builds and publication.
.github/workflows/build-images.yml - CodeQL · Static security analysis workflow.
.github/workflows/codeql-analysis.yml - Snyk DockerHub · Container scan workflow for DockerHub images.
.github/workflows/snyk-dockerhub-scan.yml - Snyk GHCR · Container scan workflow for GitHub Container Registry images.
.github/workflows/snyk-gchr-scan.yml - Trivy scan · Container vulnerability scanning workflow.
.github/workflows/trivy.yml
Connections 30
- Boot entry → App shell: mounts · Bootstraps the SPA root.
- App shell → Rule page: routes to · Primary app route for generator experience.
- App shell → About page: routes to · Auxiliary informational page.
- App shell → 404 page: fallback · Handles unmatched routes.
- Rule page → Sigma form: uses · Embeds the rule editing form.
- Rule page → YAML preview: renders · Shows generated YAML alongside editing.
- Sigma form → Form state: drives · Form UI is backed by rule state and generation logic.
- Form state → Schema types: validates · Uses shared schema for shape and constraints.
- Form state → Sigma utils: transforms · Converts form state into Sigma rule output.
- Form state → Sigma constants: reads · Consumes Sigma-specific constants.
- YAML preview → Toast hook: feedback · Supports copy/export notifications.
- App shell → Theme provider: wraps · Provides theme context to the SPA.
- App shell → UI primitives: composes · Built from shared UI primitives.
- App shell → Mobile hook: adapts · Responsive behavior for smaller screens.
- App shell → Query client: initializes · Shared client query/cache setup.
- Server entry → Routes: wires · Registers the route layer.
- Server entry → Vite bridge: serves · Connects runtime to Vite in development or production.
- Routes → Storage: uses · Route handlers rely on storage abstraction when needed.
- Routes → Schema types: shares contract · Aligns server behavior with shared validation types.
- Dockerfile → Server entry: packages · Builds the server-backed application image.
- Dev Dockerfile → Server entry: runs · Development container starts the app server.
- Compose stack → Dockerfile: builds · Production compose uses the production image.
- Dev compose → Dev Dockerfile: builds · Development compose uses the dev image.
- Traefik stack → Compose stack: extends · Reverse-proxy variant built around the main stack.
- Loki stack → Compose stack: extends · Observability variant built around the main stack.
- Build images → Dockerfile: builds · CI builds the production container image.
- CodeQL → Server entry: scans · Static analysis covers application code.
- Trivy scan → Dockerfile: scans · Scans the built container image.
- Snyk DockerHub → Dockerfile: scans · Scans DockerHub-bound image artifacts.
- Snyk GHCR → Dockerfile: scans · Scans GitHub Container Registry image artifacts.