* apollo-config: run prettier and add service to client docs
* schema-validation: update screenshots
* schema-validation: update command output
* schema-validation: use npx and add npm install apollo
* validation: add section for compatible changes
* validation: add reasoning for each bucket of failure
* validation: update breaking change language
* validation: address feedback from @zionts
This commit:
* updates the introduction to include necessary background information
* start with an operation list then move to comparison
* places the setup basic instructions higher up in the flow
* uses npx instead of a global apollo
* adds schema tags to the instructions with an image
* defines more of the current cli's behavior
* shifts describing specific schema changes to general strategies around
proper evolution of a schema
* adds learnings from dogfooding
* ignoring exit code
* simplifies the CircleCI setup
* add rollover recomendation
* Label alternative strategies for maintaining an api and make
non-breaking changes section less opinonated
* ease example into example of field change
* simplify description of behavior between Notice and Error
Wording changes include:
* passive -> active voice
* remove second person
* cutdown extra information
* pull-request => pull request
* cli => CLI
* published => pushed
* Remove the 2nd person language
* remove unused cicleCI comment
* add GraphQL service to glossary
* publish -> register
* add reference to schema tag
We now point users at publishing their schema on every deploy and add a
note that it can be advantageous to publish from master.
By default, Apollo Server and Apollo Client take care of most aspects of client awareness automatically, with the requirements being:
* Using recent versions of Apollo Server and Apollo Client which support client awareness automatically.
* The `name` and `version` be set on the `ApolloClient` constructor.
As currently written, the variables used in this _Advanced setup_ section have caused some to believe that those are the headers that should be used, whereas they were merely suggestions. The _Setup_ section above should still be observed for most cases and I hope the additional clarity in this re-wording will help avoid future confusion.
An "application programming interface" need not be capitalized in its full form, but I believe API should remain capitalized.
With all due respect to SCUBA, I'm not willing to let every form initialism land in the dictionary in lower-case.
