Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

query language for database's executable definitions #411

Open
lrlna opened this issue Jan 9, 2023 · 2 comments
Open

query language for database's executable definitions #411

lrlna opened this issue Jan 9, 2023 · 2 comments
Labels
apollo-compiler issues/PRs pertaining to semantic analysis & validation triage

Comments

@lrlna
Copy link
Member

lrlna commented Jan 9, 2023

Would kind of be interesting to explore querying executable definition types with a smaller query language that we can use in the database.

Given a schema:

  interface Pet {
    name: String
  }

  type Dog implements Pet {
    name: String
    nickname: String
    barkVolume: Int
  }

  type Cat implements Pet {
    name: String
    nickname: String
    meowVolume: Int
  }

  union CatOrDog = Cat | Dog

  type Human {
    name: String
    pets: [Pet]
  }

  type Query {
    human: Human
  }

and a query like this:

{
  human {
    pets {
      name
    }
  }
}

it would be interesting to be able to do something like this compiler.db.query.find("human.pets.name").

@lrlna lrlna added triage apollo-compiler issues/PRs pertaining to semantic analysis & validation labels Jan 9, 2023
@goto-bus-stop
Copy link
Member

Would be interesting to see how we'd select a nickname field here as it can refer to two different definitions.

{
  human {
    pets {
       ... on Cat { nickname }
       ... on Dog { nickname }
    }
  }
}

Apollo federation internals in TypeScript has an OperationPath API to represent this and they heavily use it as well in query planning, we could have something similar.

I'm not sure a query language is the best way to frame it as I think in practice you'll almost always work with dynamic paths, so having a structured representation in memory is more important than writing a particular path by hand. Though we could always have a OperationPath::parse("[email protected]") for example.

@goto-bus-stop
Copy link
Member

There is a spec proposal for operation paths: https://github.com/graphql/graphql-wg/blob/main/rfcs/OperationExpressions.md

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
apollo-compiler issues/PRs pertaining to semantic analysis & validation triage
Projects
None yet
Development

No branches or pull requests

2 participants