移动开发人员pt.1的无尽痛苦

最初发布在我的博客上

后端的缺乏可能是移动开发人员成功之路的强大障碍。

当移动外包开发商甚至移动外包公司没有自己的后端和开发能力，而仅与现有客户的后端合作或将其外包给其他地方时，我就遇到过这样的情况。

我是移动开发人员，我希望后端能够自己工作，不再伤害我。

静态API的移动后端不是火箭科学，是吗？应用之间共享功能的一部分是重要的，而不是唯一的。因此，为什么不查找和使用现有的解决方案并节省多达50％的时间和精力呢？

我们需要的99％是：

自从Parse失败成功失败的故事以来，已经有成千上万的mBaaS（firebase，endendless等）出现和死亡。这是不依赖它们的第一个原因，第二个原因是我不想付款。天知道，如果该应用起飞，该怎么办。因此，我也希望它是开源的，可以随时在我的服务器上进行部署，并让社区修复错误）））

这是我自己的特点，但我希望不要用JS编写。从类型安全的角度来看，Python也很糟糕，但至少我了解python。

这是mBaaS替代品的详尽列表。 随时与任何一个分享您的经验。

我还将分享我对其中一些的想法。

您可能会对Parse充满信心，因为您可能认为开源版本与服务本身上部署的版本相同。这是令人惊讶的（可能有一天会让您生气），因为文档相同，但解析服务器却不同。顺便说一下，这些家伙重新发明了原始的解析服务。

这是开源版本中缺少的内容的几乎正确的列表。分析，应用内购买验证，服务器端工作和功能是最令人失望的缺少功能。社区已经实现了仪表板，推送通知和电子邮件适配器。我没有尝试过实时实时查询，可能还缺少它们。

关于Parse SDK，您应该了解的另一件事是，它不能替换您应用程序的本地存储（核心数据/领域），尽管在阅读文档后看起来似乎如此。如果您尝试过，可能您可能会发现自己发明了一些使用解析本地数据存储和查询缓存的解决方法。而且您可能最终会因筋疲力尽而使coredata回到您的项目中。

不幸的是，我有一个利用开源Parse服务器的项目，也许有一天我会写一篇文章，名为“令人失望的关于Parse可伸缩性的方法文章”。

Baasbox似乎具有所有必要的功能。而且它用Java编写，这使我的灵魂保持温暖。他们的着陆页显示他们有很多应用程序，api调用等。但是不幸的是，他们的存储库像陵墓中的列宁一样是沉默的，而且我发现该项目已经死了。

这是一个非常有趣的项目，具有一系列积极地被贡献的功能。他们为金钱提供mBaaS，并为开源提供开源后端解决方案，插件和SDK。服务器本身用Go语言编写（不错！），服务器端脚本API用python语言编写（不错！）。

我一定会密切关注它，也许会尝试一天。

我也发现它很有趣，尽管它只是mongo db的Restful API。可能是完整的移动后端和手工后端之间的良好中间解决方案。

我敢肯定，有一天，这种服务器端快速框架之一将获得如此强大的生态系统，这将使其能够克服其他mBaaS解决方案。但是现在，我在等。

Feathers非常时髦，以至于我在帖子中都不会错过。它的功能集看起来很酷，但是上帝从JS中救了我，这就是为什么我永远不会关注它。

尽管Usergrid似乎有些沉重，但这是我完成研究的BaaS。

据称这是有史以来最不适合时髦的BaaS。它是由Apache开发的，自2011年以来一直是开源的，并且（突然！）用Java编写，并且可能结构良好。

我喜欢它的地方是它很旧（也许很稳定），并且由功能强大的Apache支持，拥有非常活跃的社区和新鲜的存储库。

它涵盖了完整的功能集，除了服务器端功能和应用程序内验证外，我可能将自己实现为微型微服务。

它还具有不错的社交网络功能，例如跟随和嵌套的组，它们可能会生成更新提要和事件。

Apigee使用它，并且像这样的扩展功能有更多详细和有趣的信息。

它利用Cassandra，Elasticsearch并部署在Tomcat下。

我已经将其部署在服务器上（！），并在一个宠物项目中提出了几个请求。我将从部署故事开始，介绍与usergrid一起进行的第一个冒险。

如果您对此感兴趣并想进行测试，但又不想浪费时间在部署上，请随时与我联系，我们将为您提供测试访问权限。