Итак, я спросил firebase и получил Поддержка, следующий ответ:
Великий встретиться с вами.
- Я немного обеспокоен безопасностью: Итак, я знаю, что firebase использует чтение, запись и проверку для реализации защиты на стороне сервера. Из образцов я заметил, что валидация в основном представляет собой однострочный JS-скрипт, который представляет собой «if». Поскольку я планирую создать веб-приложение для электронной коммерции, мне нужно проверить достоверность некоторых материалов. Есть ли возможность для аутсорсинга проверки в отдельном файле, чтобы сделать ее более читаемой? Также я задавался вопросом, есть ли возможность проверить эти проверки на стороне сервера, например, модульные тесты?
Вы можете реализовать чрезвычайно сложные и эффективные правила, используя наш язык правил безопасности. Вы можете развернуть правила безопасности как часть процесса развертывания вашего хостинга или через REST API. Невозможно разбить содержимое на несколько файлов на сервере, но вы можете создать собственный процесс для объединения нескольких файлов в один результат JSON.
- Я не уверен на 100% в настоящий момент, что firebase может охватывать все наши прецеденты. Было бы возможно/хорошее решение использовать «нормальный» бэкэнд для некоторых критических функций, а затем сохранить данные из бэкэнда в firebase?
Вообще говоря, синхронизация Firebase и задней части SQL не очень практична, и они не переводят хорошо. Вероятно, это тоже избыточно.
- Я видел несколько хороших полимерных элементов для огневой базы. Поддерживается ли firebase 100% в полимерных/веб-компонентах?
Я не знаю, какие 100% поддерживаемые средства в этом контексте. Мы предлагаем SDK для JavaScript, чтобы они играли хорошо вместе.
- Есть ли другой способ (например, подход Java) для реализации бизнес-логики сервера?
Мы предлагаем официальные SDK на Java, Objective-C/Swift, Android, Node.js, JavaScript и REST API для использования на других языках.
- Есть ли способ определить сценарии обновления, чтобы новые выпуски легко могли быть перенесены в производство?
Я не уверен, что это значит. Скорее всего, ответ отрицательный, поскольку мы не предоставляем процесс сборки или какие-либо инструменты для выпуска вашего программного обеспечения.
Я надеюсь, что это поможет!
Я ответил:
Спасибо за информацию, она помогла мне очень много! После прочтения вашего ответа на вопрос № 5 в голову встал еще один вопрос: ... 5. Есть ли способ определить сценарии обновления, чтобы новые выпуски можно было легко перевести на производство? Я не уверен, что это значит. Скорее всего, ответ отрицательный, поскольку мы не предоставляем процесс сборки или какие-либо инструменты для выпуска вашего программного обеспечения.
Как лучше всего использовать схему базы данных? У меня есть только одно веб-приложение (без приложений и т. Д.) В моем случае ... Я ожидаю, что база данных сильно изменится с течением времени и выпусков. Должен ли я писать логику JS, которая проверяет текущую версию базы данных и обновляет ее, если это необходимо? Возможно, это создаст приятную особенность ...
Например: Я развернул версию 1.0 своего приложения и все работает нормально. После 3 месяцев программирования я замечаю, что для пользовательских данных нужен еще один атрибут: address, который является атрибутом «не null». Теперь я развертываю версию 2.0 своего приложения, и каждый новый зарегистрированный пользователь имеет адрес, но старые пользователи (из версии 1.0) не имеют этого поля или значения.
Как я должен справиться с этим?
Поддержка ответил:
Привет Марк,
Там не лучшая практика здесь, но ваши идеи кажутся довольно звук. Вероятно, вам не нужно проверять свой JavaScript. Вероятно, вы можете сохранить номер версии в профилях пользователя, а при обновлении до новейшего программного обеспечения вы можете обновить его в своих данных профиля.
Тогда ваши правила проверки могли бы использовать что-то вроде следующего:
{
"user": {
".write": "newData.hasChild('address') || newData.child('appVersion') < 4",
"address": {
".validate": "newData.isString() && newData.val().length < 1000"
}
}
}
Так что, если вы обеспокоены версий, это может быть использовано для борьбы с существующими выпусками.
Другой популярный подход, который я видел от разработчиков, - это делать промежуточные обновления путем дублирования данных. Таким образом, вы выпускаете промежуточную версию, которая записывает на старый путь и на новый путь с обновленной структурой данных (что заставляет приложение работать для старых пользователей до их обновления). После того, как разумный процент клиентов будет обновлен, выпустите окончательную версию, которая больше не будет дублировать запись старой структуры и новой структуры.
Конечно, сглаживание данных, в то время как это приводит к сбою и извлечению данных из-за боли, упростит модернизацию, поскольку модульная структура данных легче адаптируется к изменениям. И, естественно, прагматичный дизайн, в котором вы переносите различные записи в классе (например, класс UserProfile с методами getter/setter), упрощает переход, поскольку вы можете легко взломать управление версиями в одном месте.
Надеюсь, что это поможет кому-то :)