| Новые программы oszone.net |  |
В первой части я рассказал, как создать RESTful API в облаке Microsoft Azure и как начать его использовать в своем мобильном приложении. Рекомендую ознакомиться с той статьей, поскольку данный текст и примеры во многом опираются на нее. Microsoft Azure и GitКак вы неверно уже слышали, компания Microsoft, к ее чести, в последнее время все чаще обращает свое внимание на Open Source технологии. Так, например, в последней версии Visual Studio 2013 была «из коробки» внедрена поддержка системы контроля версий Git. Облако Microsoft Azure тоже не осталось в стороне, и теперь позволяет работать с кодом не только через TFS, но и с помощью Git и прочих систем (SVN, Dropbox, Bitbucket). Включение Git в своем сервисеДля того, чтобы начать использовать Git для работы с Mobile Services, необходимо перейти в панель управления данной службой и выбрать соответствующий пункт: git clone <URL_репозитория>
Структура репозитория
$ lsapi extensions package.json scheduler shared table
Директория API
$ lscoolapi.js coolapi.json readme.md
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. {
"routes": {
"*": {
"get": {"permission":"application"},
"post": {"permission":"application"},
"put": {"permission":"application"},
"patch": {"permission":"application"},
"delete": {"permission":"application"}
}
}
}На самом деле это ни что иное, как описание прав доступа к конкретному API, которые мы задавали в самом начале при его создании (правда делали мы это с помощью мастера в портале управления). Здесь для каждого HTTP метода прописаны те или иные ограничения. В нашем случае для всех методов выставлен тип application, означающий, что только те пользователи, у которых есть ключ приложения, имеют доступ к этим методам. Допустимыми значениями также являются:
Если сейчас поменять что либо в тексте любого из этих файлов, а затем сохранить это в репозиторий, то все изменения тут же отобразятся и в портале управления (а значит и станут доступны всем вашим пользователям). Давайте, например, поменяем в одном из методов строкуHello World на Hello from Git, а метод GET сделаем доступным для всех (public), и отправим поправки в облако: git commit . -m "My first Git commit"git push Результат будет выглядеть примерно так: Директория TABLEВ данной папке, как можно догадаться из ее названия, должно храниться что-то, что относится к таблицам, которые есть в Mobile Services. Но хранятся здесь не данные самих таблиц (что логично для Git), а код, который управляет событиями вставки/удаления/изменения записей (подробнее про работу с таблицами можно почитать тут и тут). Я заранее создал таблицу с названием MyTable и немного подкорректировал скрипт, который работает при операции вставки. И вот что я получил в итоге в папке table: $ lsMyTable.json mytable.insert.js readme.md Следуя логике наименования файлов в мобильных службах, можно прийти к логическому выводу, что в файле json хранится информация о правах доступа к таблице (и это так, этот файл аналогичен тому, что мы видели в API), а в js-файле хранится код. Причем название файла формируется из имени таблицы, к которой он относится, и операции, для которой он определен. Таким образом, если создать подобный файл непосредственно на вашем локальном компьютере (назвать его, например, mytable.update.js), написать в нем код и закоммитить на сервер, то эти изменения сразу же будут доступны в портале управления, без необходимости ручного создания обработчика операции update. Директория SHAREDЗдесь могут храниться скрипты, которые не относятся к какой-то конкретной части мобильных служб, а наоборот, могут быть использованы повсеместно. Что-то вроде хранилища библиотечного кода в рамках одной службы. Чтобы воспользоваться этим кодом, надо, во-первых, его написать (и сделать это можно только через Git, поскольку прямого доступа к этим скриптам из панели управления нет), а во-вторых, подключить новый модуль в существующем коде. 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). Это очень полезная вещь при разработке приложений, поскольку позволяет в считанные секунды подключить к своему проекту тонны сторонних библиотек, разработанных для различных целей (обработка ошибок, логирование, шаблонизация видов и т.п.). ЗаключениеПлатформа PaaS, которая есть в Microsoft Azure, предоставляет очень богатые возможности для тех разработчиков, которым нужно быстрое и качественное решение и которые не очень хотят тратить много усилий на развертывание и администрирование инфраструктуры. Microsoft Azure Mobile Services предоставляют богатый функционал широкого назначения. А Custom API, в частности, помогает избежать проблем дублирования кода, когда вам нужно разработать некие общие решения для различных платформ.
Теги:
Облачный бекенд.
Комментарии посетителей
Комментарии отключены. С вопросами по статьям обращайтесь в форум.
|
|
.png)
.png)
.png)
.png)
.png)
.png)
.png)
