使用Firebase及其他功能快速迭代到有价值的产品
Maurits Verbiest在Foter.com/CC BY上拍摄的照片 我们生活在令人兴奋的时代。 从设计到开发过程的所有时间,服务不断涌现,比以往任何时候都更快,更便宜地将数字创意转化为现实。 Firebase(以及最近的Firestore)就是其中一种已经存在很长时间的工具,它为您提供了一个完整的后端,即您实际存储和处理用户数据的地方,因此您可以突然减少所需的工作量自己建立和维护此基础架构(更不用说组建一支可以做到这一点的团队了。) 但是,便利总是要付出代价的。 当拥有由外部服务运营的公司的关键基础架构时,您需要了解风险和权衡因素,并在进入之前做好准备。对于Firebase,我建议您为以下情况做准备: 1)对于您的用例而言,其功能集太有限,可能仅在产品的后续迭代中显示 2)您到达了临界点,在该临界点上,您自己的基础架构的运营变得更具成本效益,或者产品达到了不同的成熟阶段,需要以其他方式进行部署(例如,本地企业托管) 3)Google认为从业务角度来说这套产品对他们而言不再有意义,并停止使用它们(就像Facebook在Parse所做的那样)。 这归结为自软件开始以来的事实:一切都会以不可预见的方式发生变化,并且软件工程师的工作是了解其软件将运行的环境,以便他们为更改做准备。 与大多数专业人士一样,程序员必须不断进行基本的权衡:速度还是质量? 特别是对于软件,有两个主要的危险:没有足够的远见,以及为太多永远不会发生的场景做准备。 幸运的是,由于Web开发相对简单,因此有一些基本的体系结构准则,无需过多的工作即可显着降低风险。 本文的技术性部分将基于一个基本规则:良好的体系结构可将重要的决定推迟到最后的负责任时刻。 在此过程中,我们将意外发现此规则的某些后果,这些后果使我们能够: 只需很少的工作即可生成质量更高的代码…