所以，我询问了firebase supprt并得到了以下答案：
很高兴认识你。
- 我有点担心安全性：所以，我知道，firebase 使用读取、写入和验证来实现服务器端安全性。从示例中，我注意到验证基本上是一个单行 JS 脚本，它代表一个“如果”。当我计划构建一个网络电子商务应用程序时，我需要验证相当多的输入。是否有可能将验证外包到一个单独的文件中，以使其更具可读性？我还想知道，是否有可能测试这些服务器端验证，例如单元测试？
您可以使用我们的安全规则语言来实施极其复杂且有效的规则。您可以在托管部署过程中或通过 REST API 部署安全规则。在服务器上无法将内容拆分为多个文件，但您当然可以构建自己的流程，将多个文件合并为一个 JSON 结果。
- 目前我不能 100% 确定，firebase 是否可以覆盖我们所有的用例。将“普通”后端用于某些关键功能，然后将来自后端的数据持久保存在 firebase 中是否可能/一个好的解决方案？
一般来说，同步 Firebase 和 SQL 后端不是很实用，而且它们的翻译效果也不好。它也可能完全是多余的。
- 我看到了一些不错的用于 firebase 的聚合物元素。聚合物/Web 组件是否 100% 支持 firebase？
我不知道在这种情况下 100% 支持意味着什么。我们提供了一个 JavaScript SDK，因此它们应该可以很好地协同工作。
- 是否有其他方式（如 Java 方式）来实现服务器业务逻辑？
我们提供 Java、Objective-C/Swift、Android、Node.js、JavaScript 和 REST API 的官方 SDK，可用于其他语言。
- 有没有办法定义更新脚本，以便可以轻松地将新版本推送到生产环境？
我不确定这意味着什么。答案很可能是否定的，因为我们不提供构建过程或任何工具来发布您的软件。
希望对你有帮助！
我回复了：
感谢您提供的信息，它对我帮助很大！在阅读了您对第 5 题的回答后，我又想到了一个问题：
…
5. 有没有办法定义更新脚本，以便可以轻松地将新版本推送到生产环境？
我不确定这意味着什么。答案很可能是否定的，因为我们不提供构建过程或任何工具来发布您的软件。
是否有关于如何处理数据库架构的最佳实践？在我的情况下，我只有一个 Web 应用程序（没有应用程序等）......我希望数据库会随着时间和发布而发生巨大变化。我是否应该编写 JS 逻辑来检查当前数据库版本并在必要时对其进行更新？也许这会是一个不错的功能......
例如：我部署了 1.0 版的应用程序，一切正常。经过 3 个月的编程，我注意到用户数据需要进一步的属性：地址，这是一个“非空”属性。我现在部署我的应用程序的 2.0 版本，每个新注册用户都有一个地址，但旧用户（从 1.0 版本开始）没有这个字段或值。
我应该如何处理？
支持回复：
嗨，马克，
这里没有最佳实践，但您的想法似乎相当合理。您可能不需要签入您的 JavaScript。您可能可以在用户的个人资料中存储一个版本号，当他们升级到最新的软件时，您可以在他们的个人资料数据中进行升级。
那么您的验证规则可以使用如下内容：
{
"user": {
".write": "newData.hasChild('address') || newData.child('appVersion') < 4",
"address": {
".validate": "newData.isString() && newData.val().length < 1000"
}
}
}
因此，如果您担心版本控制，这可用于处理遗留版本。
我从开发人员那里看到的另一种流行方法是通过复制数据进行中间升级。因此，您发布了一个中间版本，该版本使用更新的数据结构写入旧路径和新路径（这使应用程序在旧用户升级之前一直为他们工作）。一旦升级了合理百分比的客户端，然后发布不再对旧结构和新结构进行双重写入的最终版本。
当然，扁平化数据虽然使连接和获取数据变得更加痛苦，但由于模块化数据结构更容易适应变化，因此升级将变得更加容易。而且，自然地，将各种记录包装在一个类中的实用设计（例如，带有 getter/setter 方法的 UserProfile 类）使转换变得更简单，因为您可以轻松地在一个地方进行版本控制。
希望这对某人有帮助:)