* 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.
Add documentation for new service: check flags:
* validationPeriod
* queryCountThreshold
* queryCountThresholdPercentage
* Remove broken link
* Run prettier
* (op-reg) Clarify that the operation registry is for Enterprise and Team plans.
* (op-reg) Drop the word "grab" and go for something more friendly.
* (op-reg) Add a "What to expect" heads-up on what the installation necessitates.
* op-reg: "should" > "can".
* op-reg: Refer to "Engine" as "Apollo Engine".
* op-reg: Complete sentences with correct words are great.
* Update docs/source/platform/operation-registry.md
* (op-reg) Update for `forbidUnregisteredOperations` predicate function support.
The Apollo Server operation registry plugin — available for Apollo Engine
Team and Enterprise users, now supports passing a predicate function rather
than a boolean on the `forbidUnregisteredOperations` parameter.
This new parameter can be used to selectively enforce the safe-listing
depending on contextual differences — for example, the presence of a header.
This documentation adds the implementation details for that new feature
along with an example of how to utilize it.
* Clarify predicate function with a link.
A predicate function is a function which returns `true` or `false`, which is explained within the same sentence, but a link would be helpful to those who might not understand that terminology. It's worth understanding the term, and a link helps make that easier.
* Address feedback from @peggyrayzis.
