Spins up a local instance with a pseudo-backend for testing graphQL requests from a frontend client(Apollo Client in this case). Refer to helpful links below for the link. Once there, connect to your local instance to begin making requests (snippet below for context).
For query/mutation templates to start with, see: ./src/requestTemplates.js
.
- Run
npm i
- Run
npm run start
- Go to #helpful links #1 and connect to port 8000 in the top left corner.
- Query -
- Mutation -
- Schema -
- Resolver -
- Operation Name -
- Operation Body -
- Query/Mutation name -
- Variables -
- Scalar Types -
- Input Types -
- Related Data -
- Nested Queries -
- Fragments -
- GraphQL clients(frontend/backend)
- GraphQL sandboxes - This one!
Overfetching and underfetching in applications oftens means n calls to enable a feature in an application. Leading to cumbersome latency/memory issues. As well as tight coupling between traditional REST endpoints and changing client/feature requirements.
- providing an extra layer of validation for creating/updating entries in our backend prior to making changes to our DB.
- Early failure detection for invalid calls in top layers of request cycle vs in a controller layer.
- replaces age old "API churn and burn" by allowing devs to essentially key what they want.
- self documenting schema and gql server requirements
- requires defining/re-defining types for changes to backend table models
- requires further interoperability between teammates so type/input definition changes and required response data structures are easily handled.
- one of several motivations for graphql being created was to avoid api churn and burn. However, this arguably requires same amount of effort to address for nested query for filtering table entity associations. E.g: querying an author while filtering their books according to time ranges provided.
- GraphQL client Sandbox: https://studio.apollographql.com/sandbox/explorer
- GraphQL Docs: https://graphql.org/learn/queries/