Closed JimmyLv closed 1 year ago
离组件最近，'真正做到要什么再取什么 loading加上，v-if之后就不用初始化data 多个query会不会同时发？ apollo server的用处，前端开发辅助 由前端来写schema，运用mock data 再也不用等后端实现API前端才能开发了 不必要的字段后端根本不用开发，也不用写Class的field
浪费在哪里：
Unex API->到BackEnd的转换->到BFF的转换->前端API到VuexStore的转换->Store到Vue data/computed（模板）的转换
Schema前端驱动开发：
1.先撸Vue模板HTML+CSS（纯静态） 1.1只拿到需求（原型图）就开撸<---识别动态data已经能产出Schema（Vue data都不用，直接从GraphQL里面来，因为Schema是前端定的） 1.2拿到设计稿就开撸CSS
2.再把模板变量撸出来，即对应Schema（假的动态数据） 2.1模板中的变量名和数据结构，直接就产出了Schema 2.2与此同时集成一下Vue apollo，并且编写对应的Apollo Server (mock data)
3.后端开发实现Schema resolver，无须集成（真的动态数据） 3.1前端提交Schema，git subtree同步至Schema codebase，作为契约本身 3.2后端拉取Schema，完成resolver开发，mapping好每个field的值
Driven 通常就意味着驱动力，当年你妈拿着竹条在你背后站着看你写作业的时候你有没有感受到驱动力呢？有驱动力的同时，你还会想着浪费时间吗？
与此同时，更重要的是可验证性，就像TDD，驱动意味着有某种方式来验证你做出的成果是否正确，是否符合你妈的预期，否则设立的规范也就白费。
而GraphQL的schema所带来的约束力，就是体现驱动的时刻，定义好的query和mutation就是前后端之前的契约，当输入的input type或者返回的data type不能满足于该类型的话，就直接会报错以给予反馈，且不需要前后端沟通之后才能知道。
从此，“后端你有个字段没实现！”“前端你不要给我甩个JSON好嘛？”再也不会出现了。
GraphQL 项目实践介绍
API 的未来：GraphQL 如何为敏捷组织铺平道路
JimmyLv
commented
5 years ago 
离组件最近，'真正做到要什么再取什么 loading加上，v-if之后就不用初始化data 多个query会不会同时发？ apollo server的用处，前端开发辅助 由前端来写schema，运用mock data 再也不用等后端实现API前端才能开发了 不必要的字段后端根本不用开发，也不用写Class的field
浪费在哪里：
Unex API->到BackEnd的转换->到BFF的转换->前端API到VuexStore的转换->Store到Vue data/computed（模板）的转换
Schema前端驱动开发：
1.先撸Vue模板HTML+CSS（纯静态） 1.1只拿到需求（原型图）就开撸<---识别动态data已经能产出Schema（Vue data都不用，直接从GraphQL里面来，因为Schema是前端定的） 1.2拿到设计稿就开撸CSS
2.再把模板变量撸出来，即对应Schema（假的动态数据） 2.1模板中的变量名和数据结构，直接就产出了Schema 2.2与此同时集成一下Vue apollo，并且编写对应的Apollo Server (mock data)
3.后端开发实现Schema resolver，无须集成（真的动态数据） 3.1前端提交Schema，git subtree同步至Schema codebase，作为契约本身 3.2后端拉取Schema，完成resolver开发，mapping好每个field的值
Driven 通常就意味着驱动力，当年你妈拿着竹条在你背后站着看你写作业的时候你有没有感受到驱动力呢？有驱动力的同时，你还会想着浪费时间吗？
与此同时，更重要的是可验证性，就像TDD，驱动意味着有某种方式来验证你做出的成果是否正确，是否符合你妈的预期，否则设立的规范也就白费。
而GraphQL的schema所带来的约束力，就是体现驱动的时刻，定义好的query和mutation就是前后端之前的契约，当输入的input type或者返回的data type不能满足于该类型的话，就直接会报错以给予反馈，且不需要前后端沟通之后才能知道。
从此，“后端你有个字段没实现！”“前端你不要给我甩个JSON好嘛？”再也不会出现了。