Parse的几大坑

1. Server端文档不详尽, 而且极度暧昧, 有好几种不同的管理方式, 但是, 都说的语焉不详. 比如, 使用express配合启动ParseServer的话, 它不会告诉你, 这个跟命令行的启动方式, 有什么细节上的区别. 在参考资料有限的情况下, 很容易造成错误的依据.

2. 例子逻辑不够清晰, 比如官方的标准参考, 是采用mongo-runner来启动mongodb, 然后无痕的就跟Parse连接上. 如果这个mongo-runner好用也就罢了, 问题是mongo-runner每次启动, 之前存储的数据就没了. 还好, 自己启动的mongodb也可以简单的用在parse中, 还不至于太麻烦. 但是, 毕竟官方的参考是使用mongo-runner来启动mongodb的, 如果普通用户按照官方的例子来实施, 真上线的话, 数据全部丢失, 那可真的要命了.

3. cloud函数相当不靠谱, Parse有一套功能不差的js扩充入口, 就是cloud函数, 可以实现Parse自身之外的一些功能补充, 但是, 这个cloud函数并不是标准意义上Node.js, 于是, 有一些细微的差别会存在于这个js文件和标准nodejs文件之间, 这对普通开发者来说, 就是一个门槛. 按照个人 的看法, cloud函数完全可以放弃, 而只要增强nodejs的api, 然后使用额外的nodejs来扩充api即可, 多一套cloud函数的逻辑, 其实也是一个麻烦的来源.

4. 客户端数据存储过度复杂, Parse的对象在本地存储的时候, 每次都会轮询一次本地所有的存储对象, 在小数据库中还好, 但是, 一旦数据稍微多一点, 任何一个数据写入工作, 都得全数据库查找一次, 简直就是恐怖.

5. 继承自Mongodb, 却扔掉了Mongodb的一些基本的查询机制, mongo的group函数, 可以实现一些比较靠谱的数据整理工作, 但在parse中, 却被丢失了. 比如, 用户的记录, 被记录在某个表中, 那么, 要增加一个用户记录综合排名的逻辑, 用parse就完全没有办法, 除非先将所有用户记录的对象全读到内存, 然后进行手动代码组合, 用mongodb一句话就能解决的问题, 用parse却几乎没有办法. 还有, 按照条件修改或者删除对象, 这应该是最基本的逻辑设计, parse中却没有, 唯一的做法, 就是全局搜索所有对象, 得到对象实体, 读出到内存中, 再统一修改或者删除, 这样的做法, 在超大数据库中, 简直就是要命的做法. 为了一些非常简单的操作, 平白无故的要写一大堆代码, 让人很难理解.

6. Scheme机制, 这个是我最想批评的, mongodb的牛逼之处是什么, 不就是scheme-less嘛, 它倒好, 又给mongodb加上了scheme, 这样的做法, 虽然可以让数据规范化, 却也带来一个致命的点, 那就是遇上一些不规则数据, 就没法组合了, 而这, 本来就是mongodb的一大优势.

7. 客户端API陈旧, 很多API设计, 缺乏可靠性验证, 而且, 因为过于陈旧, 存在很多不可控的问题. 比如ParseFile, 在Android上, 解码会有错误的情况发生, 要解决这种问题, 必须替换PaseFile自己关联的图片解码过程. 还有API中对Object对象统一管理的机制, 也是非常的反人类的, 任何一个对象都是唯一的, 而不是即时的, 在函数式开发逐渐热门的现代, 使用这种传统陈旧的设计模式, 带来的结果是逻辑设计会变得非常复杂而且不统一.

发表评论

电子邮件地址不会被公开。 必填项已用*标注