По мере решения задач, описанных в предыдущих статьях, у нас накопилось небольшое количество кода. Таким образом, родилась тема для нового текста. Эту статью мы начнем с рефакторинга кода приложения для приведения его в соответствие HMVC архитектуре. Код не будет идеальным. По большому счету, он останется прежним. Изменится лишь подход к реализации. Код приложения размещен на GitHub. Материалы, посвященные этой статье, вынесены в отдельную ветку refactoring.
Приступим. Файл с маршрутизацией приложения стал достаточно велик. Да и количество шаблонов в папке templates заметно увеличилось. Первое, что мы сделаем — это разделение накопившегося добра на директории модулей приложения.
Для размещения шаблонов мы создадим саб-директорию templates. При этом не забудем поменять пути к ним в созданных файлах маршрутизации. Аналогично поступаем со всеми модулями приложения. Не забываем подключить новые файлы маршрутов в index.html.
Общая директория templates предназначается для хранения общих шаблонов. Кроме того, остается глобальный файл маршрутизации router.js с описанием состояния по умолчанию.
С помощью перечисленных (довольно простых) манипуляций учебное приложение стало чуть ближе к практике построения HMVC архитектуры.
Безопасность в Parse приложениях
Следующий объект нашего внимания — это безопасность Parse приложений. Для начала напомним, как используется API от Parse.com
У нас, как владельцев приложения, есть App ID и набор ключей, которые можно разделить на два типа:
- Клиентские ключи для различных SDK;
- MasterKey.
Ключ MasterKey игнорирует любые настройки приватности, поэтому он ни в коем случае не должен попасть в приложение. Parse позволяет настроить доступ к данным, добавив ограничение на класс или на каждую строку класса. Благодаря этому, мы можем определить, кто получит доступ к данным для всего класса, либо для его отдельной записи (экземпляра).
Доступ к классу/объекту можно определить для:
- Пользователя или группы пользователей;
- Роли или группы ролей.
Казалось бы, это именно то, что нам нужно. Данные в нашем приложении относятся к пользователю, соответственно получать их должен только он. Такой подход оправдан, мы считаемым его приемлемым по большинству параметров. Единственный существенный недостаток этой парадигмы касается предоставления доступа к одному объекту сразу нескольким пользователям.
Поясним на примере: допустим у нас есть User#1 и User#2,
Чтобы дать User#2 доступ к заметке User#1, мы можем создать роль FriendOf_1 и назначить ее User#2, а также разрешить доступ этой роли ко всем объектам User#1. Согласитесь, если пользователей много, это не очень удобно.
Гораздо более простым и эффективным выглядит другой подход:
- Запрещаем доступ ко всем классам
- Переносим логику выборки данных в Cloud Code и выполняем все запросы там с использованием MasterKey.
Таким образом, мы добиваемся максимального уровня безопасности, а также получаем возможность менять логику приложения, не выпуская новых релизов.
И еще. Кроме всего, с чем мы ознакомились по ходу выполнения учебных заданий, Parse позволяет создавать полноценный серверный код приложения. Принцип работы прост, как лопата. К недостаткам можно смело относить лишь неудобства в отладке такого кода. Для его хранения следует завести отдельный репозиторий. Таковы правила хорошего тона. В учебном примере мы проигнорируем эту рекомендацию и разместим весь материал в одном репозитории. Не забывайте — наш девиз: увеличение скорости за счет снижения качества:)
Cloud Code
А теперь начнем работу с Cloud Code. Шаг первый: установка консольного инструмента Parse:
Создаем новое приложение:
При деплое на сервер зальется текущий локальный код. Обозначаем спектр хороших привычек:
- Предупредить свою команду, что хотите поработать с Cloud Code.
- Оставить описание, что это debuging, например parse deploy —description=”debuging”.
- При деплое готового варианта кода оставить комментарий из последнего коммита
Перейдем к коду. Создадим файлы для функций, соответсвующие модулям приложения и подключим их в файле main.js
Определим, что мы всегда должны использовать MasterKey. Так как доступ к этому коду есть только у нас, это решение вполне безопасно. Использование MasterKey не обязательно должно носить глобальный характер. Допускается локальное применение кода внутри любой из функций или даже для каждого запроса к базе данных. Наличие выбора — это всегда хорошо.
Пример преобразования кода для модуля привычек с учетом использования Cloud Code:
Для выполнения кода на стороне сервера мы определили функцию, включающую в себя необходимую нам логику:
Она содержит два основных параметра — request и response. Использование функции обязательно должно прийти к какому-либо конечному результату:
- успешному — response.success(habitFailure);
- или не очень — response.error(‘Not authorized’);
Функция выполняется в течение 15 секунд. Что еще нужно отметить? Функция может вернуть только один объект, поэтому:
Входные данные хранятся в request.params, но мы не можем передать сюда объект со стороны приложения (только файл). В этой связи, следует получить идентификатор, найти объект и произвести с ним необходимые манипуляции. Ничего сложного. Если же объект нам нужен только для построения связи, мы можем запросто его забилдить:
На стороне клиентского приложения мы должны вызвать такую функцию:
Продемонстрируем, как проявят себя изменения кода контроллера на стороне клиентского приложения:
Перед вами лишь фрагмент кода. С полной версией вы можете ознакомиться на GitHub.
Вызываем удаленную функцию и обновляем интерфейс при ее завершении.
Ну и, как водится, подводим итоги. Cloud Code — отличный инструмент для организации серверной логики. Однако этим его возможности не ограничиваются. Например, вы можете использовать Cloud Code для отправки писем или sms с помошью SendGrid или Twillio. Он способен изменять размер изображения на стороне сервера, отправлять push-уведомления и справляться с массой полезных мелочей.
В следующей статье этого цикла мы рассмотрим моменты, посвященные развертыванию веб-версии нашего приложения.
Не переключайтесь.
