Generate transport JSON for the original fixed schema, selected operation, and current variables. A separate expected-fixture result helps review the request without claiming a server response.
Qualify an existing Playground setup
The GraphQL Playground repository is archived. Its README directs future IDE development to GraphiQL. Treat this task as reviewing an existing pinned Playground HTML setup rather than recommending an unversioned legacy CDN install for a new project.
Record the exact HTML package or bundle, middleware if any, dependency versions, loader, browser, and setup revision. The repository also documents a historical unsanitized-input vulnerability and fixes. Review the actual retained dependency chain and configuration handling before implementing it; do not interpolate raw user strings into generated HTML settings.
Keep any future IDE migration as a separately identified implementation. The request/schema checks below remain useful, but a GraphiQL setup is not the same installed package as Playground.
Define the original schema and resolver contract
Use schema revision S1:
type Query {
note(id: ID!): Note
}
type Note {
id: ID!
label: String!
}
The fixture resolver returns the note with id n1 and label Cedar when the coerced ID is n1. For an unknown ID, it deliberately returns null without an additional application error.
Query.note is nullable. Its id argument is required, while the fields of a returned Note are non-null. The GraphQL schema guide explains the default nullable type and Non-Null modifier.
These are independently authored fixture rules, not a guarantee that every API returns null for an unknown record. A different resolver or authorization policy could behave differently.
When preparing the fixture endpoint, record its SDL and resolver source, implementation version, schema revision, and permitted endpoint identity.
Keep document and variables as separate inputs
The intended operation is:
query GetNote($id: ID!) {
note(id: $id) {
id
label
}
}
Its JSON variables are:
{"id":"n1"}
For this single-operation test, explicitly record operationName GetNote even though operation selection has no competing operation. The expected response data is:
{"data":{"note":{"id":"n1","label":"Cedar"}}}
This response is a target for the future resolver, not a captured response. Do not place it in an “Actual result” panel or imply that loading the editor produced it.
The query document uses GraphQL syntax. The variables use JSON with double-quoted property names and string values. Malformed JSON variables should be held by the authored client policy before a request is sent. Do not silently substitute the previous valid variables.
The GraphQL ID specification allows string and integer inputs according to ID coercion rules. Do not write a negative test claiming an integer is automatically invalid merely because the fixture's successful ID is a string. Use missing or null required id as the clear invalid-input cases.
Reject invalid field selections before field execution
The GraphQL validation guide distinguishes syntactic correctness from validity against the schema. Requesting unknown fields or omitting an object's selection set fails document validation before field execution begins.
Use these original negative cases independently:
| Case | change | Expected disposition |
|---|---|---|
| V1 | Replace label with title | title is absent from Note; validation error |
| V2 | Request note(id: $id) without subfields | Note requires a selection set; validation error |
| V3 | Variables {} for GetNote with no default | Required id unavailable; request cannot execute |
| V4 | Variables {"id":null} | Non-null id requirement fails |
| V5 | Variables text with broken JSON syntax | Authored client hold; no request sent |
V1 and V2 should not return partial note data as if the invalid document executed. The expected server validation response has errors and no data field. Exact error messages, paths, and HTTP status remain implementation observations to collect later.
Keep variable preparation separate from document validation. A document can have a valid variable declaration while its submitted variables are missing the required value. A readable editor and highlighted syntax do not complete either check.
Select an operation explicitly when the document contains two
query GetNote($id: ID!) {
note(id: $id) { id label }
}
query GetOther($id: ID!) {
other: note(id: $id) { id label }
}
Try the worked example
Compose GetNote with n1, then GetOther with the same variables. The expected response key changes to other. Try an unknown ID for expected null, then remove id to hold the request. Nothing is sent. An expected fixture response is not captured transport evidence.
This builds a local request for fixed known operations, not a Playground installation, general GraphQL validator, endpoint, or executed API request.
Recreate this example
Build one complete self-contained HTML page for this task: compose a GraphQL request for the original fixed-schema fixture without sending it.
Use these exact original practice data and worked expectations: S1 Query{note(id:ID!):Note},Note{id:ID!,label:String!}. Resolver fixture n1→{id:n1,label:Cedar};unknown ID→null. GetNote returns the note key; GetOther uses the alias other. Variables {"id":"n1"}; missing or null id held; integer IDs allowed.
Implement the following useful local interactions: OperationName input GetNote/GetOther, JSON variables textarea, Compose. Use a fixed two-operation document, require explicit name, validate a JSON object and string/integer ID, compose JSON query/operationName/variables. Show expected fixture result labeled expected, never actual. Do not claim general GraphQL validation. Preserve the supplied source text and distinguish an uncomputed state, a successful local result, and an invalid or incomplete input. Update output only from the current input snapshot. An input edit must retire stale feedback until the reader runs the relevant action again. Do not silently invent missing values or replace a failing case with a success.
Design the page as a compact source-and-result developer workbench with readable code, labeled inputs, and a separate explanation area. Put a compact task heading, actual sample data, the main result, and usable controls early enough to be useful on a narrow screen. Use readable text of at least 16px, generous paragraph spacing, strong contrast, native labels, accessible buttons, and visible keyboard focus. Stack long records at 360px and wrap code without page-level horizontal overflow.
Use type=button and explicit querySelector-based click handlers rather than relying on form submission. If Enter is useful, handle it only on the relevant input and ignore isComposing. Keep effects within this open page; no remote dependencies, network calls, persistence, fake downloads, or automated sending. This builds a local request for fixed known operations, not a Playground installation, general GraphQL validator, endpoint, or executed API request. Place worked explanations beside their data and identify teacher or synthetic examples clearly. Output only the complete HTML document, with inline styles and script and LF line endings.
Review the query-only request composer in NOS
Use the composed request with an authorized fixture endpoint and capture its real response separately. Review GetNote and GetOther's different response keys beside their composed requests in NOS, and revise eligible static operation instructions in visual editing mode before the endpoint test.