我目前正在研究一个新的google聚合物web应用程序，想知道我是否应该使用firebase作为后端/db。我看了一下这个项目，做了一些测试应用程序，真的很喜欢它!但是为了让我完全相信firebase是正确的选择，我需要回答以下问题:
-
我有点担心安全性:所以，我知道，firebase使用读、写和验证来实现服务器端安全性。从示例中，我注意到验证基本上是一行JS脚本，表示"if"。由于我计划构建一个web电子商务应用程序，我需要验证相当多的输入。是否有可能将验证外包到单独的文件中，以使其更具可读性?另外，我想知道，如果有可能，测试这些服务器端验证，例如单元测试?
-
我现在不能100%确定，firebase可以覆盖我们所有的用例。对于一些关键功能使用"正常"后端，然后将后端数据持久化到firebase中，这是否可能/是一个好的解决方案?
-
我看到了一些很好的聚合物元素的firebase。firebase是否100%支持聚合物/web组件?
-
是否有其他方法(如Java方法)来实现服务器业务逻辑?
-
是否有一种方法来定义更新脚本，以便新版本可以轻松地推送到生产中?
谢谢,亲切的问候
Marc所以，我询问了firebase支持并得到了以下答案:
很高兴认识你。
- 我有点担心安全性:所以，我知道，firebase使用读，写和验证来实现服务器端安全性。从示例中，我注意到验证基本上是一行JS脚本，表示"if"。由于我计划构建一个web电子商务应用程序，我需要验证相当多的输入。是否有可能将验证外包到单独的文件中，以使其更具可读性?另外，我想知道，如果有可能，测试这些服务器端验证，例如单元测试?
您可以使用我们的安全规则语言实现极其复杂和有效的规则。您可以将安全规则作为主机部署过程的一部分部署，也可以通过REST API部署。在服务器上将内容分解为多个文件是不可能的，但是您当然可以构建自己的进程，将多个文件合并为单个JSON结果。
一般来说，同步Firebase和SQL后端是不太实际的，它们不能很好地转换。这可能也是完全多余的。
我不知道100%支持在这种情况下是什么意思。我们提供了一个JavaScript SDK，所以他们应该一起玩得很好。
我们提供Java, Objective-C/Swift, Android, Node.js, JavaScript的官方sdk，以及用于其他语言的REST API。
我希望这对你有帮助!
我回应:
谢谢你提供的信息，这对我帮助很大!在阅读了你对第5个问题的回答后，我又想到了一个问题:…5. 是否有一种方法可以定义更新脚本，以便将新版本轻松地推向生产环境?我不确定这是什么意思。最有可能的答案是否定的，因为我们没有提供构建过程或任何工具来发布您的软件。
关于如何处理数据库模式是否有最佳实践?在我的情况下，我只有一个web应用程序(没有应用程序等)…我预计，随着时间的推移和版本的发布，数据库会发生巨大的变化。我应该写JS逻辑，检查当前的数据库版本和更新它，如果有必要吗?也许这将是一个很好的功能…例如:我部署了应用程序的1.0版本，一切正常。经过3个月的编程，我注意到用户数据需要一个进一步的属性:address，这是一个"非空"属性。我现在部署了我的应用程序的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方法)，使转换更简单，因为你可以很容易地在一个地方进行版本控制。希望对大家有所帮助