Juin 2016

Volume 31, numéro 6

MBaaS - Ускорение мобильной разработки с применением платформы MBaaS

Парас Вадера | Июнь 2016

Продукты и технологии:

Mobile Backend as a Service (MBaaS)

В статье рассматриваются:

  • аутентификация;
  • доступ к данным;
  • добавление и редактирование автономных данных;
  • всплывающие уведомления от сервера (push notifications);
  • файловое хранилище и доступ к нему.

Очень большая доля расходов на разработку мобильных приложений вызывается интеграцией серверной части (back-end). Более того, в большинстве приложений имеется базовый набор функций, который лишь слегка варьируется в разных приложениях. Поэтому вместо того, чтобы снова и снова создавать одни и те же функции и компоненты с нуля для каждого приложения, было бы гораздо лучше сосредоточиться на том, что делает мобильное приложение популярным, — на пользовательской среде (UX) и просто использовать (а не создавать) другие критически важные функции приложения. Именно эта идея и лежит в основе платформы Mobile Backend as a Service (MBaaS), которая предоставляет эти важные, но общие для приложений функции как сервис, который вы можете использовать, экономя уйму времени и денег на разработке приложений, в то же время фокусируясь на создании UX для ваших пользователей.

Платформа MBaaS не только избавит вас от необходимости изобретать колесо в каждом приложении, но и позволит вести «раздельную» разработку для клиентской и серверной части приложения. То есть теперь становится возможной параллельная разработка клиентской и серверной частей, и их соединение потребует лишь «щелкнуть включатель», когда обе части будут закончены.

Я намерен пройти вместе с вами основные этапы процесса разработки корпоративного приложения-примера, используя подходы «сделай сам» (do it yourself, DIY) и MBaaS, а затем сравнить эти подходы, чтобы понять, в какого рода сценариях один из подходов эффективнее другого. Высокоуровневые требования в этом случае применения описаны ниже. Приложение должно:

  • аутентифицировать своих пользователей через Active Directory Federation Services (AD FS);
  • подключаться к экземпляру SharePoint и отображать данные из него, но при этом нужно фильтровать данные, а не показывать весь набор записей из SharePoint;
  • давать возможность пользователю просматривать данные в автономном режиме;
  • разрешать пользователю добавлять новые записи в автономном режиме и автоматически синхронизировать эти записи с сервером, как только приложение вновь выйдет в онлайн;
  • принимать уведомления от сервера, подтверждающие успешное сохранение новой или обновленной записи в SharePoint;
  • позволять делать снимок и загружать его на сервер подключенным к созданной записи.

Теперь вообразите, что вы только что получили эти требования и что вас попросили создать мобильное приложение. С чего вы начнете? Давайте рассмотрим варианты.

Один из вариантов — подготовить все сервисы серверной части вроде AD FS и SharePoint наряду с сервером для хостинга ваших файлов (снимков в данном случае). Вам также понадобилось бы создать сервисы поверх AD FS и SharePoint, чтобы вы могли подключаться к ним из мобильного приложения и взаимодействовать с ними. Затем вы создали бы клиентское мобильное приложение, которое подключается к этим сервисам.

Вы также могли бы начать с создания клиентского мобильного приложения, сделав так, чтобы поначалу оно обращалось к имитациям данных и источников аутентификации, а потом обновить его для обращения к реальным данным и источникам аутентификации, как только будут готовы сервисы в серверной части. Однако это потребует от вас создания имитаций данных и систем аутентификации или сервисов, используемых для построения мобильного приложения.

При любом из этих вариантов подхода DIY вашему клиентскому приложению понадобится «разговаривать» на том же языке, что и серверной части, и создается потенциальный риск нарушения работы клиента, если серверная часть изменится, а это потребует от вас дорогостоящих и отнимающих немало времени исправлений в клиентском приложении.

В противоположность этому применение платформы MBaaS означает, что клиентское мобильное приложение и сервисы в серверной части можно создавать одновременно двумя разными группами (это ускорит время выхода продукта на рынок) и что эти две части потом можно подключить друг к другу средствами самой платформы MBaaS. Одно из нескольких преимуществ этого подхода в том, что вам не придется заботиться о создании сервисов-заглушек для имитации источников данных и аутентификации.

Применение платформы MBaaS означает, что клиентское мобильное приложение и сервисы в серверной части можно создавать одновременно двумя разными группами.

Платформа MBaaS предоставляет вам SDK как для «родных», так и для гибридных платформ. Вы просто интегрируете соответствующий SDK для выбранной вами платформы в свою среду разработки и пишете код с использованием этого SDK, что упрощает потребление сервисов в серверной части. Одна из наиболее важных особенностей MBaaS, которые будут использоваться вашими приложениями, — интеграция с данными на серверной стороне и источниками идентификации. Платформа MBaaS также предоставляет уровень абстракции, тем самым скрывая сложности серверной части от клиентского мобильного приложения.

Давайте подробнее рассмотрим, что включает каждый из этих вариантов. Я проанализирую каждую из обязательных функций приложения и сначала сосредоточусь на подходе DIY к реализации этих функций, а затем сравню с тем, как все это делается при использовании MBaaS. В заключение я дам сравнение этих двух подходов в целом.

Аутентификация

При подходе DIY вы должны сначала создать коннектор с AD FS, а затем использовать этот коннектор для аутентификации пользователя. Коннектор должен быть применимым из мобильного приложения и должен обеспечивать передачу имени пользователя и пароля из приложения в Active Directory для аутентификации. Когда Active Directory успешно аутентифицирует пользователя, она возвращает маркер аутентификации, который нужно разобрать, зашифровать и сохранить для использования в будущих вызовах. Кроме того, если провайдер аутентификации поддерживает маркеры обновления (refresh tokens), вам понадобится так написать код, чтобы он автоматически обновлял маркер аутентификации по истечении его срока действия.

В случае MBaaS, напротив, вы делаете вызов аутентификации, используя клиентский SDK для аутентификации пользователя, например:

MBaaS.login(redirectURI);

В зависимости от типа аутентификации провайдер может отобразить собственный экран входа (стиль OAuth), а провайдер MBaaS — свою версию экрана входа. Все провайдеры MBaaS предлагают, как минимум, несколько коннекторов, не требующих кода, для подключения к корпоративным источникам идентификации, в том числе к AD FS. Вы просто передаете несколько конфигурационных параметров облачному порталу MBaaS и настраиваете MBaaS на взаимодействие с вашим экземпляром AD FS. Типы предоставляемых вами параметров включают URI входа у провайдера, URI выхода, текст сертификата и идентификатор названия формата URI (name ID format URI) наряду с URI перенаправления и сроком действия (time-to-live, TTL) маркера аутентификации. Вы должны получить все эти значения от администратора AD FS в своей организации. Простой настройкой этих параметров вы создаете соединение со своим экземпляром AD FS.

Сложность реализации общего процесса аутентификации упрощается до одной строки кода. Все сложности серверной части вроде квитирования аутентификации (authentication handshake), получения маркера аутентификации, его шифрования, сохранения и т. д. теперь берут на себя платформа MBaaS и соответствующий SDK.

Доступ к данным

Выборка данных при подходе DIY кажется прямолинейной — пока вы ничего особенного не делаете. Она неплоха для источников данных, которые по умолчанию предоставляют потребляемый веб-сервис поверх данных. Может даже оказаться легко подключиться напрямую к источнику данных из веб-приложения. Однако мобильные платформы, как правило, не располагают теми же коннекторами, что и веб-приложения, для корпоративных источников данных. А значит, придется писать собственный коннектор, скорее всего в виде веб-сервиса, который взаимодействует с источником данных и предоставляет его данные с помощью обычных HTTP-команд наподобие GET, PUT, POST и DELETE. Более того, этот коннектор надо будет где-то разместить. В большинстве случаев к вашему приложению будут обращаться извне вашей сети, а значит, создаваемый вами веб-сервис должен уметь взаимодействовать как с внешним миром, так и с внутренним (который скрыт за корпоративным брандмауэром), т. е. в брандмауэре, по-видимому, придется «сверлить дырку». После создания собственного коннектора вы можете подключиться к нему из мобильного приложения и выполнять все соответствующие операции над данными. Но как быть, если вы должны разрешить пользователю извлекать лишь определенные наборы записей по его запросам? Это потребует создания в веб-сервисе средств обработки запросов, что может оказаться весьма трудным делом, особенно если вам нужно, чтобы пользователи могли выдавать сложные запросы.

Большинство систем MBaaS предоставляет готовые коннекторы для нескольких корпоративных источников данных, т. е. вы просто конфигурируете их, а не создаете. Для примера случая применения вы сконфигурировали бы коннектор для SharePoint, передав конфигурационные параметры вроде URL хоста, имени и пароля пользователя для соединения с вашим экземпляром SharePoint. Использовать данные от SharePoint в мобильном приложении не сложнее, чем написать эту строку кода:

MBaaS.data.get(NameofDataCollection [,QueryParams] [,Options]);

Обычно это возвращает массив JSON-объектов из вашего источника данных. Одно из преимуществ использования готового коннектора от провайдера MBaaS заключается в том, что такие коннекторы позволяют обнаруживать все объекты в вашем хранилище данных и поэтому вы можете просто распознать все списки SharePoint и выбрать из них те, к которым вы хотите обеспечить доступ из мобильного приложения. Кроме того, вы можете фильтровать и контролировать поля, возвращаемые SharePoint, сводя их набор лишь к тому, что требуется в мобильном приложении; благодаря этому большие наборы данных не посылаются на мобильное устройство, когда приложению на самом деле требуется лишь их малая доля. И вновь фильтрацию можно применять без написания какого-либо кода — огромное преимущество для разработчиков мобильных приложений. Без MBaaS, предоставляющей такой набор функциональности, все бремя фильтрации и контроля данных ложится либо на мобильное приложение (что потребует большей пропускной способности и высокого потребления аккумулятора на устройстве, а это никогда не было хорошей идеей для мобильных устройств), либо на серверный скрипт, который вам понадобится написать, где-то разместить и управлять им (а это подразумевает постоянную работу с ним и его сопровождение). Ввод QueryParams в метод в предыдущей строке кода позволяет передавать параметры в запросе, чтобы обеспечить поиск и фильтрацию записей на основе ваших требований или ввода от пользователя.

Использование клиентского SDK от провайдера MBaaS должно значительно облегчить поддержку работы с автономными данными в вашем приложении.

Платформа MBaaS также предоставляет хранилища данных и файлов, встроенных в саму платформу, чтобы приложения, не имеющие собственного источника данных, могли использовать встроенное хранилище MBaaS для сохранения и потребления данных.

Автономные данные

Просто сделать данные доступными для автономного потребления при подходе DIY довольно легко. Вам нужно лишь сохранить данные на локальном устройстве (либо в локальном хранилище, либо в хранилище данных вроде SQLite) и считывать их оттуда, когда пользователь попытается обратиться к этим данным в приложении.

Однако не так-то просто обеспечить поддержку автономного редактирования существующих данных или добавление новых данных и последующей их синхронизации с сервером, в то же время разрешая конфликты, возможные при таком подходе. Любой, когда-либо пытавшийся реализовать код для разрешения конфликтов, скажет вам, что это не самая забавная штука. Вы должны проверять, какие сущности были модифицированы локально, а какие — на сервере в то же самое время, затем выяснить, какие атрибуты каждой сущности были модифицированы и, если на клиенте и сервере были изменены одни и те же атрибуты одной и той же сущности, решить, какое изменения приоритетно, а потом сохранить его как значение в записи.

Использование клиентского SDK от провайдера MBaaS должно значительно облегчить поддержку работы с автономными данными в вашем приложении. Если взять пример с потреблением данных из предыдущего раздела, то вы просто передали бы в вызове нужные значения параметров:

MBaaS.data.get(NameofDataCollection [,QueryParams],
  Data.Offline, Data.EncryptFull);

В этом коде я разрешаю использовать автономное хранилище данных на устройстве, а также шифрование данных. Как SDK хранит данные для автономного потребления, варьируется от провайдера к провайдеру, но реализация этого не должна влиять на то, как вы взаимодействуете с MBaaS SDK. SDK возьмет на себя все сложности, связанные с реализацией поддержки автономных данных. Еще лучше, что для включения шифрования достаточно задать соответствующий параметр. Это делает автономное хранилище данных защищенным, что является ключевым требованием к большинству корпоративных приложений. MBaaS SDK автоматически расшифровывает данные при операциях пользователя над ними или при их отображении на экране и зашифровывает введенные пользователем данные перед сохранением на устройстве. Как правило, SDK также берет на себя поддержку редактирования автономных данных и добавление новых данных. Однако, чтобы это работало ожидаемым образом, в серверных системах должен быть реализован LastUpdatedTime для каждой записи. Аналогично задание параметров для разрешения конфликтов при одновременном обновлении записи на обеих сторонах определяет, какие изменения приоритетны — на клиенте или сервере.

Всплывающие уведомления

Подготовка всплывающих уведомлений (push notifications) для DIY-проекта может оказаться трудной задачей. Как показано на рис. 1, для успешной настройки канала передачи всплывающих уведомлений и самой передачи таких уведомлений нужно выполнить ряд этапов. (Подробнее см. по ссылке bit.ly/UWPPush.)

Схема подготовки и отправки всплывающих уведомлений
Рис. 1. Схема подготовки и отправки всплывающих уведомлений/strong>

Universal Windows Platform App  Приложение Universal Windows Platform 
App’s Cloud Service Облачный сервис приложения
Universal WindowsPlatform Universal Windows Platform
Windows Notification Service Windows Notification Service

 

  1. Приложение Universal Windows Platform (UWP) запрашивает канал всплывающих уведомлений от операционной системы.
  2. Новый канал уведомления создается Windows Notification Service (WNS) и возвращается вызвавшему устройству в виде Uniform Resource Identifier (URI).
  3. Windows возвращает вашему приложению URI канала уведомлений.
  4. Ваше приложение посылает этот URI собственному облачному сервису, где он сохраняется, чтобы вы могли обращаться по этому URI при отправке уведомлений.
  5. Когда у вашего облачного сервиса появляется уведомление для передачи, он информирует WNS, используя ранее зарегистрированный URI. Для этого выдается HTTP-запрос POST, включающий уведомление, поверх Secure Sockets Layer (SSL).
  6. WNS принимает запрос и направляет уведомление соответствующему устройству.

Кроме того, вам потребуется запрашивать канал при каждом запуске приложения, так как срок действия URI канала может истечь и нет никаких гарантий, что URI предыдущего канала все еще будет действителен. Если возвращенный URI канала отличается от URI, который вы использовали, вам понадобится обновить URI в своем облачном сервисе. Вы также должны сопоставить URI канала с идентификатором устройства для пользователя, чтобы вы могли обновить URI соответствующего канала на сервере.

Любая хорошая платформа MBaaS обеспечивает способы упрощения настройки всплывающих уведомлений. Вспомните этапы, которые вы только что видели и которые необходимы для успешной передачи такого уведомления UWP-приложению? Теперь посмотрите на рис. 2, где показано, что вам не придется делать при использовании платформы MBaaS.

Complexité de Notification push prises en charge par MBaaS
Рис. 2.complexités liées aux notifications Push prises en charge par MBaaS

DIY DIY
MBaaS MBaaS
Request Push Notification Channel Запрашиваем канал всплывающих уведомлений
Set up server for managing push registration Настраиваем сервер на управление регистрацией уведомлений
Upload notification channel URI to server Загружаем URI канала уведомлений на сервер
Set up server-side script to determine who gets push Подготавливаем серверный скрипт для определения того, кто получает уведомления
Create script to send push Создаем скрипт для отправки всплывающих уведомлений

 

Как видите, MBaaS скрывает все сложности подготовки, управления и отправки всплывающих уведомлений пользователям. Все это обрабатывается одним вызовом, выдаваемым с использованием клиентского SDK:

MBaaS.registerForPush();

и написанием бизнес-логики на серверной стороне (в рамках платформы MBaaS), определяющей, когда следует отправить уведомление, и вызывающей предопределенный метод, который посылает уведомление соответствующим пользователям.

Файловый сервер

Следуя по пути DIY, вы должны разместить свой файловый сервер и управлять им, что пользователи могли делать снимки со своих устройств и загружать их на сервер, а также управлять доступом пользователей к этим файлам, чтобы один из пользователей не мог обратиться к файлам другого пользователя. Кроме того, вам нужно управлять временем бесперебойной работы сервера, а также масштабируемостью, производительностью и обновлениями безопасности.

С помощью платформы MBaaS вам, по-видимому, не придется ничего реализовать для размещения файлов в облаке. Одна из функций платформ MBaaS — готовый уровень доступа к файловому хранилищу. Вы получаете полностью поддерживаемое CDN файловое хранилище для размещения всех распространенных типов файлов: PDF, изображений, видеороликов, офисных документов и т. д. Как и в случае других функций, вам потребуется лишь сделать простой вызов метода в MBaaS SDK для работы с файлами, хранящимися в облаке. Files API позволяет загружать, скачивать и обеспечивает потоковую передачу файлов в File Store и из него, используя вызове наподобие:

MBaaS.File.upload(FileName);
MBaaS.File.download(FileName or FileID);

Это избавляет вас от головной боли управления огромным файловым сервером (в зависимости от количества и размера сохраняемых файлов) и, в том числе, позволяет расширять и сокращать хранилище на основе потребностей в любой момент времени, а также управлять как временем бесперебойной работы, так и задержками при доступе к файлам.

Другие функции MBaaS

Я описал набор функций приложения-примера в начале этой статьи, но хотел бы также подчеркнуть пару других функций платформы MBaaS, способных облегчить разработку приложений.

  • Бизнес-логика на серверной стороне позволяет выполнять тяжелую обработку на сервере вместо того, чтобы расходовать ресурсы на клиентском устройстве. Кроме того, вы можете фильтровать данные из источника, чтобы отправлять лишь те из них, которые действительно нужны мобильному устройству, экономя его пропускную способность. Более того, можно перехватывать любые вызовы, направляемые через платформу MBaaS.
  • Кеширование на серверной стороне поддерживает сценарии, где необходима UX с временем реакции менее секунды. Традиционные корпоративные источники данных зачастую отвечают на запрос в течение нескольких секунд, но мобильные пользователи ожидают гораздо более быстрого ответа, и, если загрузка приложения происходит слишком долго, они просто удаляют это приложение и уходят к конкуренту. Благодаря функции кеширования на серверной стороне данные из корпоративного источника можно кешировать на платформе MBaaS для быстрого ответа на запросы от мобильного приложения, а кеш будет автоматически обновляться из оригинального источника данных в фоновом режиме.

Заключение

Подходы DIY и MBaaS занимают свои места в разработке приложений. Преимущества применения платформы MBaaS очевидны, но в некоторых случаях имеет смысл выбрать подход DIY. К таких случаям относятся проекты разработки единственных в своем роде приложений, уже имеющих все необходимые сервисы для подключения к данным и источникам идентификации. Для сценариев, где сервисы соединения с источниками данных и идентификации пока не созданы и где они понадобятся для потребления из нескольких приложений, платформа MBaaS может реально ускорить мобильную разработку, предоставляя большинство сложных функций интеграции серверной части в готовом виде. С помощью MBaaS можно сосредоточиться на UX приложения, не беспокоясь об интеграции источников данных и идентификации, шифровании, реализации поддержки автономной работы, разрешении конфликтов, подготовке к использованию уведомлений и других базовых, но крайне важных компонентов мобильных приложений.

В конечном счете выигрыш дает абстракция, предоставляемая платформой MBaaS; эта абстракция позволяет сколь угодно часто изменять источники данных и идентификации в вашей серверной части. Вы также можете модифицировать бизнес-логику на серверной стороне без необходимости переписывать хотя бы одну строку кода в мобильном приложении. Мобильные SDK в MBaaS работают с этой абстракцией, обеспечивая выполнение вашего приложения и избавляя вас от обновления, тестирования (в том числе от модульного, интеграционного и регрессионного тестирования), развертывания и повторного ожидания одобрения от магазина!

Один из недостатков в том, что при использовании MBaaS может быть затруднена смена платформ, так как реализации коннекторов абстрагируются. При подходе DIY вы располагаете кодом для всех коннекторов, и поэтому вам легче адаптировать их под будущие потребности.

MBaaS действительно обеспечивает существенную экономию затрат времени и усилий при создании мобильных приложений и их дальнейшего сопровождения.


Парас Вадера (Paras Wadehra) — опытный архитектор программного обеспечения, решающий проблемы в области создания приложений, которые работаю через Web, а также на настольных и мобильных платформах. Занимается разработкой для всех основных мобильных платформ, в том числе для iOS, Android и Windows. Пишет код на C#, Node.js, JavaScript, SQL, Swift и многих других языках. В настоящее время является обладателем звания Microsoft MVP в номинации Windows Development. Выступает на различных конференциях и отраслевых мероприятиях. С ним можно связаться в Twitter (@ParasWadehra) и через LinkedIn.

Выражаю благодарность за рецензирование статьи экспертам Хермиту Дэйву (Hermit Dave) из Associated Press Limited, UK, Курту Монни (Kurt Monnier) из Kinvey, Inc. и Аруну Нагараджану (Arun Nagarajan) из Uber.