Ejercicios resueltos de No-code (Bubble, Glide)

Question 1

Una app de Bubble para un consultorio en Medellín muestra las citas del paciente en un Repeating Group con «Do a search for Citas» y la restricción Paciente = Current User. No hay Privacy Rules configuradas. ¿Puede un paciente ver las citas de otro?

Accepted Answer

Sí puede. La restricción de una búsqueda dice qué pide la página, no qué está dispuesto a entregar el servidor. Son dos cosas distintas y solo la segunda es seguridad. En Bubble las búsquedas se resuelven en el servidor, pero si el tipo de dato Cita no tiene Privacy Rules, el servidor lo considera abierto: cualquier petición que pida ese tipo recibe los campos completos. No hace falta ser desarrollador, basta con pedir otra búsqueda desde la API de datos o desde el inspector del navegador. Lo que cierra el acceso es una regla en Data > Privacy: una nueva regla sobre el tipo Cita con la condición «This Cita's Paciente is Current User», marcando ahí los campos que ese paciente sí puede ver. El paso que más se olvida es la regla de abajo, «Everyone else»: tiene que quedar sin ningún campo marcado. Si queda con campos visibles, la regla nueva no sirve de nada, porque la de todos los demás sigue entregando. Después de poner las reglas hay que volver a probar la app completa, porque las Privacy Rules también aplican a los workflows del lado del cliente: lo que el usuario no puede ver, su navegador tampoco lo puede usar para calcular. Lo que necesite ver más datos (un conteo general, un reporte del médico) se mueve a un backend workflow, que corre con otros permisos. Respuesta: Sí. La restricción de la búsqueda es cosmética. Hay que crear Privacy Rules sobre el tipo Cita («This Cita's Paciente is Current User») y dejar la regla de «Everyone else» sin ningún campo marcado.

Question 2

Un colegio en Bogotá lleva la asistencia de 800 estudiantes en Glide sobre una hoja donde cada día se agrega una columna nueva (17-sep, 18-sep, …). A los dos meses la app va lenta, los filtros no sirven y hay que editar la app cada mañana. ¿Cómo debe estructurarse?

Accepted Answer

El problema no es de Glide sino del modelo de datos. Una columna por día produce una hoja «ancha», y las herramientas no-code trabajan sobre filas: filtran filas, agrupan filas, cuentan filas. Sobre columnas que nacen solas no se puede hacer nada automático. De ahí sale lo de editar la app cada día: los componentes apuntan a columnas con nombre fijo, así que cada columna nueva obliga a tocar la pantalla. Cualquier diseño que exija trabajo manual diario ya está mal planteado. El modelo correcto es «largo»: una tabla Estudiantes con 800 filas (id, nombre, curso) y una tabla Asistencias con una fila por evento, con las columnas estudiante_id, fecha y estado. La estructura no cambia nunca: crecen las filas, no las columnas. Con ese modelo los filtros y los totales salen solos: filtrar por fecha, agrupar por estudiante, contar ausencias del mes. Y la app se arma una vez y no se vuelve a tocar. Falta revisar el costo, porque los planes de Glide se cobran por filas: 800 estudiantes × 180 días de clase = 144.000 filas al año, muy por encima de lo que aguanta un plan normal. Se resuelve guardando solo las excepciones: si la asistencia normal es asistir, se registra únicamente la ausencia. Con 5 % de inasistencia son 800 × 180 × 0,05 = 7.200 filas al año, veinte veces menos, y la información es la misma: quien no tiene fila ese día, asistió. Si aun así crece, se archiva por periodo académico. Respuesta: Tabla Estudiantes y tabla Asistencias con una fila por estudiante y fecha (estudiante_id, fecha, estado). Registrando solo las ausencias son unas 7.200 filas al año en vez de 144.000.

No-code (Bubble, Glide)