Clean up links and unecessary component in the homepage

This commit is contained in:
Trevor Blades
2019-05-24 20:47:24 -07:00
parent 83f6bb8577
commit 0d3fbb8fd3
8 changed files with 477 additions and 1151 deletions

1581
docs/package-lock.json generated

File diff suppressed because it is too large Load Diff

View File

@@ -6,6 +6,6 @@
},
"dependencies": {
"gatsby": "^2.4.2",
"gatsby-theme-apollo-docs": "^1.0.0-alpha.56"
"gatsby-theme-apollo-docs": "^1.0.0-alpha.58"
}
}

View File

@@ -10,8 +10,7 @@ The Apollo GraphQL platform is an implementation of GraphQL that helps you manag
import {
ButtonWrapper,
Button,
HollowButton,
ExpansionPanel
HollowButton
} from 'gatsby-theme-apollo-docs';
<ButtonWrapper>
@@ -19,6 +18,4 @@ import {
<HollowButton to="/intro/platform">Learn more</HollowButton>
</ButtonWrapper>
<ExpansionPanel />
![Graph layer](./img/platform.jpg)

View File

@@ -18,7 +18,7 @@ The [VS Code extension](https://marketplace.visualstudio.com/items?itemName=apol
- Validate field and argument usage in operations
- [Navigate projects more easily](#navigating-projects) with jump-to and peek-at definitions
- Manage [client-only](#client-only-schemas) schemas
- [Switch schema tags](#schema-tag-switching) to work with schemas running on different environments
- [Switch schema tags](#schema-variant-switching) to work with schemas running on different environments
## Getting started
@@ -74,7 +74,7 @@ module.exports = {
};
```
Linking to the local schema won't provide all features such as switching schema tags and performance metrics. See [the Apollo config docs](https://www.apollographql.com/docs/references/apollo-config) for more details on configuration options.
Linking to the local schema won't provide all features such as switching schema tags and performance metrics. See [the Apollo config docs][] for more details on configuration options.
### Client-only schemas
@@ -144,11 +144,13 @@ Navigating large codebases can be difficult, but the Apollo GraphQL extension ma
### Schema variant switching
Apollo supports publishing multiple versions ([variants](http://localhost:8000/platform/schema-registry#schema-tags)) of a schema. This is useful for developing on a future development schema and preparing your clients to conform to that schema. To switch between schema variants, open the Command Palette (`cmd + shift + p` on mac), search "Apollo" and choose the "Apollo: Select Schema Tag" option.
Apollo supports publishing multiple versions ([variants](/platform/schema-registry/#registering-schemas-to-a-variant)) of a schema. This is useful for developing on a future development schema and preparing your clients to conform to that schema. To switch between schema variants, open the Command Palette (`cmd + shift + p` on mac), search "Apollo" and choose the "Apollo: Select Schema Tag" option.
## Troubleshooting
The most common errors are configuration errors, like a missing `.env` file or incorrect service information in the `apollo.config.js` file. Please see [the Apollo config docs](https://www.apollographql.com/docs/references/apollo-config) for more configuration guidance.
The most common errors are configuration errors, like a missing `.env` file or incorrect service information in the `apollo.config.js` file. Please see [the Apollo config docs][] for more configuration guidance.
[the Apollo config docs]: /references/apollo-config/
Other errors may be caused from an old version of a published schema. To reload a schema, open the Command Palette (`cmd + shift + p` on mac), search "Apollo" and choose the "Apollo: Reload Schema" option.

View File

@@ -9,33 +9,33 @@ From that information it is possible to track down slow or frequently erroring r
#### How it works
With [one line of configuration](/docs/references/setup-analytics), Apollo Server will start recording traces of every request it receives and sending summaries of that performance data to Engine. Engine aggregates and summarizes those traces to provide segmented, filterable insights about your graph's usage.
With [one line of configuration](/references/setup-analytics/), Apollo Server will start recording traces of every request it receives and sending summaries of that performance data to Engine. Engine aggregates and summarizes those traces to provide segmented, filterable insights about your graph's usage.
<h2 id="trace">Traces</h2>
## Traces
With the metrics reporting set up, you'll be able to see traces of your operations in [Engine](https://engine.apollographql.com). Execution of a GraphQL request happens layer by layer, and each field in the query calls a function in your server called a resolver. The [_trace_ view in Engine](https://blog.apollographql.com/the-new-trace-view-in-apollo-engine-566b25bdfdb0) allows you to look at a detailed breakdown of the execution for individual operations, with timing shown for every resolver.
![Trace view](../img/trace.png)
<h3 id="critical-path">Critical path</h3>
### Critical path
When a trace is opened, some resolvers are collapsed and others are expanded. This is Engine automatically expanding resolvers on the "critical path" of the query. The critical path is the set of fields and resolvers that makes the longest sequence in the query. If you are trying to speed up your query's execution, this is the set of fields you should be looking at first.
<h3 id="sampled-traces">Trace inspector</h3>
### Trace inspector
Every trace stored in Engine records the request's resolver timings, variables, and HTTP headers. This is particularly useful when debugging and the detailed information about the trace can be found by opening up the _trace inspector_:
![Trace Inspector](../img/trace-inspector.png)
<h3 id="tracking-subs">A note on GraphQL subscriptions</h3>
### A note on GraphQL subscriptions
Engine does not currently track statistics or traces for subscriptions. The proxy does, however, support the transparent pass-through of subscription requests and responses.
<h2 id="operation-signatures">Operation signatures</h2>
## Operation signatures
Engine groups operations that select the same fields together, treating different queries distinctly even if they share the same name. Not every query string can be taken as-is for grouping though, because some queries inline their variables. For these cases, Engine has a _signature_ algorithm to normalize inline variables so that queries of the same shape can still be grouped together.
<h3 id="transformations">Signature algorithm</h3>
### Signature algorithm
The current signature algorithm performs the following transformations when generating a signature. (Future improvements to Engine will allow users to customize the signature algorithm.)
@@ -55,7 +55,7 @@ The current signature algorithm performs the following transformations when gene
For example:
```
```graphql
query Foo {
user(id : "hello") {
... Baz
@@ -70,19 +70,19 @@ fragment Baz on User {
becomes
```
```graphql
query Foo{user(id:""){name timezone...Baz}}fragment Baz on User{dob}
```
See the reference implementation of [query signatures](https://github.com/apollographql/apollo-tooling/blob/7e1f62a8635466e653d52064745bf8c66bb7dd10/packages/apollo-graphql/src/operationId.ts#L60) for more information.
<h3 id="signatures-sensitive-data">Signatures and sensitive data</h3>
### Signatures and sensitive data
The signature algorithm is primarily designed to make it possible to treat operations that differ only in trivial ways as the same operation. It also happens that removing the content of string literals appears to achieve greater data privacy within Engine, but this is not the primary goal. In fact, Engine also sends the full raw query along with traces (though it does not currently expose them in the user interface), so relying on the signature to ensure sensitive data never hits Engine's servers is inappropriate.
Future versions of Engine are likely to change this default algorithm to leave string literals alone, though it will still be easy to configure your server to remove string literals like in the current implementation. We also intend to stop sending the full raw query in future versions of Engine, so that the signature algorithm really can be used to avoid sending sensitive data in queries to Engine.
But where possible, we strongly advise that you keep sensitive data in GraphQL variables instead of in literal arguments in the query body, as you can more easily control which variables should be stripped out of the Engine reporting pathway for privacy purposes. See [data privacy](../data-privacy.html) for further detail on how this works.
But where possible, we strongly advise that you keep sensitive data in GraphQL variables instead of in literal arguments in the query body, as you can more easily control which variables should be stripped out of the Engine reporting pathway for privacy purposes. See [data privacy](https://www.apollographql.com/docs/references/apollo-engine#data-privacy) for further detail on how this works.
## Error tracking

View File

@@ -64,7 +64,7 @@ module.exports = {
};
```
The [Apollo config documentation](/docs/references/apollo-config.html#service-config) has more details and advanced configuration options for the `apollo.config.js` format.
The [Apollo config documentation](/references/apollo-config/#clientservice) has more details and advanced configuration options for the `apollo.config.js` format.
## Registering a schema
@@ -136,7 +136,7 @@ Product cycles move fast and it's common for schemas to be slightly different ac
Apollo supports tracking multiple _variants_ for every graph. A variant is just like a regular data graph. It has its own history of schemas, its own metadata store of metrics, and its own operation registry. Variants can be used to track ideas like staging environments, canaries, and deploys of experimental features destined for the production graph.
To get fully set up associating data sent to Apollo with _variant_ information, you'll need to [configure your CLI commands](#register-a-schema-to-a-variant) to send data with a `--tag` flag and [configure your Apollo Server](#associating-metrics-with-a-variant) with a `schemaTag` option.
To get fully set up associating data sent to Apollo with _variant_ information, you'll need to [configure your CLI commands](#registering-schemas-to-a-variant) to send data with a `--tag` flag and [configure your Apollo Server](#associating-metrics-with-a-variant) with a `schemaTag` option.
### Registering schemas to a variant

View File

@@ -171,7 +171,7 @@ Each change to the schema will be labeled with `PASS` or `FAIL` and a URL with f
<img src="../img/schema-validation/service-check-page.png" width="100%" alt="Service check page in the Engine UI">
> **Note:** If you have [installed schema validation checks on your GitHub PRs](#github), the "Details" link in your GitHub checks will take you to the same details link in this output.
> **Note:** If you have [installed schema validation checks on your GitHub PRs](#github-integration), the "Details" link in your GitHub checks will take you to the same details link in this output.
A failed `apollo service:check` command will exit with a non-0 exit code and fail CI checks. There are many cases where it is safe to make a potentially breaking change, as long as the change is made intentionally with an understanding of its impact.

View File

@@ -351,7 +351,7 @@ A central source of truth for your schema in Apollo Engine. It enables schema re
## Schema versioning
Refers to the need to evolve a schema over time. As a schema evolves, there is a potential for introducing breaking changes to clients. The Apollo CLI assists schema evolution by validating schema changes and checking for breaking changes using Apollo Engine. Read more in our article about [schema change validation](/platform/schema-validation/#versioning).
Refers to the need to evolve a schema over time. As a schema evolves, there is a potential for introducing breaking changes to clients. The Apollo CLI assists schema evolution by validating schema changes and checking for breaking changes using Apollo Engine. Read more in our article about [schema change validation](/platform/schema-validation/#set-up-schema-validation).
## Schema stitching