Servicio de registro de carreras
Un servicio de registro de carreras anota en el momento la distancia, el tiempo, el ritmo y la ruta de cada carrera desde el teléfono, y muestra a cada persona que ha iniciado sesión solo sus propios registros. Cuando termina una carrera, el registro de hoy se suma a la lista, y los registros de otras personas no son visibles entre sí. Los mismos registros se ven tanto en la app del teléfono como en la web.
Este ejemplo muestra una sola cosa. Dos pantallas, la app del teléfono y la web, usan a la vez un único backend de WEEGLOO. Por eso esta página primero mira el backend que la app y la web comparten, y después se divide hacia el lado que te interese, la app o la web. Elijas el que elijas, el backend es el mismo. Ese es el punto clave.
Qué construimos
En lugar de una tienda de ropa o un blog, este ejemplo es un servicio personal de registro de carreras. Los mismos registros se ven en dos pantallas: la app del teléfono y la web. Las pantallas de la app se plantean en tres.
- Pantalla de inicio de sesión: inicias sesión con Google.
- Lista de registros: la persona que ha iniciado sesión ve los registros de carrera que ha anotado hasta ahora, del más reciente al más antiguo.
- Añadir un registro: anotas la distancia, el tiempo, el ritmo, la ruta y la fecha de una carrera.
Lo esencial es "cada persona ve solo sus propios registros". A la persona que ha iniciado sesión se le entregan solo los registros que ella anotó, y los registros de otras personas no son visibles. Esta condición es lo que hace que más adelante hagan falta a la vez el inicio de sesión de los miembros y los permisos.
Puedes ir directamente al lado que te interese. Para construir la app del teléfono, ve a Usarlo como app; para construir la web, a Usarlo como web. Ahora bien, el "backend detrás de las pantallas" que viene debajo es común tanto para la app como para la web, así que si lo revisas primero, las dos ramas se enlazan bien.
El backend detrás de las pantallas (común a la app y la web)
Cuando construyes las pantallas, las conectas y le dices al agente "intégralo con WEEGLOO" (Conectarlo · Integrarlo en una frase), el agente examina las pantallas y monta lo que hace falta detrás de ellas. Una estructura de datos para guardar los registros de carrera (Content Type), el inicio de sesión con Google (ServiceLogin), el permiso de "solo tus propios registros" (ServiceUserRole), y la entrega que, según ese permiso, envía a cada miembro solo sus propios registros. Este backend es el mismo tanto si empiezas por la pantalla de la app como por la de la web, y la app y la web lo comparten tal cual. Cómo tratar cada pieza por separado se cubre una a una en Añadir registro e inicio de sesión · Repartir permisos · Guardar y recuperar datos.
A continuación están los recursos realmente creados en el Space Stride de este ejemplo. No es un recorrido de cómo configurar cada uno; es una mirada a lo que apareció como resultado de "intégralo".
La estructura que guarda los registros de carrera
Lo primero es la estructura que guarda los registros de carrera (Content Type), "Run". Los valores que entran en una sola carrera están repartidos en casillas por elemento.
| Elemento | Tipo de casilla | Obligatorio | Valor que guarda |
|---|---|---|---|
Date | Date | Obligatorio | La fecha de la carrera. También se usa como el título que identifica el registro en la lista. |
Distance (km) | Number | Obligatorio | La distancia recorrida (en kilómetros). Admite decimales. |
Duration (seconds) | Integer | Obligatorio | El tiempo que costó (en segundos). En pantalla se muestra en minutos y segundos, como 41:05. |
Notes | Long Text | Opcional | Una nota de la carrera de ese día. |
Route photo | Media | Opcional | Un archivo de mapa de la ruta o foto. |
No hay ninguna casilla aparte que guarde el ritmo medio. Es un valor que se obtiene solo con la distancia y el tiempo, así que la app lo calcula y lo muestra en el momento (el "auto-calculated" de la pantalla de añadir un registro).
Inicio de sesión con Google
Lo segundo es el canal que los miembros usan para iniciar sesión con Google (ServiceLogin). En este ejemplo el nombre se fija en "Stride", y Google es el único método de inicio de sesión activado. Una persona recién registrada recibe por defecto el permiso "Runner" de más abajo. Cuando termina el inicio de sesión, el resultado vuelve a la pantalla, pero la forma en que vuelve difiere un poco entre la app y la web. Esa diferencia se cubre por separado en Usarlo como app y Usarlo como web.
El permiso de "solo tus propios registros"
Lo tercero es el permiso que reciben los miembros (ServiceUserRole), "Runner". Las reglas son las siguientes.
| Lo que se puede hacer | Ámbito al que se aplica |
|---|---|
| Crear un registro | Cualquier miembro que haya iniciado sesión |
| Leer un registro | Solo los que tú creaste |
| Editar un registro | Solo los que tú creaste |
| Borrar un registro | Solo los que tú creaste |
Como "leer" está atado a "solo los que tú creaste", la lista muestra a cada persona solo sus propios registros. Como los registros que cada miembro puede leer son solo los suyos, esa es precisamente la lista que se entrega a esa persona. Esta regla se aplica igual tanto en la app como en la web.
Registros y fotos
Lo cuarto son cada registro de carrera individual (Content) y la foto de la ruta (Media). Estos dos no se crean con antelación; cada uno se crea a nombre de un miembro cuando anota una carrera. A continuación hay un registro que se anotó realmente. La estructura "Run" de arriba está rellena con valores, y una foto de la ruta va adjunta junto a él.
La distancia 42.195 es un maratón completo. El tiempo se guarda en segundos (aquí, un registro de 3 horas y 53 minutos) y en pantalla se muestra como 3:53:00. La foto de la ruta se guarda aparte como un archivo (Media), y el registro guarda solo un enlace que apunta a ese archivo.
Usarlo como app
Primero, la app del teléfono. Construyes las pantallas de la app y llenas lo que hay detrás de esas pantallas con el backend detrás de las pantallas de arriba.
Crear las pantallas de la app y conectarlas
1. Crear los diseños de las pantallas. Las tres pantallas de "Qué construimos" de arriba se obtuvieron dándole a un LLM un prompt como el de abajo. Le indicas en una línea qué clase de app estás haciendo, la lista de pantallas y qué contiene cada pantalla, y una dirección de diseño.
Diseña las pantallas de una app de registro de carreras. Es una app móvil vertical.
Pantallas:
- Inicio de sesión: una línea que presenta la app y un botón "Continue with Google".
- Lista de registros (inicio): un resumen de la distancia total y el número de carreras, una lista de tarjetas de registro de carrera (fecha, distancia, tiempo, ritmo, miniatura de la ruta) y un botón de añadir un registro.
- Añadir un registro: campos de fecha, distancia, tiempo, ritmo, notas y foto de la ruta, más guardar.
Que quede limpia y activa, de modo que cifras como la distancia y el ritmo se lean de un vistazo. Sigue las convenciones de UI móvil.
Las pantallas obtenidas así están todavía sin datos ni inicio de sesión: son solo las pantallas.
2. Conectar con WEEGLOO. Conecta el agente con WEEGLOO y dile "intégralo con WEEGLOO". El agente examina estas pantallas y monta el backend detrás de las pantallas de arriba.
Dos cosas a tener en cuenta por ser app
El backend es exactamente igual que cuando lo construyes con la web. Por ser app hay dos cosas a tener en cuenta.
- Despliegue: hacer llegar una app móvil terminada a las manos de la gente (publicarla en un mercado de apps) ocurre fuera de WEEGLOO. Lo que WEEGLOO asume son los datos, los miembros y los permisos detrás de las pantallas de la app. (La web no tiene mercado de apps. Se cubre en Usarlo como web.)
- Retorno del inicio de sesión: la conexión que trae el resultado a la app cuando termina el inicio de sesión difiere de la web. El resultado del inicio de sesión solo puede volver a una dirección web, así que hace falta un paso extra: una página que actúa como puente intermedio y pasa ese resultado a la app. Este paso técnico se cubre en Auth API.
Comprobar que de verdad son solo tus propios registros
La condición esencial, "cada persona ve solo sus propios registros", se cumple de verdad en la app. A continuación están las pantallas de inicio de la misma app abierta con dos cuentas distintas. Es la misma app, pero la distancia total, el número de carreras y los registros que aparecen en la lista son todos distintos.
Una cuenta muestra solo una carrera de 5km, y la otra muestra solo dos carreras, un maratón y una de 3km. Sus registros no son visibles entre sí. Stride guarda los tres registros, pero a cada miembro se le entregan solo los registros que él anotó. Es el resultado de haber atado la lectura a "solo los que tú creaste" en El permiso de "solo tus propios registros" de arriba.
Usarlo como web
La web usa tal cual el mismo backend que la app. La web lee el backend detrás de las pantallas de arriba y muestra los mismos registros.
Crear las pantallas de la web y conectarlas
La web son los mismos dos pasos que la app.
1. Crear los diseños de las pantallas de la web. Igual que con la app, le das a un LLM un prompt como el de abajo para obtener las pantallas de la web. El contenido que muestra es el mismo que en la app, adaptado a un diseño web pensado para pantallas anchas.
Diseña las pantallas web de un registro de carreras. Es una web de escritorio.
Pantallas:
- Inicio de sesión: una línea que presenta el servicio y un botón "Continue with Google".
- Lista de registros (panel): un resumen de la distancia total, el número de carreras y el ritmo medio, una lista de registros de carrera (fecha, distancia, tiempo, ritmo, miniatura de la ruta) y un botón de añadir un registro.
- Añadir un registro: campos de fecha, distancia, tiempo, ritmo, notas y foto de la ruta, más guardar.
Con un diseño que aproveche la pantalla ancha, de modo que cifras como la distancia y el ritmo se lean de un vistazo. Sigue las convenciones de UI web.
2. Conectar con WEEGLOO. Le dices al agente conectado "intégralo también con WEEGLOO". Si ya construiste la app, el agente no vuelve a montar el backend detrás de las pantallas de arriba, sino que lo enlaza tal cual. No se crea ningún recurso nuevo de WEEGLOO. Lo único nuevo que se crea en la web son las pantallas web. (Si empezaste por la web sin pasar por la app, este backend se crea por primera vez en este momento, y aunque después añadas la app pasa lo mismo: la reutiliza tal cual. En cualquiera de los dos casos, el backend es el mismo.)
Esta pantalla web es la de la cuenta que aparece en Comprobar que de verdad son solo tus propios registros (este mes 45.2km, un maratón de 42.20km y 3km), abierta en la web. La distancia total, el número de carreras y los registros son idénticos a los de la pantalla de inicio de la app. Como el backend es uno solo, la web muestra en una pantalla de escritorio esos mismos datos que mostró la app.
Dos cosas que difieren por ser web
La web también difiere de la app en dos cosas, pero la dirección es la contraria a la de la app, así que esta vez más bien hay menos que tener en cuenta.
- Despliegue: la web no necesita mercado de apps. Los archivos web que creas se ponen directamente en internet con Web Hosting (Poner un sitio en internet).
- Retorno del inicio de sesión: en la web el resultado del inicio de sesión vuelve directamente a una dirección web. La página que hace de puente intermedio, necesaria en la app, no hace falta en la web.
El permiso es el mismo, así que también en la web cada miembro ve solo sus propios registros. El permiso de "solo tus propios registros" de arriba se aplica igual en la web.
Qué hacer a continuación
- Añadir registro e inicio de sesión: cubre cómo añadir por separado un inicio de sesión que admita a tus propios miembros.
- Auth API: cubre el paso técnico de traer el resultado del inicio de sesión de vuelta a la app.
- Repartir permisos: cubre cómo fijar los permisos para que los miembros traten solo sus propias cosas.
- Guardar y recuperar datos: cubre cómo crear una estructura de datos y rellenarla con contenido.
- Poner un sitio en internet: cubre cómo desplegar la web con Web Hosting.