You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
apollo-parser provides users with an AST to programmatically derive information from any given GraphQL input. Although the parser runs lexical and syntactic analysis, we still cannot be certain that the input provided does not contain errors. To ensure that the input is entirely error free, apollo-rs’s compiler must also take into the account each input statement’s context. All of this will be done as part of semantic analysis.
There are two main goals of this task:
Validate each statement in an input and ensure it contains no errors.
Provide a user-facing API to context. To be able to 1. the compiler must build up knowledge and details about each statement’s context. This context, let's call it Source Database, is to be provided as an API.
High-level implementation details
Validation is to be separated out into two parts: document and type system validation. To unblock other Apollo teams, we will focus on query work first.
All statement validation requires knowledge/context awareness. This will manifest itself as accessor methods to the Source Database. These will be the basis of queries, a user-facing API for Source Database, which will be backed by salsa-rs. The queries are to be expanded based on the information needed overtime for validation or usage purposes. Examples information includes:
“get all fragment names in a given query”,
“get all arguments defined by a given operation definition”,
“is this variable used in a given query already defined?”,
"what is the type of the current node?",
"given this type, what are its subtypes?".
In the process of validation, we might have to do some processing, or normalisation (e.g. processing StringValue). This should not modify the original AST, but should modify the string values in Source Database.
Initial validation work will focus on whether an node is semantically correct, and produce semantic errors. As per apollo-rs error-resilience philosophy, semantic errors will be returned alongside The next stage for diagnostics work is to additionally create warnings, hints and suggestions.
Diagnostics will be divided into: errors, warnings, hints and suggestions. Hints and suggestions will be an addition to the errors and warnings created.
Context
apollo-parser
provides users with an AST to programmatically derive information from any given GraphQL input. Although the parser runs lexical and syntactic analysis, we still cannot be certain that the input provided does not contain errors. To ensure that the input is entirely error free,apollo-rs
’s compiler must also take into the account each input statement’s context. All of this will be done as part of semantic analysis.There are two main goals of this task:
High-level implementation details
salsa-rs
. The queries are to be expanded based on the information needed overtime for validation or usage purposes. Examples information includes:apollo-rs
error-resilience philosophy, semantic errors will be returned alongside The next stage for diagnostics work is to additionally create warnings, hints and suggestions.Current task list:
The text was updated successfully, but these errors were encountered: