Поиск на сайте: Расширенный поиск


Новые программы oszone.net Читать ленту новостей RSS
CheckBootSpeed - это диагностический пакет на основе скриптов PowerShell, создающий отчет о скорости загрузки Windows 7 ...
Вы когда-нибудь хотели создать установочный диск Windows, который бы автоматически установил систему, не задавая вопросо...
Если после установки Windows XP у вас перестала загружаться Windows Vista или Windows 7, вам необходимо восстановить заг...
Программа подготовки документов и ведения учетных и отчетных данных по командировкам. Используются формы, утвержденные п...
Red Button – это мощная утилита для оптимизации и очистки всех актуальных клиентских версий операционной системы Windows...
OSzone.net Microsoft Разработка приложений Облако/Azure Облачный бекенд для мобильных приложений своими руками. Часть 2 RSS

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

Текущий рейтинг: 0 (проголосовало 0)
 Посетителей: 396 | Просмотров: 457 (сегодня 0)  Шрифт: - +

В первой части я рассказал, как создать 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, необходимо перейти в панель управления данной службой и выбрать соответствующий пункт:

*
Увеличить


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

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

*
Увеличить


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

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

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

*
Увеличить

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

*
Увеличить

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


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

$ lsapi  extensions  package.json  scheduler  shared  table


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

Директория API


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

$ lscoolapi.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

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

*
Увеличить


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

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

*
Увеличить


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

*
Увеличить

Директория TABLE

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

$ lsMyTable.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.

Автор: Георгий Могелашвили  •  Иcточник: MSDN  •  Опубликована: 13.08.2014
Нашли ошибку в тексте? Сообщите о ней автору: выделите мышкой и нажмите CTRL + ENTER


Оценить статью:
Вверх
Комментарии посетителей
Комментарии отключены. С вопросами по статьям обращайтесь в форум.