要完善的地方

[wangjie-fourth]

1、项目构建

• 将项目的默认发送请求方式改成url
• 一个简单的集成测试
• 配个简单的ci

2、完善的功能

• antlr4生成代码应该在项目构建的时候生成
• 后面的函数功能如何完善？
• 前端项目的输入框如何做语法提示？

[wangjie-fourth]

*全返回与之前的依赖校验冲突；得把依赖校验冲突移动到每次数据返回的时候

[kevinten10]

@wangjie-fourth 我们是否可以默认使用json格式作为 capa-bff 的查询dsl呢。

如果要使用生产级的BFF，那么人们会选择graphql而不是 capa-bff，因为capa-bff更像是一个demo。
会使用 capa-bff 的人，一定是不想维护庞大的graphql体系，仅仅希望使用基础的bff功能。

所以大概率他们在查询语言上会采用最简单易用的方案，可能json是比较合适的。
如果默认使用antlr4，可能会提高他们的接入成本。

所以我想，咱们可以默认使用json，也可以通过设置快速的开启antlr4。

[wangjie-fourth]

@kevinten10 可以使用json格式，但我觉得似乎没有必要。

1、如果使用json格式，且不用antlr4来解析dsl的话

• 解析dsl会增加很多工作量，还需要额外为解析代码去写UT
• 后期要对dsl格式进行扩展的话，就需要对解析代码和UT进行改造，增加维护成本

2、如果使用json格式，还用antlr4来解析dsl的话

• 根据原来的格式定义，部分字段的key必须是request、response；这会增加antlr4解析难度，因为无法通过词法分析确定某个key是否必须是request、response，还需要再次通过分析上下文来确定当前key是否必须为request、response关键字
• 如果后期打算做前端输入框的语法提示、自动补全、语法高亮的话，实现起来会麻烦一点，理由跟上面一致

3、至于接入成本，的确是需要使用者再次熟悉capa-bff的格式。我认为这个后期可以通过对输入框做语法提示来弥补一下

4、如果想把这个项目做成生产级别的话，我觉得可以向当初出题目的人请教一下。只要项目功能完善、测试覆盖率高、文档齐全，我认为是可以生产上尝试的