前后分离后 关于接口的思考

前言

咳,玩笑归玩笑,就我目前工地代码的水平而言,我负责架构时,前后开会商量数据怎么处理,多搞点review,优化流程和接口

生成文档的轮子

每次确定好模式,设计完接口,还要写注释就已经痛苦不堪了,想着还要写文档,是很绝望的,
所以,为团队弄一个从代码和注释中自动生成文档,保证代码、注释的范式的同时,也可以给到其他人(尤其是前端)调试调用

现在我们会从这个轮子中统计常用的接口,和项目管理系统关联,用80%的精力坐好最重要的20%的事情

参数范式

在README里,需要说明常用的参数意义,不允许使用太过抽象的参数命名,
比如 i, j, k, it, data, handle 等,指定命名的范式,如驼峰,下划线,特殊字符含义等

数据的颗粒性

我曾经为了获取一个用户的信息,调用了不下5个接口,前后的代码都混乱不堪,
甚至为了拿到用户的下属数量,前端手动遍历了整个深层数组,就为了一个length属性…
性能,流量等都极度不友好,生成、结构长json两边的cpu就已经明显不行了,这里就不对缓存做过多赘述了
所以,一个接口的单一性和数据的颗粒性,这其中的平衡十分微妙,放到具体的业务场景,就是一门艺术了

唠唠

制定范式,遵守是十分消耗时间成本的,节省下来的管理成本还不易被察觉,至于怎么平衡,这就是另一门艺术了,共勉.