While it used to be required to pass the `--save` flag in order to actually
write the dependency to the project's `package.json` file, this is no longer
the case in recent versions of npm.
Hey guys,
I've noticed that some of the gql examples are indented differently than the rest and I think that consistent indentation and formatting makes it easier to read and comprehend.
Let me know what you think, thanks.
In an effort to maintain consistency and semantically correct meaning,
this changes (only in documentation and internal Apollo Server tests) the
name of the first argument in resolver signatures to use `parent` rather
than `root`.
While `root` certainly makes sense when the resolver is belonging to the
root `Query` or `Mutation` type, once nested field resolvers begin getting
called, the more semantically correct term would seem to be `parent`.
Since `parent` still makes sense at the root level, and since resolvers
frequently get copied and pasted into more deeply-nested positions, putting
this pattern in place for apps which are just beginning might just help
someone more clearly understand the relationship in the future — without
incorrectly thinking that a nested resolver is accessing the root of the
graph, rather than the parent.
Fix grammar, and hopefully make the explanation a bit clearer.
It could also be said like this (for a smaller diff) ;-)
"By allowing the consumer of the API to see the full possibilities that an API can *deliver*, developers can"...
`esModuleInterop` was enabled in
e4164c8892
to help with importing from packages that use default exports.
Those changes were reverted in
https://github.com/apollographql/apollo-server/pull/1210
to work around a few reported issues. Those issues are no longer
relevant, so this commit re-enables `esModuleInterop`, and
updates all default imports to use the more common (standard)
import syntax.
* docs: Correct path for GraphQL Playground.
This corrects the documentation which incorrectly stated that the message on the console would include `http://localhost:4000/graphql`.
While the `/graphql` URL will also serve the GraphQL Playground, it's only working as a by-product of of `/graphql` being included within the (higher) `/` path. (That is to say that `/any-url` would also respond!).
* [squash] Tweak per feedback.
cc @evans
* feat: ApolloServer is created and exported by all variants
* docs: add initial docs around exporting ApolloServer
* feat: export gql from integrations
* docs: change apollo-server examples to use express with registerServer
* server: remove registerExpressServer
* core, docs: comment functions, fix api reference, context creation more like middleware args
* docs: fix integrationed typo
* Bury Best Practices, for the time being.
* Bury Schema, but leave it on disk.
* Introduce new Querying section.
* Move "Why Apollo Server?" into "Index".
* ...to be refined.
* Remove no-longer-helpful "Getting Started" from "Index".
cc @stubailo @evans @peggyrayzis @JakeDawkins @unicodeveloper @jbaxleyiii
While the `gql` tag is not currently _required_, it does make it easier to
implement additional, development-friendly functionality in the future.
For example, it could avoid the need to question whether a string literal is
actually using Schema Definition Language (SDL) and avoid the need to
look for context clues.
By implementing these suggestions now, we can avoid the need to ask
developers to refactor in the future.
