Apollo-tooling: Support service projects better in VS Code

[NickClark]

Intended outcome:

I expected it to report some level of success like my client project does. Maybe something like:

🚀 Apollo GraphQL v1.5.0
------------------------------
✅ Service Loaded!
🏷 Schema Tag: current
📈 Number of Types: 22
------------------------------

Actual outcome:

🚀 Apollo GraphQL v1.5.0
------------------------------

How to reproduce the issue:

It appears to halt on simply adding the service property. But this is my exact config:

module.exports = {
  service: {
    localSchemaFile: './src/generated/schema.graphql'
  }
};

Despite no actual error being raised, I see no apparent result. I guess I expected, at a minimum, to see autocomplete in the schema.graphql file. Maybe I'm just expecting the wrong results.

Versions

V1.5.0

[JakeDawkins]

Hi @NickClark! This is actually by design right now.

Service projects aren't supported as fully as client projects are. For this reason, the status bar button just prints the extension version and opens the output window (in case there are any errors).

What would you expect to see for autocomplete in the schema? Since the autocomplete results are based on the schema, I'm not sure what you'd be able to do here.

[NickClark]

I figured it would be less featured... I guess it may just be comforting for the IDE to complete known types, default primitives, etc. I guess that boils it down to more of a spell checker. But it'd be helpful none-the-less 😄

[JakeDawkins]

True, true! I'll keep this in mind as we move forward. We should be working on service tooling quite a bit in the near future! For now, I'll rename this to make it easier to track. Thanks for the feedback :)

[FredyC]

I want to join this proposal. We have already tooling in place for managing schema and authorization tokens. The schema file is actually versioned in Git. It's "agile" development, so schema is changing quite often and we want the code versioned together with it.

Anyway, I would argue that autocomplete based on local schema is like "spell checker" as @NickClark called it. It kinda feels like a key feature if I can directly see what fields and arguments I can use when writing queries.

Up until now, I've been using GraphQL for VSCode which works exactly like that and it is super helpful. However, it has a fairly complicated setup and for some team members, it simply doesn't work. And development is rather stagnating.

PS: It's kinda pity that this is another project introducing its own way of configuring graphql endpoints while there is graphql-config that is already recognized by couple of tools. It makes it much harder to keep all those configs in sync.

[JakeDawkins]

@FredyC Sorry, but I'm not sure what you're suggesting.

Anyway, I would argue that autocomplete based on local schema is like "spell checker" as @NickClark called it. It kinda feels like a key feature if I can directly see what fields and arguments I can use when writing queries.

We already do support that on client projects. This issue was talking about _service_ projects only.

[FredyC]

Well, I am definitely confused about some terminology here in that case. I tried to install and configure extension, but it wanted from me a service api key and there was a bunch of other strange errors.

I would be expecting is that with the following config it would parse schema file and provide intellisense based on it. Why would it need to connect to any service really? Or did I misunderstood the purpose of that extension?

module.exports = {
  service: {
    localSchemaFile: './src/generated/schema.graphql'
  }
};

[JakeDawkins]

@FredyC Definitely understandable! We've been working on improving the docs around configuration, but it's still a bit confusing.

the top level service key is only used when developing services, not the clients that consume them. To set up a client project that consumes a graphql api, you'd use the top level client key in the config. There's some instructions about setting that up here.

You'd want to look at Option 3: Link a schema from a local file to do this. Hope that makes sense :)

[FredyC]

Ok, I see a difference now, but this is exactly the document I've been using and it did not work with local schema only. I will open a new issue with relevant information.

[mdecurtins]

Hi @JakeDawkins @hwillson any updates on this issue? Working intellisense for GraphQL server projects would be a godsend.

[olup]

Hi, same here. Intellisense is provided by code first approaches, but graphql js does not cover directives. Or there is typegraphql but class decorators... c'mon...
Would love to be able to work with a safe environment with the schema first approach, and through multiple splitted schema files. Any progress this way ?