Когда учреждение решает создать мобильное приложение, первый вопрос редко касается самого приложения. Речь идёт о том, откуда возьмётся контент. Каталоги курсов, объявления, профили преподавателей, списки мероприятий, новости — этот контент уже находится в системе управления контентом, и приложению нужен надёжный способ доступа к нему. Именно здесь на помощь приходит подход API-first для Drupal: вместо того чтобы рассматривать мобильное приложение как отдельный проект с собственным хранилищем контента, Drupal становится единым бэкендом, который обслуживает сайт, приложение и любой будущий канал через единый согласованный набор API.
В этой статье объясняется, как построить мобильное приложение поверх Drupal, используя архитектуру API-first. Мы разберёмся с разницей между «API-first» и «headless», рассмотрим, почему эта модель так хорошо подходит для мобильных решений, пройдёмся по слоям API и аутентификации, разберём специфичные для мобильных приложений вопросы, которые упускает большинство руководств, и предложим чёткую систему для принятия решения о том, насколько глубоко следует проводить декаплинг.
API-first против headless: устраняем путаницу
Эти два термина часто используют как взаимозаменяемые, но они описывают разные вещи, и понимание этого различия определяет то, как вы планируете проект.
Headless описывает архитектуру: фронтенд (то, что видит пользователь) отделён от бэкенда (где хранится контент), и они взаимодействуют через API. В headless-конфигурации Drupal перестаёт сам отрисовывать страницы и вместо этого передаёт «сырой» контент отдельному фронтенд-приложению.
API-first описывает философию проектирования: контент моделируется и предоставляется в виде API с самого начала, чтобы быть готовым питать сразу любое количество каналов — сайт, приложение для iOS, приложение для Android, смарт-часы, киоск, голосовой ассистент. Headless — это про отделение одного фронтенда; API-first — про готовность ко всем сразу. Мобильное приложение часто становится поводом перейти на API-first, но настоящая выгода в том, что один и тот же бэкенд способен обслуживать каждый новый канал, который учреждение добавит позже, без необходимости каждый раз перестраивать слой контента.
Drupal хорошо подходит для обоих подходов, потому что его возможности API заложены в ядре, а не являются дополнением. Начиная с Drupal 8 и развиваясь через Drupal 9, 10 и 11, платформа поставляется со слоем веб-сервисов, который превращает структурированный контент в ответы API без написания собственного кода. Именно на этом фундаменте строится всё остальное в этой статье.
Почему API-first — правильная основа для мобильного приложения
Выбор бэкенда Drupal с подходом API-first для мобильного приложения даёт преимущества, которые проявляются на протяжении всего жизненного цикла проекта, а не только на старте.
- Один источник контента, много каналов: одно и то же объявление, курс или профиль вводится в Drupal один раз и одновременно доставляется на сайт, в мобильное приложение и на любой другой канал. Редакторам не приходится вести контент дважды, а приложение никогда не рассинхронизируется с сайтом.
- Структурированный контент, готовый для любого интерфейса: поскольку Drupal хранит контент как структурированные данные, а не как отрисованные страницы, этот контент чисто ложится на мобильный интерфейс. Курс — это не блок HTML, а набор полей (название, кредиты, преподаватель, расписание), которые приложение может выстраивать так, как ему нужно.
- Независимое развитие фронтенда и бэкенда: команда приложения может выпустить новую версию, не трогая бэкенд, а команда контента может реструктурировать бэкенд, не ломая приложение, — пока сохраняется контракт API. Обновления с одной стороны не вынуждают перестраивать другую.
- Инвестиция, устойчивая к будущим изменениям: когда появляется следующий канал — новое приложение, система экранов на кампусе, интеграция с другой платформой — контент уже опубликован и ждёт. Учреждение строит новый фронтенд, а не новый бэкенд.
- Управление контентом корпоративного уровня за приложением: приложение наследует редакционные процессы Drupal, детализированные права доступа, многоязычную поддержку и работу с медиа — возможности, которые специально созданному мобильному бэкенду пришлось бы изобретать заново.
Слой API: JSON:API, REST и GraphQL
Drupal может предоставлять контент через три основные спецификации. Это скорее не конкуренты, а разные инструменты, и правильный выбор зависит от потребностей приложения.
| Спецификация | Что это такое | Лучше всего подходит для |
|---|---|---|
| JSON:API | Стандартизированная спецификация, включённая в ядро Drupal без какой-либо настройки. Автоматически предоставляет каждую сущность контента в виде чётко структурированной конечной точки. | Выбор по умолчанию для большинства мобильных приложений — предсказуемо, последовательно, не требует настройки. |
| REST (RESTful Web Services) | Классический подход, также встроен в ядро. Конечные точки настраиваются для каждого ресурса с большим ручным контролем. | Простые интеграции или случаи, когда нужна конкретная нестандартная форма конечной точки. |
| GraphQL | Язык запросов (через контрибьютный модуль), позволяющий клиенту запрашивать ровно те поля, которые ему нужны, за один вызов. | Сложные приложения, которым нужно минимизировать количество запросов и получать точные наборы данных. |
Для большинства мобильных проектов JSON:API — естественная отправная точка. Он входит в ядро, не требует настройки для включения и следует строгой спецификации, а значит, мобильный разработчик точно знает, как будут выглядеть ответы. Его структура также предсказуемым образом обрабатывает связи между сущностями контента — курс и его преподавателя, мероприятие и место его проведения, — что часто требуется в институциональных приложениях. GraphQL становится привлекательным, когда экрану приложения нужно одновременно получить множество разных данных и вы хотите избежать многочисленных повторных запросов; компромисс — дополнительная настройка и сложность. Как общее правило: начинайте с JSON:API и переходите к GraphQL только тогда, когда это оправдано конкретной потребностью в производительности.
Аутентификация: почему мобильные приложения не могут полагаться на cookie
Аутентификация — первое настоящее техническое препятствие при разработке decoupled мобильного приложения, и оно застаёт врасплох многие команды. Традиционный сайт на Drupal аутентифицирует пользователей с помощью сессионных cookie, которыми управляет браузер. У нативного мобильного приложения нет ни браузера, ни хранилища cookie, поэтому этот механизм просто не применим. Приложению нужно аутентифицироваться иначе.
Стандартное решение — аутентификация на основе токенов. Пользователь один раз вводит свои учётные данные; приложение отправляет их в Drupal; Drupal их проверяет и возвращает токен; приложение сохраняет этот токен и прикладывает его к каждому последующему запросу. Преобладают два подхода:
- OAuth 2.0 (модуль Simple OAuth): рекомендуемый подход для большинства decoupled-приложений. Выдаёт токены доступа и обновления, поддерживает современные потоки, включая PKCE для публичных клиентов, таких как мобильные приложения, и чисто интегрируется с централизованными системами идентификации. Этим путём идёт большинство институциональных проектов.
- JWT (JSON Web Token): облегчённая альтернатива, при которой сам токен несёт идентификацию пользователя. Он прост и не требует хранения состояния, хорошо подходит для несложных приложений без сложных требований к авторизации.
Для учреждений, уже использующих единый вход, слой OAuth может подключить приложение к тому же центральному поставщику идентификации, который используется везде, — так студенты и сотрудники входят в приложение с уже имеющимися учётными данными. Важно правильно настроить аутентификацию на раннем этапе — гораздо сложнее позже встроить безопасный поток токенов в приложение, построенное вокруг более простого предположения, чем спроектировать его так с самого начала.
Слой, специфичный для мобильных устройств: офлайн, push-уведомления и медиа
Большинство руководств по decoupled Drupal останавливаются на API и аутентификации. Но мобильное приложение живёт на устройстве с нестабильным подключением, ограниченной пропускной способностью и собственной системой уведомлений, и эти реалии требуют планирования, которое никогда не требуется для сайта.
- Офлайн-доступ и кэширование: мобильный пользователь ожидает, что приложение будет работать в поезде или в лекционном зале при слабом сигнале. Приложение должно кэшировать контент локально и синхронизироваться с Drupal при восстановлении соединения. Слой API поддерживает это, предоставляя кэшируемые структурированные ответы, которые приложение может сохранять и обновлять, — но логика кэширования и синхронизации находится на стороне приложения и должна быть спроектирована осознанно.
- Push-уведомления: уведомления — одна из главных причин, по которым учреждениям вообще нужно нативное приложение: новая оценка, изменение расписания, экстренное оповещение. Drupal выступает источником триггера: когда контент публикуется или срабатывает событие, Drupal обращается к push-сервису (например, Firebase Cloud Messaging), который доставляет уведомление на устройства. Контент и триггер находятся в Drupal; доставку обеспечивает инфраструктура уведомлений платформы.
- Оптимизация медиа и изображений: мобильные экраны и мобильные тарифные планы делают работу с изображениями критически важной. Система медиа и стили изображений Drupal могут генерировать версии каждого изображения подходящего размера, так что приложение запрашивает вариант, оптимизированный для мобильных устройств, а не скачивает файл в полном разрешении, предназначенный для десктопа. Это напрямую влияет на время загрузки и расход трафика.
- Progressive Web Apps как промежуточный путь: не каждому учреждению нужно полноценное нативное приложение. Progressive Web App (PWA) обеспечивает значительную часть нативного опыта — установку на главный экран, офлайн-поддержку, push-уведомления — из единой веб-кодовой базы, и Drupal поддерживает это через специальный модуль PWA. Для многих кампусов PWA — более дешёвый путь к опыту, похожему на приложение, прежде чем переходить к нативной разработке.
Развязанная, прогрессивно развязанная или связанная архитектура?
Полный переход на развязанную архитектуру — серьёзное обязательство, и это не всегда правильный ответ по умолчанию. Честно понимать, когда не стоит развязывать систему, так же важно, как знать, когда стоит. Существует три основные модели:
- Связанная (традиционный Drupal): Drupal управляет и контентом, и представлением. Это остаётся правильным выбором для стандартного сайта без отдельного приложения или фронтенд-фреймворка. Если нет мобильного приложения и второго канала, развязка добавляет затраты без пользы.
- Прогрессивно развязанная: Drupal отрисовывает большую часть страницы, но передаёт отдельные интерактивные компоненты JavaScript-фреймворку. Это сохраняет редакционные и макетные инструменты Drupal нетронутыми, добавляя при этом насыщенную интерактивность там, где она нужна, — полезный промежуточный вариант для сайта, которому нужно некоторое поведение, похожее на приложение, без полной перестройки.
- Полностью развязанная: Drupal выступает исключительно бэкендом, а один или несколько независимых фронтендов (мобильное приложение, отдельное веб-приложение) потребляют его API. Это модель, которую требует нативное мобильное приложение, и это правильный выбор, когда вы действительно обслуживаете несколько каналов, — но это означает, что команда фронтенда берёт на себя обязанности, которые раньше выполнял Drupal, от маршрутизации до SEO и доступности.
Решающий фактор — сколько фронтендов должен обслуживать контент. Единственный сайт лучше оставить связанным. Сайт плюс нативное мобильное приложение указывает на развязанную или гибридную архитектуру. Ошибка — развязывать систему ради самой развязки: полностью развязанная сборка для проекта, которому всегда был нужен только один сайт, добавляет сложность и затраты, которые учреждению придётся поддерживать годами. Более широкие компромиссы между платформами мы рассмотрели в нашем сравнении Drupal, WordPress и Joomla.
Выбор фронтенда: React Native, Flutter и нативная разработка
Поскольку бэкенд Drupal с подходом API-first независим от фронтенда, он работает с любой мобильной технологией, которую предпочитает команда. API всё равно, кто его потребляет, а значит, решение можно строить исходя из требований приложения и навыков команды.
- React Native: популярный кроссплатформенный выбор, позволяющий строить приложения для iOS и Android из единой JavaScript-кодовой базы. Он естественно сочетается с JSON:API от Drupal, и за ним стоит большая экосистема и пул специалистов.
- Flutter: кроссплатформенный фреймворк от Google на языке Dart, известный плавной производительностью и единообразным внешним видом на разных платформах. Он потребляет API Drupal так же легко, как и любой другой клиент.
- Нативная разработка (Swift / Kotlin): раздельная разработка для iOS (Swift) и Android (Kotlin) даёт наиболее глубокую интеграцию с платформой и лучшую производительность при более высокой стоимости разработки. Бэкенд Drupal обслуживает оба приложения одинаково.
Ключевой момент в том, что это действительно открытый выбор. Поскольку бэкенд предоставляет стандартные API, учреждение не привязано к какой-либо одной технологии фронтенда и может даже сменить её позже, не затрагивая слой контента.
Распространённые ошибки при сборке мобильного приложения по подходу API-first
- Развязка системы там, где в ней не было необходимости: самая распространённая ошибка. Если нет второго канала, связанный сайт на Drupal проще, дешевле и легче в обслуживании. Развязывайте систему потому, что у вас есть мобильное приложение, а не потому, что это звучит современно.
- Откладывание аутентификации на потом: аутентификация на основе токенов формирует всю архитектуру приложения. Проектируйте поток OAuth или JWT с самого начала, а не после того, как приложение уже построено вокруг предположений о сессиях.
- Забывание о том, что теперь относится к фронтенду: в развязанной сборке команда фронтенда наследует маршрутизацию, SEO, доступность и метаданные — то, что раньше Drupal обрабатывал автоматически. Это нужно планировать явно, иначе этого просто не произойдёт.
- Игнорирование слоя, специфичного для мобильных устройств: офлайн-поведение, push-уведомления и оптимизация изображений — не второстепенные детали. Приложение, которое не справляется со слабым соединением или отдаёт изображения десктопного размера, будет казаться сломанным независимо от того, насколько чист API.
- Избыточная выгрузка данных: запрос большего объёма данных, чем нужно экрану, впустую расходует пропускную способность и заряд батареи. Используйте фильтрацию полей JSON:API или GraphQL там, где это уместно, чтобы получать только то, что необходимо.
- Отношение к API как к второстепенной детали: весь смысл подхода API-first в том, чтобы заранее и осознанно спроектировать модель контента и её API. Прикручивание API к структуре контента, которая никогда не предназначалась для внешнего потребления, приводит к неудобным, неэффективным конечным точкам.
При продуманном подходе бэкенд Drupal с архитектурой API-first даёт учреждению единый, хорошо структурированный источник контента, способный обеспечивать работу сайта, мобильного приложения и всего, что появится в будущем, — без дублирования контента и без перестройки фундамента каждый раз заново. Это естественное решение для организаций, которые уже полагаются на структурированный контент Drupal и хотят распространить его на новые каналы. Чтобы увидеть более широкий спектр возможностей платформы, ознакомьтесь с нашим обзором того, что можно сделать с Drupal, который описывает смежные сценарии, а руководство что такое Drupal раскрывает основы его модели структурированного контента.
Часто задаваемые вопросы о Drupal и мобильных приложениях
Является ли Drupal хорошим бэкендом для мобильного приложения?
Да, особенно когда приложению нужно делиться контентом с сайтом или другими каналами. Возможности Drupal в подходе API-first заложены прямо в ядро, поэтому он может предоставлять структурированный контент для iOS, Android или любого другого фронтенда через стандартные API без необходимости в специальной инфраструктуре. Он особенно хорошо подходит, когда приложению важно управление контентом корпоративного уровня «за кадром» — редакционные процессы, детализированные права доступа, многоязычный контент и надёжная работа с медиа. Для автономного приложения без общего контента и без потребности в управлении контентом может хватить более лёгкого бэкенда; аргументы в пользу Drupal усиливаются вместе с ростом сложности контента.
Нужно ли мне знать PHP, чтобы создать мобильное приложение на Drupal?
Нет, не для самого приложения. В decoupled-архитектуре мобильное приложение строится с использованием мобильных технологий — React Native, Flutter, Swift или Kotlin — и взаимодействует с Drupal исключительно через API. Мобильные разработчики работают на своём языке и никогда не касаются PHP. Знание PHP актуально только на стороне Drupal — для настройки бэкенда, моделирования контента и кастомизации слоя API, чем обычно занимается команда Drupal, а не команда приложения.
JSON:API или GraphQL для мобильного приложения?
Начните с JSON:API. Он включён в ядро Drupal без какой-либо настройки, следует строгой и предсказуемой спецификации и покрывает потребности большинства мобильных приложений сразу же после установки. GraphQL стоит рассмотреть, когда экранам приложения нужно за один запрос получить множество разных данных и вы хотите минимизировать количество повторных обращений — но это добавляет настройку и сложность через контрибьютный модуль. Практичный путь — использовать JSON:API по умолчанию и переходить к GraphQL только тогда, когда это оправдано конкретной потребностью в производительности.
Можно ли одному бэкенду на Drupal одновременно обслуживать и сайт, и мобильное приложение?
Да, и это одна из самых веских причин выбирать подход API-first. Один бэкенд на Drupal может одновременно обслуживать и сайт, и мобильное приложение из одного и того же контента. Объявление или курс, введённые один раз, появляются в обоих местах, всегда синхронно, без дублирования усилий. Именно это на практике означает «один источник контента, много каналов» — и это ключевое преимущество построения архитектуры по подходу API-first с самого начала.