Блог Георгия Могелашвили

Облачный бекенд для мобильных приложений своими руками. Часть 2

Облачный бекенд для мобильных приложений своими руками. Часть 2

В первой части я рассказал, как создать RESTful API в облаке Microsoft Azure и как начать его использовать в своем мобильном приложении. Рекомендую ознакомиться с той статьей, поскольку данный текст и примеры во многом опираются на нее.

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

Microsoft Azure и Git

Как вы неверно уже слышали, компания Microsoft, к ее чести, в последнее время все чаще обращает свое внимание на Open Source технологии. Так, например, в последней версии Visual Studio 2013 была «из коробки» внедрена поддержка системы контроля версий Git. Облако Microsoft Azure тоже не осталось в стороне, и теперь позволяет работать с кодом не только через TFS, но и с помощью Git и прочих систем (SVN, Dropbox, Bitbucket).

В Microsoft Azure Mobile Services решили пойти дальше и оставить для работы только Git. Возможно это так только на время Preview-версии данного решения, но, учитывая тенденции корпорации, такой вариант может перекочевать в релиз.

Что же нам дает использование Git в своем проекте? Да все абсолютно то же, что и всегда. А именно — совместная работа над кодом, локальные репозитории у каждого участника команды, поддержка версионности. Но что еще важно, так это соблюдения принципа continuous integration — непрерывное развертывание решения при каждом новом чекине кода в репозиторий. Каждый раз, когда кто-то из участников команды отправляет свои изменения на сервер, происходит их деплой в облаке. Все это работает на Kudu (кстати, еще один open source проект), и довольно успешно.

Включение Git в своем сервисе

Для того, чтобы начать использовать Git для работы с Mobile Services, необходимо перейти в панель управления данной службой и выбрать соответствующий пункт:

Создание репозитория Git в Microsoft Azure Mobile Services

Вас спросят, уверены ли в своем действии и предупредят, что пока функция находится в стадии Preview возможны какие-то неполадки. Соглашаемся и продолжаем.

После того, как создание репозитория завершится, вы сможете посмотреть параметры доступа к нему на странице Configure в панели управления службами. В секции Source Control будет два параметра: URL доступа к репзиторию и URL, обращение к которому будет запускать развертывание вашего решения:

Конфигурация репозитория в Microsoft Azure

После выполнения операции создания ваш облачный Git готов к работе. Давайте получим файлы, которые хранятся на сервере, в свой локальный репозиторий. Для этого можно воспользоваться стандартной консолью Git (например Git Bash для Windows).

Клонирование серверного репозитория локально выполняется с помощью команды

git clone <URL_репозитория>

Клонирование репозитория локально

Необходимо указать URL, указанный в параметре GIT URL в конфиге облачного сервиса. Также необходимо будет ввести логин и пароль пользователя Git (если у вас его не было, то при первом создании Git репозитория Microsoft Azure предложит придумать эту пару). В результате должно получиться примерно так, как на картинке ниже:

Результат выполнения клонирования репозитория

Структура репозитория

Как только команда завершится, у вас на жестком диске появится директория с названием мобильной службы. Внутри нее будет папка service и файл .deployment. Файл интереса не представляет, а вот внутрь папки service стоит заглянуть.

$ ls
api  extensions  package.json  scheduler  shared  table

Если обратить внимание на имена папок, находящихся внутри service, то можно проследить закономерность, что все они называются так же, как и подсистемы мобильных служб Microsoft Azure (API, планировщик и таблицы), плюс две директории с названиями extensions и shared.

Директория API

Директория API отвечает за хранения файлов, описывающих код Custom API (то, что мы создали в первой части). Если перейти в директорию и посмотреть ее содержимое, то там должно быть три файла:

$ ls
coolapi.js  coolapi.json  readme.md

Не считая файла readme.md, который есть в каждой папке и просто описывает ее содержимое, здесь хранятся js-скрипты, по одному на каждый API, который у вас есть. Также, на каждый скрипт с кодом приходится по одному файлу .json, который описывает права доступа к конкретному API. Давайте посмотрим на содержимое этих файлов. Ниже — содержимое файла coolapi.js:

exports.post = function(request, response) {
    // Use "request.service" to access features of your mobile service, e.g.:
    //   var tables = request.service.tables;
    //   var push = request.service.push;

    response.send(statusCodes.OK, 'Hello World!');
};

exports.get = function(request, response) {
    var result = {type: 'message', data: 'Hello World!'};
    response.send(statusCodes.OK, result);
};

Как вы видете, файл точь-в-точь повторяет код, который мы писали в предыдущей статье непосредственно в панели управления Microsoft Azure. И это понятно, ведь за каждым API лежит простой js-скрипт, который работает в приложении Node.js.

Файл coolapi.json немного интереснее, поскольку мы его до этого видели только косвенно и не в таком виде:

{
    "routes": {
        "*": {
            "get": {"permission":"application"},
            "post":{"permission":"application"},
            "put":{"permission":"application"},
            "patch":{"permission":"application"},
            "delete":{"permission":"application"}
        }
    }
}

На самом деле это ни что иное, как описание прав доступа к конкретному API, которые мы задавали в самом начале при его создании (правда делали мы это с помощью мастера в портале управления). Здесь для каждого HTTP метода прописаны те или иные ограничения. В нашем случае для всех методов выставлен тип application, означающий, что только те пользователи, у которых есть ключ приложения, имеют доступ к этим методам. Допустимыми значениями также являются:

  • public — доступ разрешен всем (аналог Everyone на портале)
  • user — доступ разрешен только зарегистрированным пользователям (аналог Only Authenticated Users)
  • admin — доступ разрешен только администраторам (аналог Only Administrators)

Если сейчас поменять что либо в тексте любого из этих файлов, а затем сохранить это в репозиторий, то все изменения тут же отобразятся и в портале управления (а значит и станут доступны всем вашим пользователям). Давайте, например, поменяем в одном из методов строку Hello World на Hello from Git, а метод GET сделаем доступным для всех (public), и отправим поправки в облако:

git commit . -m "My first Git commit"
git push

Результат будет выглядеть примерно так:

Результаты git push

Если посмотреть в логи операции, то помимо простого копирования файлов на сервер выполняются работы по развертыванию решения с помощью Kudu.

Теперь, если зайти в портал управления мобильными службами и посмотреть код для данного API, то можно увидеть проделанные изменения:

Код API на портале после работы git push

А если обратиться к API через браузер (что стало возможно после того, как мы ослабили ограничения для метода GET), убедиться, что изменения доступны и извне:

Результат GET операции API

Директория TABLE

В данной папке, как можно догадаться из ее названия, должно храниться что-то, что относится к таблицам, которые есть в Mobile Services. Но хранятся здесь не данные самих таблиц (что логично для Git), а код, который управляет событиями вставки/удаления/изменения записей (подробнее про работу с таблицами можно почитать тут и тут). Я заранее создал таблицу с названием MyTable и немного подкорректировал скрипт, который работает при операции вставки. И вот что я получил в итоге в папке table:

$ ls
MyTable.json  mytable.insert.js  readme.md

Следуя логике наименования файлов в мобильных службах, можно прийти к логическому выводу, что в файле json хранится информация о правах доступа к таблице (и это так, этот файл аналогичен тому, что мы видели в API), а в js-файле хранится код. Причем название файла формируется из имени таблицы, к которой он относится, и операции, для которой он определен. Таким образом, если создать подобный файл непосредственно на вашем локальном компьютере (назвать его, например, mytable.update.js), написать в нем код и закоммитить на сервер, то эти изменения сразу же будут доступны в портале управления, без необходимости ручного создания обработчика операции update.

Директория SHARED

Здесь могут храниться скрипты, которые не относятся к какой-то конкретной части мобильных служб, а наоборот, могут быть использованы повсеместно. Что-то вроде хранилища библиотечного кода в рамках одной службы. Чтобы воспользоваться этим кодом, надо, во-первых, его написать (и сделать это можно только через Git, поскольку прямого доступа к этим скриптам из панели управления нет), а во-вторых, подключить новый модуль в существующем коде.

Вот простой пример. Создадим в папке shared файл с названием myshared.js и следующим содержимым:

exports.someSharedMethod = function () {
    return 'Hello from Shared!';
}

Теперь в коде API используем этот модуль, добавив следующие строки кода:

exports.get = function(request, response) {
    var myshared = require('../shared/myshared.js');
    response.send(statusCodes.OK, myshared.someSharedMethod);
};

Если вы уже работали с Node.js, этот код будет вам знаком. Это стандартный механизм подключения внешних модулей к вашему приложению. По большому счету папка shared — это просто директория на жестком диске, где рекомендуется хранить общие модули. Никакой магии, все по-честному.

Остальные директории

Про оставшиеся две директории можно сказать примерно то же, что и про предыдущие: в них хранится код. В папке scheduler будут лежать скрипты для управления соответствующим сервисом, а в папке extensions хранится код, который может быть подключен ко всему Node.js приложению мобильных служб и который будет выполняться ровно один раз при его запуске. При этом гарантируется, что все остальные операции в приложении будут приостановлены до тех пор, пока работа кода расширения не завершится. Это может быть полезным, если вы хотите делать какие-то специальные настройки в БД при каждом перезапуске мобильных служб.

Пакеты NPM

Если уж мы теперь понимаем, что за кулисами мобильных служб работает приложение на Node.js, то логично спросить — а есть ли NPM? Для тех, кто не знает, NPM — это менеджер пакетов для Node (что-то вроде NuGet или того, что есть в Linux). Это очень полезная вещь при разработке приложений, поскольку позволяет в считанные секунды подключить к своему проекту тонны сторонних библиотек, разработанных для различных целей (обработка ошибок, логирование, шаблонизация видов и т.п.).

К счастью, работать с NPM можно и в Microsoft Azure Mobile Services. Для этого необходимо отредактировать файл package.json (который находится на одном уровне файловой структуры, что и директории api, table и т.п.). Добавив в этот файл упоминание необходимых модулей (стандартным для Node.js образом, в секции dependencies) и закоммитив этот файл обратно на сервер, мы заставим Microsoft Azure выкачать их для нашего приложения. Останется только подключить их через require и можно извлекать всю пользу из творений сообщества.

Заключение

Платформа PaaS, которая есть в Microsoft Azure, предоставляет очень богатые возможности для тех разработчиков, которым нужно быстрое и качественное решение и которые не очень хотят тратить много усилий на развертывание и администрирование инфраструктуры. Microsoft Azure Mobile Services предоставляют богатый функционал широкого назначения. А Custom API, в частности, помогает избежать проблем дублирования кода, когда вам нужно разработать некие общие решения для различных платформ.

Что дополнительно хорошо и почетно для Microsoft, так это то, что компания решила пойти навстречу современным тенденциям и частично отказалась от использования проприетарных технологий в пользу Open Source и кроссплатформенности. Если вы заметили, все вещи, которые я показывал в этой статье, можно сделать абсолютно на любом компьютере, будь то PC или Mac, Windows или Linux. А наличие нативных кроссплатформенных библиотек для всех трех ключевых мобильных устройств (и поддержка REST API для большинства своих сервисов) позволяют пользоваться этим облаком практически отовсюду. По-моему, это отличный подход к ведению бизнеса и прекрасный задел на будущее.

P.S. Напоследок хочется отметить, что поскольку работа с Git репозиториями в мобильных службах пока еще находится в стадии preview, то что-то может быть нестабильно, а что-то со временем может поменяться.
P.P.S. Материалы этой статьи также доступны в форме видеоурока на YouTube или курса на Microsoft Virtual Academy.

Добавить комментарий

Ваш адрес email не будет опубликован.

Этот сайт использует Akismet для борьбы со спамом. Узнайте, как обрабатываются ваши данные комментариев.