Android + Express + Mongodb

Question

乡亲

我在这里研究了一堆帖子，虽然一些回答证实了我的问题，但还是有一些空白，因此我的体系结构得到了完整的端到端验证。

我想要建立一个MVP，并希望得到一些投入，在最快的途径，以实现这一目标，并验证我的技术选择。我可以处理Javascript，express-node.js，mongo，对android编程有初级的经验，以及中等的java。

我想要一个android应用程序，它可以在使用android应用程序之前对用户进行身份验证，然后使用户能够管理客户和他们的元数据，管理一些与每个客户有关的文档，比如CRM应用程序中的文档，将文档发送回客户，并通过支付网关处理来自客户的付款，还可以通过SMS向客户发送一些通知，以执行"a“"b”"c“操作。

出于明显的原因，我考虑转向基于云的解决方案，而不是本地数据库。这是我正在考虑的技术栈。我需要确认这是合理的，我没有遗漏什么。

客户端编程

• Android Studio 3.0
• ButterKnife:生成代码的视图绑定库
• 将java接口改造为restful
• 安卓应用程序将与node.js提供的restful /web服务对话。

服务器

用于验证支付网关的Express框架+ node.js服务器passport.js : stripe

CDN

可能是amazon，用于保存一些文档、模板，然后在mongodb中保存对该数据的静态urls，并在我的express应用程序中使用节点-aws模块。

后端存储

noSQL: Moongose ORM + mongodb模块: pugm矩

在5-6个月后的某个时间点，我确实预计会有一个离线选项。我知道这对于mongodb来说是很棘手的，couchdb等可能是一个更好的选择，因为他们有一个lite选项。另一种选择是让我使用。或者在SQLlite和mongodb中使用异步同步(尽管我不喜欢将sql和nosql混为一谈)。

再一次，速度对我来说很重要。

请分享你对我所做的技术选择的想法，如果我在正确的轨道上，以及我需要担心的事情。再次，我得到MVP准备，很快想要一些客户尝试它，然后再去GA在6-9个月。

谢谢苏德

Answer 1

对于一个项目，没有“最好的”技术栈。即使我们对你和项目有足够的了解来提出建议(但我们没有)，我们中没有人有水晶球来预测未来，现在看来合适的技术可能是非常不合适的。

对于构建MVP，我能提供的最好建议是：选择技术栈，使您能够尽可能快速/廉价地验证您最危险的假设。实际上，您应该期望构建许多MVP，如MVP不是一个单一的产品，而是一个过程。。

有几个例子：

1. 对于大多数初创企业来说，最冒险的假设是用户首先想要他们的产品。验证这一点的最快/最便宜的方法通常是避免构建任何东西(这可能需要几个月的时间)，而只是与潜在的客户交谈(这可能需要几个小时)！在这种情况下，“技术堆栈”可能不过是在巴尔萨米克中创建的餐巾纸素描或一些模拟。如果用户似乎不感兴趣，你将不得不回到绘图板，但至少你只损失了几个小时，而不是几个月。另一方面，如果顾客开始垂涎当你给他们看你的草图，你可以继续下一个MVP。
2. 您所做的下一个MVP可能是您产品的硬编码、静态HTML原型。您的“技术堆栈”可能是使用html5up作为免费的HTML5模板，引导用于样式设计，GitHub页面用于托管。也许当你在这个阶段向顾客要钱时，他们会拒绝你。这是一个遗憾，但它只花了你几天的静态原型，而不是几个月的编码。另一方面，也许有几个用户会在这个阶段签一张支票，这是很好的验证！
3. 之后，下一个MVP可能是在HTML后面添加一个动态后端。在这种情况下，使用平台即服务(PaaS) (如赫鲁库 )或后端为服务(BaaS) (如Firebase )可能要好得多，这样您就不必花费时间部署/管理基础设施。使用他们提供的任何数据存储，不要担心扩展或花哨的特性。如果你足够幸运地得到一些牵引力，并且缩放正在成为一个问题，这是一个很大的问题！
4. 此时，您将更多地了解您的问题空间，并将能够决定关系数据库或NoSQL DB是否适合您的数据模型，节点是否是您团队最了解的技术，PaaS还是BaaS是否仍然适合您的需要，或者您是否需要迁移到基础设施即服务(IaaS)，如AWS等等。即使在这个阶段，您仍然需要为快速移动而进行优化，所以您通常会选择这样的技术：(a)您的团队最了解并且(b)有一个大型的社区，可以为您的问题空间构建开放源码库。

要更详细地了解这类权衡，请查看https://www.hello-startup.net/的“挑选技术堆栈”一章。

Answer 2

我不能在Android方面说话，但对后端来说，是的。

我对后端的理解--您需要以下特性：

1. 用户认证
2. 通过条带进行在线支付
3. 数据抵抗
4. 数据同步
5. 用户认证

您指定要使用护照，但尚未指定策略。如果要使用基本本地auth (用户名/密码)，则需要确保遵循最佳实践，如哈希密码。

1. 通过条带进行在线支付

条纹是容易工作和快速的开始。在做出承诺之前，确保它符合你的所有要求。

1. 数据抵抗

我强烈建议不要使用NoSQL数据库，如MongoDB。原因是NoSQL是用于非关系数据的。SQL数据库用于关系数据，您已经在上面描述了这些数据：

使用户能够管理客户

这将是一种1:N或一对多的关系；用户可以有许多客户。

将定义更多的关系，例如一对一或多对多的关系，这使SQL成为明确的选择。如果您正在寻找速度，那么将PostgreSQL作为一个自由选项，否则亚马逊Aurora将是最好的选择。

1. 数据同步

这是你需要花费大量时间的事情。您必须决定是要滚动自己的解决方案还是使用现有的解决方案(如领域平台 )。滚动你自己的解决方案本身就有它自己的复杂性。例如，如果用户A和用户B都可以访问相同的客户并同时编辑它们，该怎么办？移动应用程序将如何回应？还有很多其他的情况也可能发生。

此外，还包括：

• 我不会让您的Node.js/Express应用程序成为传统的monolith应用程序/REST。将每个功能都作为自己的“应用程序”或microservice.。
• 注意任何地方，州，国家等法规，如果你接受付款，你可能必须遵守。条纹有自己的跟随，你很可能有另一套你需要遵循。
• 考虑春天框架，特别是Spring Boot项目。