前端操作数据库的思考

一个前端操作后端持久化数据的接口 

相比如今基本被广泛接受和应用的后端新秀"微服务",这个理念已经有超过 20 年的沉淀,然后仍然没有被广泛应用和接受,目前只活跃在特定业务和特定技术人群.

一些产品示例:

• OLE DB for OLAP
• MDX （ Multi-Dimensional Express 多维表达式）
• Cognos
• 其他 OLAP
• 一些报表引擎
• APIJSON
• hasura

提前点出恰饭和屁股问题

• 前端用这个会加大工作量,提升心智负担,技术型偏向全栈。
• 后端 curd 仔被消灭掉
• curd 确实可以被大限度的替代,节省成本

软件工程角度

• 维护难度,会随着代码量和业务复杂度的增加,指数级上升
• 重构难度,不能重构,只能重写
• 性能,千万级表的 join,有没有索引都会出问题,依托于这种服务的数据库，出了性能问题就没法解决,加钱,加机器也不行
• 所有的数据聚合,业务处理,权限管理都依托于这个基础服务,可以暴露给前端,给以最大的灵活性,然而,事实是不存在一个通用的满足前端任何条件组合的高性能数据处理方式,把这些东西交给前端崽崽,真实太理想化了,同样一旦有超于框架的需求,没有任何方法解决,比如 APIJSON 不支持事务,没有锁.
• 我们暂且推翻上一条,确实有这么一个完美的数据操作服务，然后业务也不复杂特殊，数据量也不大.那么,一个前端崽崽,要掌握什么样的技能能够完成软件开发？调个 api 就能增删查改，就能加权限，就能聚合 /校验数据？ destroyEarth()就可以毁灭世界吗？最终，所有的后端内容都押到前端，然后，后端逐渐退出市场。这样做，除了减少前后端沟通，有其他优势吗？相比比于单人全栈，我没有想到任何优势。

最后

其实市场需要的不是 http 操作后端持久化数据，而是降低开发成本，解决前后端矛盾。http 操作后端持久化数据 现如今只不过是特定业务，特定场景的特殊需求，或者小打小闹，特定人群的自嗨，恰饭工具罢了。

写这个的原因，是因为有人杠在 业务不复杂，数据不够大，开发水平一般的开发场景，一个这样的服务完全可以支撑起来全部开发，一个初级前端就够了。简直又坏，又蠢。

以上,请大家只考虑技术可行性.