mirror of
https://github.com/zhigang1992/apollo.git
synced 2026-01-12 22:45:53 +08:00
Clean up links and unecessary component in the homepage
This commit is contained in:
1581
docs/package-lock.json
generated
1581
docs/package-lock.json
generated
File diff suppressed because it is too large
Load Diff
@@ -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"
|
||||
}
|
||||
}
|
||||
|
||||
@@ -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 />
|
||||
|
||||

|
||||
|
||||
@@ -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.
|
||||
|
||||
|
||||
@@ -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.
|
||||
|
||||

|
||||
|
||||
<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_:
|
||||
|
||||

|
||||
|
||||
<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
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
|
||||
@@ -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.
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
|
||||
Reference in New Issue
Block a user