Meteorjs现在适用场景如何开发项目之后维护成本是否很大

2019-11-10 20:52:21

在当前graphql发展得不错的情况下，meteor已经没那么吸引人了。用过meteor也用过apollo-graphql,meteor的问题就是比较依赖mongodb，也比较依赖collection的定义。因为前端需求和后端业务需求常常不同，后端mongodb和前端mini-mongo用同一套collection的定义有些别扭，需求一复杂了，也没有省去多少数据转换的麻烦。所以金狮贵宾会登录网址选择apollo,自己定义dataSource，想用啥数据库用啥数据库，数据来源是很多个数据库写起来也不别扭，业务后端变得极为灵活了，和前端的结合也更加紧密了。业务后端甚至兼了一个代理层的用场。apollo-link-state还兼了reduxmobx这类本地状态管理的活儿。正面回答问题，适用场景：愿意选择mongodb作为业务数据库的项目、业务清晰不拧巴的项目、交互性强的项目（websocket的优势得以发挥）。维护成本是否很大：金狮贵宾会登录网址觉得招人应该不容易，meteor是个框架，有它自己的游戏规则，新人上手需要时间去适应（apollo虽然也是框架，但是它是遵从于graphql这个大的标准的）；其他的，说白了这就是个nodejs项目，性能问题什么的能解决的如何看的就是个人水平了。没记错的话，多表查询还是吃内存的（毕竟是基于mongodb）。你要是想得开也可以再弄个缓存数据库专门服务于跨collection查询吧。

相关产品

相关资讯