Prezentare generală
Funcțiile logice rulează în sandbox în procese Node.js de scurtă durată — odată ce o rulare se termină, nimic din ce a fost păstrat în memorie nu supraviețuiește. Când ai nevoie să îți amintești ceva între rulări (să pui în cache un răspuns API costisitor, să stochezi un cursor pentru sincronizări incrementale, să aplici debounce sau să transmiți starea de la o funcție la alta), salvează-l în spațiul de stocare cheie-valoare integrat. Fiecare aplicație primește propriul spațiu de nume izolat: intrările sunt asociate cu aplicația autentificată, astfel încât cheile tale nu pot intra niciodată în coliziune cu — sau fi citite de — o altă aplicație. Magazinul este persistent: înregistrările sunt stocate în baza de date PostgreSQL a instanței — nu într-un cache în memorie precum Redis — astfel încât acestea supraviețuiesc repornirilor serverului, implementărilor și actualizărilor aplicației și rămân disponibile până când le ștergeți. Acest lucru îl face fiabil pentru stări durabile, precum cursorii de sincronizare sau configurația per utilizator, nu doar pentru cache-uri de scurtă durată. Valorile sunt stocate ca JSON simplu, fără criptare la nivel de aplicație, așa că nu introduceți secrete în el — păstrați cheile API și alte date de autentificare în variabilele secrete ale aplicației sau ale serverului, care sunt criptate în repaus.Get, set, delete
Importațikv din twenty-sdk/logic-function. Valorile pot fi orice payload serializabil JSON.
src/logic-functions/sync-linear-issues.ts
Domenii de aplicare
Fiecare intrare are un domeniu de aplicare, transmis ca opțiune la fiecare apel. Valoarea implicită esteWORKSPACE.
WORKSPACE(implicit) — intrarea este privată pentru instalarea curentă a workspace-ului aplicației tale. Fiecare workspace care instalează aplicația primește propriul set independent de chei. Aceasta este opțiunea potrivită pentru cache-uri, cursoare și stare specifică fiecărui workspace.SERVER— intrarea este partajată între fiecare instalare a aplicației tale de pe server. Intrările de tip server se comportă ca niște claim-uri: valoarea stocată este întotdeauna workspaceId-ul care a revendicat cheia (omitevaluelasetpentru a revendica cheia pentru workspace-ul curent), iar doar acel workspace o poate suprascrie sau șterge. Orice instalare poate citi intrarea.
kv.set aruncă o eroare atunci când cheia este deja revendicată de un alt workspace.
Folosește-l: păstrează în cache un apel costisitor
O utilizare tipică este păstrarea în cache a unui răspuns lent sau cu limitare de rată de la un terț, astfel încât rulările repetate să îl refolosească în loc să plătească costul de fiecare dată.src/logic-functions/getExchangeRate.logic-function.ts
Tipare și sfaturi
- Spații de nume. Prefixează cheile pentru a păstra domeniile diferite separate —
sync-cursor:linear,cache:exchange-rate:USD:EUR,lock:nightly-report. - Expiry (TTL). Store-ul nu are expirare integrată. Stochează un timestamp în interiorul valorii (ca în exemplul de cache) și verifică-l la citire sau curăță cheile învechite dintr-o funcție declanșată de cron.
- Ce să stochezi. Orice valoare serializabilă JSON — numere, stringuri, array-uri, obiecte. Păstrează intrările mici; acesta este pentru coordonare și caching, nu pentru blob-uri mari sau fișiere. Pentru fișiere, folosește un câmp
FILESșiuploadFile. - Vizibilitate. Intrările se află în baza de date Postgres a instanței, nu ca înregistrări ale spațiului de lucru — nu apar niciodată în interfața spațiului de lucru, nu fac parte din modelul de date al aplicației tale și nu necesită permisiuni de rol sau de obiect.
Alternativă: un obiect de stocare interogabil
Spațiul de stocare integrat este, în mod deliberat, opac: intrările nu sunt înregistrări, astfel că nu le poți răsfoi în UI, nu le poți corela cu alte obiecte și nu le poți filtra cu interogări de înregistrări. Când ai nevoie de oricare dintre acestea — de exemplu un jurnal de sincronizare vizibil sau o stare per-înregistrare — definește în schimb un mic obiect tehnic cu un câmpkey unic și un câmp RAW_JSON value, și interoghează-l prin clientul API tipizat. Vezi Objects pentru referința defineObject și Data → Unique indexes pentru aplicarea unicității cheilor.
- Limitarea la o înregistrare. Adaugă o relație de la obiectul de stocare la obiectul țintă, în loc să codifici id-ul în cheie.
- Vizibilitate și permisiuni. Rândurile trăiesc în baza de date a workspace-ului ca orice altă înregistrare, astfel încât pot fi interogate prin API și respectă rolul aplicației tale. Pentru a ține store-ul în afara UI-ului principal, nu îl include în navigation menu.
Spre deosebire de spațiul de stocare integrat, un obiect personalizat este întotdeauna limitat la un singur workspace — nu poate partaja intrări între instalări, așa cum fac cheile
SERVER.