Уроки, извлеченные при запуске стартапа на Firebase, часть II
В Praise мы создаем социальную сеть для качественной журналистики поверх Firebase Web. Это наш дневник разработки. После разговора о тестируемости, поддержке, хостинге Firebase и экспресс-облачных функциях в качестве серверного промежуточного программного обеспечения в предыдущем посте, сегодня мы углубляемся в глубины Firebase для Интернета с управлением сеансами и его подводными камнями.
Охваченные темы: Управление данными сеанса пользователя с помощью настраиваемых утверждений. Еще одна важная часть нашего стремления заменить как можно больше элементов традиционного стека приложений предложениями Firebase и Google.
Пользовательские сеансы с настраиваемыми утверждениями
В области Firebase существует множество методов имитации пользовательских сессий на основе файлов cookie. Один особенно элегантный способ создания настраиваемых пользовательских данных: настраиваемые утверждения, объекты данных, прикрепленные к встроенному управлению аутентификацией Firebase. У этих требований есть несколько преимуществ:
- данные распределяются между клиентом и сервером,
- нет необходимости выполнять асинхронный поиск в вашей базе данных в реальном времени или Firestore
- утверждения могут использоваться в правилах безопасности Firebase
- нет шаблонного кода управления сеансом
Приведем пример. Логичным выбором было бы предъявить претензию при создании пользователя. Поскольку Praise на данный момент построен на аутентификации Twitter, мы подключаем ограниченное пространство имен пользователей Twitter и делаем его нашим собственным. Эти «дескрипторы» Twitter удобочитаемы, составляют части наших URL-адресов и знакомы нашей целевой группе. Это простейшая форма кода, необходимая для установки пользовательского утверждения внутри функции Firebase, которая запускает onAuthCreate.
Это утверждение будет доступно для каждого объекта аутентификации пользователя везде в вашем приложении. НО… есть некоторые подводные камни.
Настраиваемые утверждения не становятся волшебным образом доступны на клиенте после того, как вы установили их в функции. Если вам нужно иметь возможность работать с заявкой сразу после создания пользователя - во время адаптации, как в нашем случае - вы должны вернуться к базе данных, чтобы сообщить об изменении. Просто просмотрите путь, соответствующий внутреннему идентификатору пользователя Firebase (который вы знаете в любой момент времени) на клиенте, и обновите его после того, как запрос будет установлен для функции. Продолжая наш фрагмент выше, это будет выглядеть так:
Кроме того, пользовательские утверждения не экспортируются из внутренней системы аутентификации Firebase. Это означает, что вам придется установить их программно, если вы переносите пользователей между базами данных или учетными записями Firebase. Проще говоря, эта firebase-cli команда не выдаст никаких пользовательских заявлений:
firebase auth:export users.json --format=json
Итак, резюмируем: мы устанавливаем пользовательское утверждение внутри облачной функции и информируем об этом клиента, обновляя базу данных. Клиент отслеживает изменения в этом объекте базы данных и, наконец, перезагружает idToken, содержащий все пользовательские данные и настраиваемые утверждения:
Еще не все
В части III нашего дневника разработки мы будем говорить о рутинных задачах с Firebase вместо задач CRON. Следите за обновлениями и подписывайтесь на нас, чтобы получать последние сообщения прямо на свой почтовый ящик.
