Resumen
Las funciones de lógica se ejecutan aisladas en procesos de Node.js de corta duración; una vez que una ejecución finaliza, nada de lo que se mantuvo en memoria sobrevive. Cuando necesitas recordar algo entre ejecuciones (almacenar en caché una respuesta de API costosa, guardar un cursor para sincronizaciones incrementales, aplicar debounce al trabajo o traspasar estado de una función a otra), persiste esos datos en el almacén de clave-valor integrado. Cada aplicación obtiene su propio espacio de nombres aislado: las entradas se asocian con la aplicación autenticada, por lo que tus claves nunca pueden entrar en conflicto con — ni ser leídas por — otra aplicación. El almacén es persistente: las entradas se almacenan en la base de datos PostgreSQL de la instancia — no en una caché en memoria como Redis —, por lo que sobreviven a los reinicios del servidor, las implementaciones y las actualizaciones de la aplicación, y permanecen allí hasta que las elimines. Esto lo hace fiable para estados duraderos, como cursores de sincronización o configuraciones por usuario, y no solo para cachés de corta duración. Los valores se almacenan como JSON sin formato y sin cifrado a nivel de aplicación, así que no incluyas secretos en él — guarda las claves de API y otras credenciales en las variables secretas de aplicación o servidor, que se cifran en reposo.Obtener, establecer, eliminar
Importakv desde twenty-sdk/logic-function. Los valores pueden ser cualquier carga útil serializable en JSON.
src/logic-functions/sync-linear-issues.ts
Ámbitos
Cada entrada tiene un ámbito (scope), que se pasa como una opción en cada llamada. El valor predeterminado esWORKSPACE.
WORKSPACE(predeterminado): la entrada es privada para la instalación actual de tu aplicación en el espacio de trabajo. Cada espacio de trabajo que instala la aplicación obtiene su propio conjunto independiente de claves. Esto es lo que quieres para cachés, cursores y estado por espacio de trabajo.SERVER: la entrada se comparte entre todas las instalaciones de tu aplicación en el servidor. Las entradas de servidor se comportan como reclamaciones: el valor almacenado es siempre el workspaceId que reclamó la clave (omitevalueensetpara reclamar la clave para el espacio de trabajo actual), y solo ese espacio de trabajo puede sobrescribirla o eliminarla. Cualquier instalación puede leer la entrada.
kv.set produce una excepción cuando la clave ya ha sido reclamada por otro espacio de trabajo.
Úsalo: almacena en caché una llamada costosa
Un uso típico es almacenar en caché una respuesta lenta o limitada por rate limiting de un tercero para que ejecuciones repetidas la reutilicen en lugar de pagar el coste cada vez.src/logic-functions/getExchangeRate.logic-function.ts
Patrones y consejos
- Espacios de nombres. Añade un prefijo a las claves para mantener separadas las distintas responsabilidades:
sync-cursor:linear,cache:exchange-rate:USD:EUR,lock:nightly-report. - Caducidad (TTL). El almacén no tiene caducidad integrada. Almacena una marca de tiempo dentro del valor (como en el ejemplo de caché) y revísala al leer, o borra las claves obsoletas desde una función activada por cron.
- Qué almacenar. Cualquier valor serializable en JSON: números, cadenas, arreglos, objetos. Mantén las entradas pequeñas; esto es para coordinación y almacenamiento en caché, no para blobs grandes o archivos. Para archivos, utiliza un campo
FILESyuploadFile. - Visibilidad. Las entradas residen en la base de datos Postgres de la instancia, no como registros del espacio de trabajo; nunca aparecen en la interfaz de usuario del espacio de trabajo, no forman parte del modelo de datos de tu aplicación y no necesitan permisos de rol ni de objeto.
Alternativa: un objeto de almacenamiento consultable
El almacén integrado es deliberadamente opaco: las entradas no son registros, por lo que no puedes explorarlas en la interfaz de usuario, relacionarlas con otros objetos ni filtrarlas con consultas de registros. Cuando necesites algo de eso — por ejemplo, un registro de sincronización visible o estado por registro — define en su lugar un pequeño objeto técnico con un campokey único y un campo value de tipo RAW_JSON, y consúltalo mediante el cliente de API tipado. Consulta Objects para la referencia de defineObject y Data → Unique indexes para aplicar la unicidad de la clave.
- Limitando el ámbito a un registro. Añade una relación desde el objeto de almacenamiento al objeto de destino en lugar de codificar el id en la clave.
- Visibilidad y permisos. Las filas residen en la base de datos del espacio de trabajo como cualquier otro registro, por lo que se pueden consultar a través de la API y respetan el rol de tu aplicación. Para mantener el almacén fuera de la interfaz principal, déjalo fuera de tu menú de navegación.
A diferencia del almacén integrado, un objeto personalizado siempre está limitado a un solo espacio de trabajo: no puede compartir entradas entre instalaciones como lo hacen las claves
SERVER.