Crea una aplicación en la nube

Describe el caso de uso

Explica usuarios, entradas, resultados, datos persistentes y privacidad antes de elegir tecnologías.

Necesito una aplicación de inscripción a un evento.
Los visitantes introducen nombre y contacto; un administrador puede consultar y exportar registros.
Confirma permisos, uso esperado y almacenamiento antes de proponer la versión mínima.
Prueba con recursos separados. No publiques ni cambies datos de producción sin mi aprobación.

La ejecución depende de modelos, herramientas y permisos. Aclara el acceso a datos personales, autenticación y pagos.

Tres elementos

Consulta estos recursos en Plataforma. El asistente puede preparar y explicar la configuración; no necesitas rellenar cada campo técnico sin ayuda.

Capacidades nativas: conecta los recursos de la plataforma

El servidor de tu aplicación puede llamar directamente a la API de Brazosd. Las aplicaciones Node.js también pueden usar el SDK oficial @brazosd/node. Así puedes conectar archivos, asistentes e historial de trabajo con tu propia interfaz:

Una función en la nube llama a las API con su propio usuario de servicio por defecto. Su organización configura los permisos de API y de recursos. Esta identidad representa a la aplicación: visitar la página o iniciar sesión no le concede automáticamente acceso al disco ni a las sesiones del visitante. Para actuar con los permisos del usuario actual, utiliza el SSO para aplicaciones internas que se explica a continuación.

Elige cómo gestionar el registro y el acceso

Recomendamos Brazosd SSO (inicio de sesión único) para reutilizar el registro y el acceso de Brazosd. El usuario inicia sesión en una página de Brazosd, elige una organización, confirma y vuelve a la aplicación. También puedes conservar un sistema de cuentas existente o crear uno independiente.

Las aplicaciones internas reciben una autorización independiente y revocable, y guardan las credenciales del usuario en el servidor. Brazosd no entrega las credenciales que utiliza el navegador ni permite con este flujo que un tercero acceda a los datos de usuarios de otra organización.

El JWT de identidad incluye account_id, org_id y user_id. Recomendamos account_id como identificador del usuario en la aplicación: la cuenta sigue siendo la misma al cambiar de organización. Si el negocio separa los datos por pertenencia a una organización, puede elegir la combinación de org_id y user_id. Iniciar sesión no convierte al usuario en administrador; la aplicación gestiona sus propios roles, permisos de datos y sesiones. Los miembros de la misma organización también pueden usar identity si solo necesitan identificarse.

Ejemplo: un SaaS de revisión de contratos

El área de administración usa org-user para miembros de la organización de la aplicación. Accede a archivos, agentes y sesiones de revisión según los permisos de cada miembro. El área de clientes usa identity y crea sus propios registros de usuario con el account id.

Cuando un cliente sube un contrato a la aplicación, el usuario de servicio puede enviarlo a un agente autorizado y guardar el resultado en una carpeta autorizada del disco o en la base de datos de la aplicación. La aplicación mantiene separados los contratos de cada cliente. El inicio de sesión no autoriza el acceso al disco de Brazosd que el cliente ya tenía.

Crea un SaaS de revisión de contratos con la API de Brazosd y SSO.
Limita la administración a nuestra organización y usa los permisos de cada miembro para archivos, agentes y sesiones.
Permite que los clientes de cualquier organización se identifiquen sin conceder acceso a sus recursos; usa el account id como identificador.
Cada cliente solo puede consultar sus propios contratos enviados y resultados.
Usa la habilidad develop-cloud-apps y verifica primero ambos modos de acceso y el aislamiento de datos en pruebas.

Un proceso práctico

Confirma requisitos y usa funciones y bases separadas para pruebas. Comprueba entradas correctas, campos vacíos, envíos repetidos y permisos.

Antes de publicar, confirma recursos, datos, dirección y costes esperados. Espera un despliegue correcto y prueba la URL antes de distribuirla. Desarrollado, desplegándose y disponible son estados diferentes.

Qué guardan las instantáneas

Guardan archivos y dependencias, no procesos en ejecución, memoria ni conexiones. Termina las escrituras e instalaciones antes de capturar.

Los miembros de la organización pueden consultar y usar sus instantáneas. Revisa su contenido. Si funciones, agentes o sesiones las referencian, hay que liberar esas referencias antes de borrarlas; también se aplican permisos de creador y propietario.

Publicación y recuperación

La versión existente puede seguir atendiendo mientras se prepara una nueva. Paquetes e historial permiten identificar versiones y seleccionar un paquete anterior.

Volver a una versión de código no restaura automáticamente los datos. Revisa y respalda los cambios de producción por separado; evita mezclar bases de pruebas y reales.

Mantener la aplicación

Documenta finalidad, responsable, URL, base de datos y mantenimiento. Revisa consumo y estado. Al retirarla, comprueba cada recurso antes de eliminarlo, porque la eliminación puede ser permanente.