Una app sin backend sólido es una interfaz. Puedes tener onboarding pulido y animaciones a 60 fps. Si el login se rompe, si dos dispositivos pisan el mismo dato o si el modo avión deja la app en un limbo, el usuario no culpa al servidor: culpa al producto.
El error habitual es pintar pantallas y “ya pondremos API”. Entonces el modelo de datos se inventa a destiempo, el token de sesión se guarda donde no toca y el offline es un cache a ciegas que duplica pedidos. Eso no se arregla con más UI.
Este artículo cubre lo que hay que decidir antes de abrir Figma: auth, sincronización, offline y APIs. Es el suelo de un proyecto de desarrollo de app, no un extra de la fase 2. Las push las dejamos fuera a propósito: ya tienen su propia guía.
Qué backend para apps hay que decidir antes de pintar
El backend para apps no es “un Laravel y cuatro endpoints”. Es el sistema que autentica, autoriza, guarda, replica y resuelve conflictos. Si no decides eso en discovery, el diseño UX/UI va a inventar estados que el servidor no puede cumplir: “guardado” que no está guardado, “enviado” que se envió dos veces, “sesión” que caduca en mitad de un pago.
Tres preguntas cierran el tipo de backend: ¿quién entra y con qué rol?, ¿el dato vive en un solo dispositivo o en varios?, ¿qué tiene que funcionar sin red y qué no? Klapper y Weddle responden distinto. Por eso no copian arquitectura.
| Decisión | Barato de fingir | Caro de no decidir |
|---|---|---|
| Auth y sesiones | Login + token largo | Robo de sesión, sin revocar |
| Roles | Un flag isAdmin | Permisos en el cliente |
| API | REST bien versionada | GraphQL sin política de N+1 |
| Offline | Cache de lecturas | Escrituras duplicadas |
| Fuente de verdad | Servidor | Cada móvil con su copia |
Auth: tokens, roles y el momento de cortar
Auth no es la pantalla de login. Es el ciclo: identidad, sesión, refresh, logout, revocación y roles. El detalle de errores de roles lo cubrimos en autenticación y roles de usuario; aquí importa el encaje con la app: el token no puede ser eterno, el refresh no puede vivir en un sitio que un backup de iCloud copie, y el rol no se decide en el cliente.
En la práctica pedimos: access token corto (minutos), refresh rotativo, logout que invalida en servidor, y un endpoint de “quién soy” que la app consulta al abrir —no un JSON cacheado de hace tres semanas. Si hay que echar a un usuario (empleado que se va, cuenta comprometida), la revocación tiene que ser inmediata, no “cuando caduque el JWT de 30 días”.
APIs y modelo: lo que la pantalla no debería inventar
La API es el contrato del producto. Si el diseñador inventa un “estado de ticket” que el backend no tiene, la pantalla miente. Por eso el modelo se cierra con diseño y backend en la misma mesa: entidades, transiciones, idempotencia.
REST bien versionada cubre la mayoría de apps que construimos. GraphQL entra cuando hay muchas pantallas pidiendo formas distintas del mismo grafo y el equipo sabe evitar el N+1. La comparación honesta está en REST vs GraphQL en proyectos reales. La decisión no es de moda: es de quién opera el esquema a los 18 meses.
Tip técnico: idempotencia en escrituras
Un “comprar”, un “unirse al grupo” o un “marcar como leído” se reintenta cuando la red falla. Sin Idempotency-Key (o un id de operación generado en el cliente), el reintento crea un segundo cargo o un segundo grupo. El offline no es magia: es una cola de mutaciones con identidad propia y un servidor que las reconoce si llegan dos veces.
Offline y sync: qué se puede mentir y qué no
Offline no es “guardar el JSON de la última GET”. Es una política: lecturas stale-while-revalidate, escrituras en cola, conflictos visibles. Si dos invitados editan el mismo perfil en Weddle, ¿quién gana? Si un portero valida una entrada en Klapper sin red, ¿qué pasa cuando el servidor dice que ya se usó?
No todo producto necesita offline-first. Una app de venta de entradas puede cachear el ticket y el QR; no debería vender un abono dos veces sin servidor. Una app social de un evento puntual puede permitir chat encolado; no puede inventar un grupo que el servidor rechaza. La promesa de la store tiene que caber en esa tabla.
Si mañana el usuario entra en modo avión, ¿qué tres acciones siguen siendo honestas? Si no las puedes listar, no tienes offline: tienes un cache accidental.
Klapper y Weddle: dos backends, ninguna pantalla primero
Klapper es nuestra plataforma de entradas: marca, web y app. El backend carga con inventario, pagos, usuarios y el momento en que un QR se valida. Ahí la fuente de verdad es el servidor. El offline del asistente es el ticket ya comprado, no la venta. Auth y roles (asistente, organizador, staff de puerta) se deciden antes del color del botón. Si el stock se descuadra, no hay UI que lo tape.
Weddle es otra bestia: grupos privados de solteros invitados a una boda, activos unos días. Auth por invitación, no un feed eterno. El dato es sensible y caduca. La sync es “estar en el grupo correcto a tiempo”, no un grafo social de años. Offline ayuda a no perder un mensaje a medias; no justifica un backend improvisado. Pintar el hielo-breaking sin modelo de grupo, roles y caducidad es diseñar una mentira amable.
La app que se rompe no suele romperse en el pixel. Se rompe en la sesión, en el stock o en un write que se envió dos veces. Eso se decide en el backend, la semana antes de abrir Figma —no la semana del store review.
Las notificaciones importan —reactivación, recordatorio, “te han escrito”— pero son un canal encima de este suelo. Si quieres ese canal, está en notificaciones push: buenas prácticas. Aquí el criterio es otro: sin auth y sync honestos, la push solo avisa de un dato ya corrupto.
Antes de diseñar pantallas, verifica esto
- ¿Están listados roles y quién puede hacer cada escritura?
- ¿Access token corto, refresh rotativo y revocación en servidor?
- ¿Cada mutación crítica tiene id de idempotencia?
- ¿Sabes qué acciones son online only, encolables o prohibidas sin red?
- ¿La UI distingue “pendiente”, “enviado” y “confirmado por servidor”?
- ¿Hay regla de conflicto (last-write, merge o pantalla) por entidad?
- ¿El rol no se fía del cliente —el servidor autoriza?
- ¿Web y app, si coexisten, tienen sesiones y scopes distintos?
Preguntas frecuentes sobre backend para apps
¿Qué backend necesita una app en 2026?
El que autentique de verdad, autorice en servidor, versiona la API y tenga una política de sync. Firebase o un backend propio pueden servir: la pregunta no es el logo del proveedor, es si puedes revocar una sesión, no duplicar un pago y explicar qué pasa sin red.
¿Toda app tiene que funcionar offline?
No. Offline es un requisito de producto, no un sello de calidad. Un checkout o un inventario en vivo suelen ser online only. Un lector de tickets o un borrador de mensaje sí pueden encolar. Decláralo en el brief. “Que funcione en el metro” no es una spec.
¿Cuándo se decide el backend respecto al diseño?
En el discovery, en paralelo. Las pantallas dependen de estados reales (sesión caducada, cola, conflicto). Si el diseño cierra primero, el backend se pasa el proyecto parcheando promesas. En Truman no abrimos UI de app sin modelo de auth y de datos.
¿REST o GraphQL para una app a medida?
REST si el equipo es pequeño y los recursos son claros (usuarios, pedidos, grupos). GraphQL si hay muchos clientes y formas de leer el mismo grafo, y hay disciplina de queries. Ninguno arregla un modelo mal cortado. Empieza por entidades y transiciones; el transporte se elige después.
