Cuando una institución decide crear una aplicación móvil, la primera pregunta rara vez tiene que ver con la aplicación en sí. Se trata de dónde vendrá el contenido. Catálogos de cursos, anuncios, perfiles del profesorado, listados de eventos, noticias: este contenido ya reside en un sistema de gestión de contenidos, y la aplicación necesita una forma fiable de acceder a él. Justo aquí es donde entra en juego un enfoque API-first para Drupal: en lugar de tratar la aplicación móvil como un proyecto separado con su propio almacén de contenido, Drupal se convierte en el único backend que sirve al sitio web, a la aplicación y a cualquier canal futuro a través de un conjunto de API coherente.
Este artículo explica cómo construir una aplicación móvil sobre Drupal utilizando una arquitectura API-first. Aclararemos la diferencia entre "API-first" y "headless", veremos por qué este modelo encaja tan bien con lo móvil, repasaremos las capas de API y autenticación, cubriremos las cuestiones específicas de móvil que la mayoría de las guías pasan por alto, y estableceremos un marco claro para decidir hasta qué punto desacoplar.
API-First frente a Headless: aclarando la confusión
Estos dos términos suelen usarse indistintamente, pero describen cosas distintas, y entender esa diferencia condiciona cómo se planifica el proyecto.
Headless describe una arquitectura: el frontend (lo que ve el usuario) se separa del backend (donde reside el contenido), y ambos se comunican mediante una API. En una configuración headless, Drupal deja de renderizar las páginas por sí mismo y en su lugar entrega el contenido en bruto a una aplicación de frontend independiente.
API-first describe una filosofía de diseño: el contenido se modela y se expone como API desde el principio, de modo que está listo para alimentar cualquier número de canales a la vez: un sitio web, una app de iOS, una app de Android, un smartwatch, un quiosco, un asistente de voz. Headless trata de separar un frontend; API-first trata de estar preparado para todos ellos. Una aplicación móvil suele ser el detonante para adoptar API-first, pero la verdadera recompensa es que el mismo backend puede servir a cada canal que la institución añada más adelante, sin reconstruir la capa de contenido cada vez.
Drupal se adapta bien a ambos enfoques porque sus capacidades de API forman parte del núcleo y no son un añadido. Desde Drupal 8, y madurando a lo largo de Drupal 9, 10 y 11, la plataforma incorpora una capa de servicios web que convierte el contenido estructurado en respuestas de API sin necesidad de código personalizado. Ese es el fundamento sobre el que se construye todo lo demás en este artículo.
Por qué API-first es la base adecuada para una aplicación móvil
Elegir un backend Drupal API-first para una aplicación móvil aporta ventajas que se manifiestan a lo largo de todo el ciclo de vida del proyecto, no solo en el lanzamiento.
- Una sola fuente de contenido, muchos canales: el mismo anuncio, curso o perfil se introduce una vez en Drupal y se entrega simultáneamente al sitio web, a la aplicación móvil y a cualquier otro canal. Los editores no mantienen el contenido por duplicado, y la aplicación nunca se desincroniza del sitio.
- Contenido estructurado, listo para cualquier interfaz: como Drupal almacena el contenido como datos estructurados en lugar de páginas renderizadas, ese contenido se traslada de forma limpia a una interfaz móvil. Un curso no es un bloque de HTML: es un conjunto de campos (título, créditos, docente, horario) que la aplicación puede organizar como necesite.
- Evolución independiente de frontend y backend: el equipo de la app puede publicar una nueva versión sin tocar el backend, y el equipo de contenido puede reestructurar el backend sin romper la app, siempre que se mantenga el contrato de la API. Las actualizaciones en un lado no obligan a reconstruir el otro.
- Una inversión preparada para el futuro: cuando aparece el siguiente canal —una nueva app, un sistema de pantallas en el campus, una integración con otra plataforma—, el contenido ya está expuesto y esperando. La institución construye un nuevo frontend, no un nuevo backend.
- Gestión de contenido de nivel empresarial detrás de la app: la aplicación hereda los flujos editoriales de Drupal, los permisos granulares, el soporte multilingüe y la gestión de medios: capacidades que un backend móvil construido a medida tendría que reinventar desde cero.
La capa de API: JSON:API, REST y GraphQL
Drupal puede exponer contenido a través de tres especificaciones principales. No son tanto competidoras como herramientas distintas, y la elección correcta depende de las necesidades de la aplicación.
| Especificación | Qué es | Mejor opción para |
|---|---|---|
| JSON:API | Una especificación estandarizada, habilitada en el núcleo de Drupal sin ninguna configuración. Expone automáticamente cada entidad de contenido como un endpoint bien estructurado. | La opción por defecto para la mayoría de las apps móviles: consistente, predecible, sin necesidad de configuración. |
| REST (RESTful Web Services) | El enfoque clásico, también incluido en el núcleo. Los endpoints se configuran por recurso, con mayor control manual. | Integraciones sencillas o cuando se necesita una forma de endpoint personalizada muy concreta. |
| GraphQL | Un lenguaje de consultas (mediante un módulo contribuido) que permite al cliente solicitar exactamente los campos que necesita en una sola llamada. | Aplicaciones complejas que necesitan minimizar el número de peticiones y obtener conjuntos de datos precisos. |
Especificación JSON:API para la mayoría de los proyectos móviles como el punto de partida natural. Es parte del núcleo, no requiere ninguna configuración para activarse, y sigue una especificación estricta, lo que significa que el desarrollador móvil sabe exactamente cómo serán las respuestas. Su estructura también gestiona las relaciones entre contenidos —un curso y su docente, un evento y su sede— de manera predecible, algo que se necesita con frecuencia en las aplicaciones institucionales. GraphQL resulta atractivo cuando una pantalla de la app necesita obtener muchas piezas distintas de datos a la vez y se quiere evitar múltiples idas y vueltas; la contrapartida es una configuración y complejidad añadidas. Como regla general, conviene empezar con JSON:API y pasar a GraphQL solo cuando una necesidad concreta de rendimiento lo justifique.
Autenticación: por qué las aplicaciones móviles no pueden depender de las cookies
La autenticación es el primer obstáculo técnico real en una construcción móvil desacoplada, y pilla desprevenidos a muchos equipos. Un sitio Drupal tradicional autentica a los usuarios mediante cookies de sesión gestionadas por el navegador. Una aplicación móvil nativa no tiene navegador ni un almacén de cookies, así que ese mecanismo simplemente no se aplica. La aplicación tiene que autenticarse de otra manera.
La solución estándar es la autenticación basada en tokens. El usuario introduce sus credenciales una vez; la app las envía a Drupal; Drupal las verifica y devuelve un token; y la app almacena ese token y lo adjunta a cada solicitud posterior. Predominan dos enfoques:
- OAuth 2.0 (módulo Simple OAuth): el enfoque recomendado para la mayoría de las apps desacopladas. Emite tokens de acceso y de actualización, admite flujos modernos incluyendo PKCE para clientes públicos como las apps móviles, y se integra limpiamente con sistemas de identidad centralizados. Este es el camino que sigue la mayoría de las construcciones institucionales.
- JWT (JSON Web Token): una alternativa ligera en la que el propio token lleva la identidad del usuario. Es simple y sin estado, y encaja bien en aplicaciones sencillas sin necesidades de autorización complejas.
Para instituciones que ya cuentan con inicio de sesión único, la capa de OAuth puede conectar la app con el mismo proveedor de identidad centralizado que se usa en todos los demás sitios, de modo que estudiantes y personal inician sesión en la app con las credenciales que ya tienen. Acertar con la autenticación desde el principio es importante: es mucho más difícil incorporar a posteriori un flujo de tokens seguro en una app construida en torno a una suposición más simple que diseñarlo así desde el inicio.
La capa específica de móvil: sin conexión, notificaciones push y medios
La mayoría de las guías sobre Drupal desacoplado se detienen en la API y la autenticación. Pero una aplicación móvil vive en un dispositivo con conectividad intermitente, ancho de banda limitado y su propio sistema de notificaciones, y estas realidades requieren una planificación que un sitio web nunca exige.
- Acceso sin conexión y caché: un usuario móvil espera que la app funcione en un tren o en una sala de conferencias con mala señal. La app debería almacenar el contenido en caché localmente y sincronizarlo con Drupal cuando vuelva la conexión. La capa de API respalda esto sirviendo respuestas estructuradas y cacheables que la app puede almacenar y actualizar, pero la lógica de caché y sincronización reside en el lado de la app y debe diseñarse de forma deliberada.
- Notificaciones push: las notificaciones son una de las principales razones por las que las instituciones quieren una app nativa en primer lugar: una nueva calificación, un cambio de horario, una alerta de emergencia. Drupal actúa como fuente del disparador: cuando se publica contenido o se dispara un evento, Drupal llama a un servicio push (como Firebase Cloud Messaging) que entrega la notificación a los dispositivos. El contenido y el disparador residen en Drupal; la entrega la gestiona la infraestructura de notificaciones de la plataforma.
- Optimización de medios e imágenes: las pantallas móviles y los planes de datos móviles hacen que la gestión de imágenes sea crítica. El sistema de medios y los estilos de imagen de Drupal pueden generar versiones de tamaño adecuado de cada imagen, de modo que la app solicita una versión optimizada para móvil en lugar de descargar un archivo de resolución completa pensado para escritorio. Esto afecta directamente a los tiempos de carga y al consumo de datos.
- Las Progressive Web Apps como camino intermedio: no todas las instituciones necesitan una app nativa completa. Una Progressive Web App (PWA) ofrece gran parte de la experiencia nativa —instalación en la pantalla de inicio, soporte sin conexión, notificaciones push— a partir de una única base de código web, y Drupal lo soporta mediante un módulo PWA dedicado. Para muchos campus, una PWA es una vía de menor coste hacia una experiencia similar a una app antes de comprometerse con el desarrollo nativo.
Desacoplado, progresivamente desacoplado o acoplado
Pasar a un desacoplamiento total es un compromiso real, y no es automáticamente la respuesta correcta. Ser honesto sobre cuándo no desacoplar es tan importante como saber cuándo hacerlo. Existen tres modelos generales:
- Acoplado (Drupal tradicional): Drupal gestiona tanto el contenido como la presentación. Esto sigue siendo la elección correcta para un sitio web estándar sin una app independiente ni un framework de frontend. Si no hay una aplicación móvil ni un segundo canal, desacoplar añade costes sin ningún beneficio.
- Progresivamente desacoplado: Drupal renderiza la mayor parte de la página, pero delega componentes interactivos concretos a un framework de JavaScript. Esto mantiene intactas las herramientas editoriales y de maquetación de Drupal mientras añade interactividad avanzada donde se necesita: un término medio útil para un sitio web que busca cierto comportamiento similar al de una app sin una reconstrucción completa.
- Completamente desacoplado: Drupal es puramente un backend, y uno o varios frontends independientes (una app móvil, una aplicación web independiente) consumen sus API. Este es el modelo que requiere una aplicación móvil nativa, y es la elección correcta cuando realmente se atienden varios canales, pero implica que el equipo de frontend asume responsabilidades que antes gestionaba Drupal, desde el enrutamiento hasta el SEO y la accesibilidad.
El factor decisivo es a cuántos frontends necesita servir el contenido. Un único sitio web es mejor mantenerlo acoplado. Un sitio web más una app móvil nativa apunta hacia una arquitectura desacoplada o híbrida. El error es desacoplar por desacoplar: una construcción completamente desacoplada para un proyecto que solo necesitaba un sitio web añade complejidad y costes que la institución mantendrá durante años. Analizamos las contrapartidas más amplias entre plataformas en nuestra comparación de Drupal, WordPress y Joomla.
Elecciones de frontend: React Native, Flutter y nativo
Como un backend de Drupal API-first es independiente del frontend, funciona con cualquier tecnología móvil que el equipo prefiera. A la API no le importa quién la consume, lo que deja que la decisión dependa de los requisitos de la app y de las habilidades del equipo.
- React Native: una opción multiplataforma popular que construye apps de iOS y Android a partir de una única base de código JavaScript. Encaja de forma natural con la JSON:API de Drupal, y cuenta con un ecosistema y una bolsa de talento amplios detrás.
- Flutter: el framework multiplataforma de Google, que utiliza el lenguaje Dart, conocido por su rendimiento fluido y un aspecto consistente entre plataformas. Consume las API de Drupal con la misma facilidad que cualquier otro cliente.
- Nativo (Swift / Kotlin): construir por separado para iOS (Swift) y Android (Kotlin) ofrece la integración más profunda con la plataforma y el mejor rendimiento, a un coste de desarrollo más alto. El backend de Drupal sirve a ambos de forma idéntica.
El punto clave es que se trata de una elección genuinamente abierta. Como el backend expone API estándar, la institución no queda atada a ninguna tecnología de frontend concreta y puede incluso cambiarla más adelante sin tocar la capa de contenido.
Errores comunes en una construcción móvil API-first
- Desacoplar cuando no era necesario: el error más habitual. Si no hay un segundo canal, un sitio Drupal acoplado es más sencillo, más barato y más fácil de mantener. Desacopla porque tienes una app móvil, no porque suene moderno.
- Dejar la autenticación para el final: la autenticación basada en tokens condiciona toda la arquitectura de la app. Diseña el flujo de OAuth o JWT desde el principio, no después de que la app ya esté construida en torno a suposiciones de sesión.
- Olvidar lo que ahora recae sobre el frontend: en una construcción desacoplada, el equipo de frontend hereda el enrutamiento, el SEO, la accesibilidad y los metadatos: cosas que antes gestionaba Drupal automáticamente. Hay que planificarlas explícitamente, o simplemente no ocurrirán.
- Ignorar la capa específica de móvil: el comportamiento sin conexión, las notificaciones push y la optimización de imágenes no son un añadido de última hora. Una app que no gestiona bien la mala conectividad o sirve imágenes del tamaño de escritorio se sentirá rota, por muy limpia que sea la API.
- Sobrecargar la petición de datos: solicitar más de lo que una pantalla necesita desperdicia ancho de banda y batería. Usa el filtrado de campos de JSON:API, o GraphQL cuando encaje, para obtener solo lo necesario.
- Tratar la API como algo secundario: el sentido de API-first es diseñar el modelo de contenido y su API de forma deliberada, desde el principio. Añadir una API a posteriori sobre una estructura de contenido que nunca se pensó para ser consumida externamente conduce a endpoints incómodos e ineficientes.
Bien planteado, un backend Drupal API-first ofrece a una institución una única fuente de contenido bien estructurada capaz de impulsar un sitio web, una app móvil y lo que venga después, sin duplicar contenido ni reconstruir la base cada vez. Encaja de forma natural en organizaciones que ya confían en el contenido estructurado de Drupal y quieren extenderlo a nuevos canales. Para ver el rango más amplio de lo que soporta la plataforma, nuestro resumen sobre qué se puede hacer con Drupal recoge los escenarios relacionados, y la guía qué es Drupal cubre los fundamentos de su modelo de contenido estructurado.
Preguntas frecuentes sobre Drupal y aplicaciones móviles
¿Es Drupal un buen backend para una aplicación móvil?
Sí, especialmente cuando la aplicación necesita compartir contenido con un sitio web u otros canales. Las capacidades API-first de Drupal están integradas en el núcleo, por lo que puede servir contenido estructurado a iOS, Android o cualquier frontend mediante API estándar sin necesidad de infraestructura personalizada. Encaja especialmente bien cuando la aplicación se beneficia de una gestión de contenido de nivel empresarial detrás: flujos editoriales, permisos granulares, contenido multilingüe y una gestión de medios sólida. Para una aplicación independiente sin contenido compartido ni necesidades de gestión de contenido, un backend más ligero puede ser suficiente; el argumento a favor de Drupal crece con la complejidad del contenido.
¿Necesito saber PHP para construir una aplicación móvil en Drupal?
No, no para la aplicación en sí. En una arquitectura desacoplada, la aplicación móvil se construye con tecnologías móviles —React Native, Flutter, Swift o Kotlin— y se comunica con Drupal exclusivamente a través de API. Los desarrolladores móviles trabajan en su propio lenguaje y nunca tocan PHP. El conocimiento de PHP solo es relevante en el lado de Drupal, para configurar el backend, modelar el contenido y personalizar la capa de API, tareas que normalmente asume el equipo de Drupal y no el equipo de la aplicación.
¿JSON:API o GraphQL para una aplicación móvil?
Empieza con JSON:API. Está habilitado en el núcleo de Drupal sin necesidad de configuración, sigue una especificación estricta y predecible, y cubre las necesidades de la mayoría de las aplicaciones móviles nada más instalarlo. GraphQL merece la pena cuando las pantallas de la app necesitan obtener muchas piezas distintas de datos en una sola petición y se quiere minimizar el número de idas y vueltas, pero añade configuración y complejidad a través de un módulo contribuido. El camino práctico es usar JSON:API por defecto y pasar a GraphQL cuando un requisito de rendimiento concreto justifique el esfuerzo adicional.
¿Puede un mismo backend de Drupal impulsar a la vez un sitio web y una aplicación móvil?
Sí, y esa es una de las razones más sólidas para elegir un enfoque API-first. Un único backend de Drupal puede servir el sitio web y la aplicación móvil al mismo tiempo, a partir del mismo contenido. Un anuncio o un curso introducido una vez aparece en ambos, siempre sincronizado, sin esfuerzo duplicado. Esto es exactamente lo que significa en la práctica "una fuente de contenido, muchos canales", y es la ventaja principal de construir con enfoque API-first desde el principio.