Lección 5 de 16 · Lectura y práctica
Bubble: construcción de web apps completas
Construye en Bubble un pequeño gestor de tareas con un modelo de datos, estados y privacidad comprobada por usuario.
Del concepto a la práctica
Taller de esta lección
Una aplicación web completa necesita distinguir quién crea, consulta y modifica cada registro. Un filtro visual oculta elementos, pero la protección real debe aplicarse en las reglas de datos y probarse con identidades separadas. El modelo mínimo para tareas es tarea, título, estado y propietario.
Ejemplo resuelto
Con dos usuarios, Ana crea “Llamar al proveedor” y Bruno crea “Revisar factura”. La lista de Ana debe devolver solo su tarea. La acción de completar debe comprobar que el propietario de la tarea coincide con la identidad activa; nunca debe aceptar un propietario enviado desde un campo público.
Pruébalo
Crea dos identidades y dos tareas.
Asigna cada tarea automáticamente a quien inició sesión.
Consulta la lista con cada identidad.
Intenta editar la tarea ajena y registra el resultado.
Error frecuente: confiar en ocultar botones. Corrección: prueba también la consulta y la modificación contra las reglas de datos.
Comprueba tu resultado
La matriz esperada es: Ana ve Ana, Ana no ve Bruno; Bruno ve Bruno, Bruno no ve Ana. La edición cruzada debe producir cero cambios persistidos.
En Bubble, las reglas de privacidad protegen lectura, búsqueda y auto-binding, pero no bloquean automáticamente una modificación hecha por un workflow. Añade la condición de identidad y propietario a esa operación del servidor y prueba ese camino por separado; no interpretes una casilla de lectura como permiso de escritura universal.
Mapa de prácticaEl control de acceso, las actualizaciones y las copias de seguridad cubren riesgos distintos. Una alerta necesita un procedimiento de respuesta para contener y recuperar el servicio. Varias capas reducen la exposición, pero ninguna garantiza seguridad absoluta.
Ver la infografía en tamaño completo ↗Fuentes para profundizar
Caso de práctica: tareas privadas
La aplicación ficticia permite que cada usuario cree sus propias tareas y marque una como completada. El ejemplo debe funcionar para dos identidades de prueba sin compartir sus datos. Un formulario visible y un filtro en una lista no son, por sí solos, reglas de privacidad.
Modelo mínimo
| Tipo | Campos propuestos | Regla del ejemplo |
|---|---|---|
| Task | title: text; done: yes/no; owner: User | Solo el propietario consulta y cambia la tarea |
| User | Identidad de la cuenta | No publicar información adicional sin necesidad |
Escribe qué datos necesitas antes de dibujar pantallas. El campo owner conecta la tarea con una identidad. En el workflow de creación, establece ese propietario desde el usuario autenticado, no desde un campo que el visitante pueda elegir.
Tres workflows para implementar
- Crear: comprobar sesión y título no vacío; crear una Task con owner igual al usuario actual.
- Listar: mostrar las tareas del usuario actual y aplicar las reglas de privacidad correspondientes.
- Completar: permitir el cambio de done solo cuando la tarea pertenece a ese usuario.
Revisa las privacy rules del tipo Task en la documentación de Bubble y limita qué campos pueden consultarse. Comprueba por separado las acciones que modifican datos; no supongas que ocultar un botón impide ejecutar un workflow. Las opciones concretas dependen del editor y la configuración de tu aplicación.
Prueba con dos cuentas de práctica
| Caso | Resultado a comprobar |
|---|---|
| Visitante sin sesión | No obtiene la lista privada ni crea tareas |
| Usuario A | Puede consultar y completar su propia tarea |
| Usuario B | No ve la tarea de A ni puede modificarla |
| Título vacío | Se rechaza antes de crear |
| Cierre de sesión | La vista privada deja de mostrar datos de la sesión anterior |
- Crea datos ficticios separados para A y B.
- Prueba acceso directo a una página y no solo la navegación normal.
- Revisa una búsqueda y un cambio de estado con la otra identidad.
- Anota el resultado real de cada caso y corrige los permisos antes de compartir el prototipo.
Entregable
- Diagrama de Task y su propietario.
- Capturas de los tres workflows y reglas aplicadas, sin credenciales.
- Una tabla de los cinco casos con resultado observado.
- Una limitación pendiente explícita, como borrado o recuperación de una sesión.
No publiques el prototipo con datos reales de clientes como parte de esta práctica. Un proyecto no-code también requiere revisar autorización, errores y estados de sesión; esa revisión forma parte del trabajo, no es un detalle final.
Referencias para comprobar la implementación
Documentación consultada el 2 de octubre de 2026. Comprueba también las versiones y condiciones de tu proyecto.
Sigue con No-Code: Crear Apps sin Programar
Esta lección forma parte de un curso de Cursalo. Revisa su programa y elige entre la compra individual o el acceso a toda la escuela.
Si ya tenías acceso a este curso, entra con tu cuenta: tus derechos y tu progreso se conservan. No necesitas comprarlo de nuevo.