That is in no way different than REST: 1. (same) 2. Based on the screen designs and workflows, front end dev team writes the REST contract that they want. They

That is in no way different than REST: 1. (same) 2. Based on the screen designs and workflows, front end dev team writes the REST contract that they want. They mock the endpoints (i.e. using nock [0] or Angular's MockBackend) for the contracts and come up with the DTO definitions. 3. Backend folks start implementing the REST endpoints by orchestrating microservices (or by creating a REST service facade for an existing REST API). 4. Once the backend REST endpoints are done, switch out the mock endpoints for the real ones There is no need or benefit for using GraphQL here, all this can be done with REST already. Tooling around REST is great, i.e. you could use TypeScript to generate .d.ts files for your REST Dtos based on the swagger API schema [1]. Or with plain JS, use a JS runtime library that validates the DTO schematics/REST contracts (both your mocked ones and the real ones returned by the backend) with i.e. joi [2]. [0]: https://github.com/nock/nock https://github.com/nock/nock [1]: https://github.com/swagger-api/swagger-codegen https://github.com/swagger-api/swagger-codegen [2]: https://github.com/hapijs/joi https://github.com/hapijs/joi