I have a bare-bones prototype of a generic GraphQL notebook which lets you run and save queries based on endpoints in your GraphQL config files:

gqlnb.mp4

In the recording above, I'm creating a single 'GraphQL' notebook controller, and at runtime I'm reusing the
vscode-graphql extension's GraphQLContentProvider to look for endpoints based on the config file in the project directory. In my recording, the config file points to GitHub's GraphQL endpoint like so, allowing me to run a query about the currently authenticated user (myself):

endpoints: {
  default: {
    url: "https://api.github.com/graphql",
    headers: {
      Authorization: `Bearer ${process.env.VSCODE_GITHUB_GRAPHQL_API_TOKEN}`,
    },
  },
},

I prototyped this in vscode-graphql itself so that I could reuse the following logic that already exists for executing queries in the vscode-graphql extension:

Parsing config files for endpoints
Extracting literals from a text document
Network helper logic

And by putting the GitHub schema file in the project root and referencing it in my config file, I also get syntax highlighting and some schema help.

The branch is here (fair warning, this code is not production ready and I'm sharing it just so you have an idea of what it takes to hook the existing execution logic up to a notebooks UI): joyceerhl/vscode-graphql-notebook@1c5e631

Some notes from this prototype:

The current GraphQL execution experience prompts the user to pick an endpoint if there is more than one configured. I think it could be a nice experience with the notebooks UI to instead register a controller for every endpoint that the user has in their config file, so you aren't prompted to pick the endpoint every time you want to run a query. However, note that the selected endpoint would then be global for the notebook document, so you'd need to either have one notebook per endpoint, or switch controllers a lot. Any thoughts on this @sschneider-ihre-pvs?
I recall that LSP might be getting first class support for notebooks, and then we could update the GraphQL language server to be notebooks-aware. Maybe @rebornix has more details?
@acao you mentioned wanting to split execution into its own extension that builds on top of vscode-graphql. Would you prefer that I duplicate all the code (GraphQLContentProvider, NetworkHelper, SourceHelper) that I used for my prototype into a new extension vscode-graphql-notebook?
The current GraphQL execution experience prompts the user to fill in variables when a query is executed--it could be a nice experience to allow setting variables in some table/tree view UI so you can tweak and rerun them easily
Because we are using process.env, which isn't available in the browser, this approach will not work in VS Code for the Web :(
@acao I'm not familiar with "subscription" operations in GraphQL, how does that operation signal that it's "done"? This is important for making sure that we end the notebook cell execution task when all the data that we need to report in the notebook cell outputs has returned (otherwise the notebook cell would continue to execute indefinitely)

General graphql notebook #7

Description

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions