Stack tehnologic

Tabel de referință pentru stack-ul ASYDATA. Sursa autoritativă a deciziilor actuale este asydata-app-backend-dotnet/CLAUDE.md (cu detalii în docs/DECISIONS.md); docs/ARCHITECTURE.md conține propunerea inițială, din care unele elemente au fost ulterior respinse — marcate mai jos.

Backend

Aria	Tehnologie	Note
Runtime	.NET 10 LTS, C# 14	suport până nov. 2028
Web framework	ASP.NET Core Minimal API	OpenAPI 3.1 nativ + Scalar UI la /scalar/v1
Arhitectură	Clean Architecture (Domain ← Application ← Platform ← Infrastructure ← WebApi)	service pattern, Result<T> — vezi Clean Architecture
Modularitate	Module Odoo-style (IAsyModule, src/Modules/Asy.Modules.*)	assembly scan la startup
ORM	EF Core 10 + Npgsql, AddPooledDbContextFactory<T>	DbContext pooling
Bază de date	PostgreSQL	pooled multi-tenant, RLS pe firm_id — vezi Multi-tenancy
Mesagerie	Confluent.Kafka direct + outbox propriu	topic firm.events — vezi Event-driven
Search	Elasticsearch 9 + Elastic.Clients.Elasticsearch	full-text, multilingv (planificat)
Storage fișiere	MinIO (self-host, S3-compatible)	PDF-uri, atașamente (planificat)
Realtime	SignalR	când va fi nevoie
Auth	ASP.NET Core Identity nativ + Google OAuth	vezi Autentificare
Observability	Serilog + OpenTelemetry + Sentry	logging structurat, tracing, error tracking
Testing	xUnit + Testcontainers / WebApplicationFactory	teste pe servicii reale
Orchestrare dev	Docker Compose (Postgres + Kafka + ES + MinIO + UIs)	infra/docker-compose.yml
Orchestrare prod	Kubernetes self-host (kubeadm + Rancher + Harbor + NFS)	Helm charts
Reverse proxy	Caddy	servește SPA + rutează /api/*

Stare de implementare

Implementate astăzi: WebApi (modular monolith), EF Core + Postgres + migrations, Identity + Google OAuth, outbox + Kafka + worker Telegram/WebPush. Planificate (interfețe prezente, wiring în roadmap): indexer Elasticsearch, MinIO, SignalR, auth full (refresh/MFA).

Frontend

Aria	Tehnologie
Framework	React 19
Build	Vite
Routing / data	TanStack Router + Query
Styling	Tailwind
Deployment	build static → wwwroot/, servit de Caddy (single-deployment, same-origin)

Decizii explicit refuzate

Sursa: CLAUDE.md / docs/DECISIONS.md. NU se sugerează alternative la stack — aceste opțiuni au fost respinse deliberat:

Respins	Motiv
Wolverine	preferință pentru control total, fără framework de messaging (outbox + Kafka direct)
MediatR	comercial din 2025; oricum fără CQRS — service pattern clasic
MassTransit	comercial din 2026
CQRS / dispatcher	service pattern clasic e suficient pentru nevoile actuale
Keycloak	totul în ASP.NET Core Identity nativ (PII sub jurisdicția noastră)
Supabase	independență de vendor — Postgres self-managed
.NET Aspire	Docker Compose e suficient și transparent
Schema-per-tenant / DB-per-tenant	operare scumpă; izolarea RLS pooled e suficientă
Dapper ca ORM primar	EF Core (migrations native, DbContextFactory)
Cod customer la runtime (eval / DLL-uri dinamice)	toate modulele sunt în binar
UNIQUE pe IDNO	IDNO nu e unic și nu e validat — admin verifică manual

Discrepanță cu docs vechi

docs/ARCHITECTURE.md listează Wolverine, Keycloak, CQRS și .NET Aspire ca parte a propunerii. Sunt deprecate — reflectă o iterație anterioară. Stack-ul valid e cel din acest tabel.

Pending (decizii de la dev — Alex Cozlovschi)

Neconfirmate încă (docs/DECISIONS.md, docs/AUTH.md):

• Token flow peste Identity: BearerToken nativ vs OpenIddict vs cookie pur (BFF). Inclusiv întrebarea „JWT cu client certificate” (mTLS / RFC 8705 / RS256-with-cert) — de clarificat.
• Cluster K8s prod: DOKS / AKS / Hetzner managed K3s / self-hosted bare?
• Postgres pe NFS vs local PV + CloudNativePG?
• Sidecar deploy: 1 pod per tenant vs shared core + sidecars per-tenant?
• Volum estimat: câți tenants în 12 luni? (dimensionare cluster + sharding viitor)

Legături

• Cum se compun componentele: Context de sistem.
• Straturile și modulele: Clean Architecture + module.
• Izolarea datelor: Multi-tenancy și RLS.
• Diagramele vizuale: ASYDATA pe Figma.