Что мы делаем? Сервис регистрации и авторизации пользователя для мобильного приложения
В пет-проектах каждого мобильного разработчика рано или поздно наступает момент, когда требуется быстро и без лишней головной боли создать сервер для своего приложения. Не важно, какую функцию должен выполнять сервер: будь то хранение данных или регистрация/авторизация пользователей.
Как правило, вначале все идут (ну или большинство) по пути наименьшего сопротивления. Мы ищем готовое решение и смотрим, как быстро его можно приспособить для наших нужд.
На данном этапе первое, что получается «нагуглить» — это сервисы Firebase, бесплатных лимитов которых более чем достаточно для организации бекенда небольшого мобильного приложения. Но в данном случае, рассматривая именно российского разработчика, мы рискуем наступить на грабли нашего законодательства — трансграничную передачу данных и хранение персональных данных пользователя.
(ФЗ 152 «О персональных данных», ст. 12, Глава 2)
Соблазн использования именно Firebase велик, но если мы хотим застраховаться от ненужной возни с различными надзорными ведомствами, то начинаем смотреть альтернативные варианты.
Следующий этап — это использование VDS-сервера с каким либо open-source или freemium решением, где за основу берется готовый «сервис-как-услуга» или решение, позволяющее развернуть похожий функционал.
Несколько лет назад на Хабре я уже писал подробное руководство по настройке BaasBox (статья была убрана из паблика по причине устаревшей информации) на арендованном сервере и приводил пример использования различных вызовов в iOS-приложении для языка Objective C. Но BaasBox реально «тяжеловес» и диктует свой минимум для арендуемого сервера. Немного поигравшись с ним, было решено использовать другое решение. Parse-server на тот момент только недавно был отдан в open-source разработку компанией Facebook, не имел столь большого количества адаптеров, как в настоящее время, но его возможностей было более чем достаточно для личных проектов и приложений частных заказчиков (многие проекты до сих пор существуют и стабильно работают).
Справедливости ради, стоит отметить, что parse-server очень сильно повзрослел и активно развивается. На текущий момент воссоздан практически весь функционал, что был доступен в коммерческом предке. Можно писать свои хуки, локализованные пуш-уведомления, менеджер процессов и есть даже подписка на изменение объектов, основанная на сокетах (ParseLiveQuery — если будет интересно, напишу отдельно статью по настройке ParseLiveQuery).
Но parse-server перестал быть интересен именно в тот момент, когда потребовалось реализовать нестандартный тип данных, с которым сложно работать на основе определенных в системе типов. Также мешает то, что не являясь профильным серверным разработчиком, ранее я не придавал значения более эффективному развертыванию окружения и многие файлы конфигураций делались руками, при этом действия постоянно повторялись на каждом новом сервере. Именно в этот момент и приходит понимание, что коробочное решение — это не решение всех проблем, и следует переходить к следующему этапу организации своего сервера для мобильного приложения.
В последнее время мой основной язык разработки — Swift. Поэтому именно он и интересен мне в первую очередь в написании серверного кода. Сам по себе язык Swift легко установить на unix-системе, но это не даст никаких явных преимуществ. По своей сути это будет напоминать разработку консольного приложения со сложной логикой. Придется много времени потратить на воссоздание базовых методов, необходимых в работе сервера.
Как и во многих других языках, server side swift имеет свои фреймворки и коммьюнити, участвующие в развитии этих решений.
На текущий момент можно выделить три наиболее значимых решения для разработки server side swift:
- Perfect
- Vapor
- Kitura
Существуют и другие варианты, но они не заслуживают упоминания по причине давно остановившегося развития и своей смерти.
В части документации и поддержки, мне более нравится Vapor, но это дело вкуса. Кому то будут близки другие решения. Так или иначе, во многих моментах они похожи.
Естественно, что далее на протяжении всего цикла статей в своих примерах я буду использовать Vapor. На его основе мы реализуем сервис регистрации/авторизации пользователя, отправку и подтверждение email, возможность сброса и изменения пароля.
Стоит ли делать реализацию без практической пользы?
Скорей всего, нет! Поэтому мы сделаем максимально взрослый сервис, который можно брать и использовать для организации логики хранения данных пользователя на своем сервере.
Если решение взрослое, то оно влечет применение обдуманных решений. Мы должны упростить масштабирование, реализовать валидацию данных и предусмотреть хранение сессии пользователя, чтобы не заставлять его каждый раз вводить свой логин и пароль.
Что нам для этого потребуется?
- VAPOR 4 (да, еще в бете, но релиз уже скоро, как обещали разработчики)
- PostgreSQL (имеется прекрасный адаптер для работы с этой БД)
- NGINX
- SSL (закроем все наши запросы из клиента к серверу с помощью сертификата)
- Localhost (рассмотрим способ разработки локально, чтобы не привязываться к сети и без проблем поработать в дороге)
Ну и упакуем все это в Docker, чтобы обеспечить одинаковую работу, независимую от текущего окружения среды выполнения.
Честно говоря, я в свое время скептически относился к докеру, но следовало более внимательно рассмотреть эту технологию. Цель статьи не в объяснении его работы и обучению работы с ним (подозреваю, что мне самому предстоит еще узнать много интересных возможностей докера). Но те, кто не знает, что это такое, и как с ним работать, могут самостоятельно начать знакомство с Docker по официальной ссылке: www.docker.com
Забегая вперед, оставлю еще полезную ссылку на приложение Kitematic, которое призвано упростить работу с контейнерами докера: kitematic.com (must have для тех, кто не любит пользоваться терминалом).
Итак, начнем с установки Docker на mac-компьютер:
Переходим по ссылке hub.docker.com/editions/community/docker-ce-desktop-mac и скачиваем Get Docker Desktop For Mac (Stable)
Открываем полученный образ и далее, установка ничем не отличается от стандартного копирования приложения в каталог программ.
После достаточно запустить приложение и дождаться полной инициализации сервиса.
Если еще нет Docker ID, то его следует создать на hub.docker.com А если есть, то просто авторизоваться в приложении.
Вот и все, подготовка к использованию Docker завершена. Осталось лишь проверить текущую версию и информацию об окружении.
> docker version
> docker info
На этом подготовка к разработке сервиса авторизации завершена. В следующей части мы посмотрим, как можно использовать контейнеры различных сервисов, разберемся с docker-compose для автоматизации сборки нашего окружения и начнем писать код.
P.S.: Небольшой совет из личного опыта. Когда мы разрабатываем сервисы на своей локальной машине, Docker выделяем для своего использования ресурсы по умолчанию. Если мы хотим визуализировать ожидаемое поведение сервиса на удаленном сервере, стоит позаботиться о ресурсах на локальной машине, максимально приближенным к характеристикам сервера. Сделать это можно в настройках приложения Docker Desktop, что мы скачали:
Автор статьи:
Виталий Подольский, преподаватель HackerU
