Remove client stubs generation from SDKs

[shykes]

Problem

The cloak DX is currently very rough. One particularly rough area is the client stub generation, because it causes duplication of effort. For each action implemented in Go or Typescript, the developer must write 2 different but redundant graphql schemas: one for the server-side implementation (new field and its parameters), one for the client-side implementation (new query with same parameters).

For example see the netlify go extension:

Server-side (schema.graphql):

extend type Query {
  netlify: Netlify!
}

type Netlify {
  deploy(
    contents: FSID!
    subdir: String
    siteName: String
    token: SecretID!
  ): Deploy!
}

type Deploy {
  url: String!
  deployURL: String!
  logsURL: String
}

Client-side (operations.graphql):

query Deploy(
  $contents: FSID!
  $subdir: String
  $siteName: String
  $token: SecretID!
) {
  netlify {
    deploy(
      contents: $contents
      subdir: $subdir
      siteName: $siteName
      token: $token
    ) {
      url
      deployURL
    }
  }
}

The only purpose of the client-side file is to allow client-side stub generation.

Solution

As a stopgap, remove client stub generation entirely, while leaving the possibility of bringing it later, as an optional add-on layer.

The benefits of this stopgap are:

• Having to write manual graphql queries is a better DX than having to write redundant schema files with confusing filenames
• Less complex SDK implementation, easier to understand and change
• Better knowledge sharing across languages: if a typescript dev found the perfect graphql query to solve a particular problem, it can be reused as-is by go or python developers.

[sipsma]

@shykes I agree that operations.graphql is pure boilerplate and terrible DX, but I'd prefer we address this by just autogenerating operations.graphql from schema.graphql rather than by skipping client stub generation. Have an issue for that here: #3111

The reason being that using raw graphql queries from go is really, really bad. We actually do this with internal code occasionally just for convenience and because we're temporarily okay with giving our own selves a bad DX, example here of one single graphql query: https://github.com/dagger/cloak/blob/408c1a9dbce2b16ee2771b647f17f1544da7592b/cmd/cloak/config/config.go#L154-L194

You have to create inline structs yourself, you have to make sure you get the casing on each field in the struct exactly correct, it's highly verbose, etc.

I fear that having users do that themselves would be a huge loss to the DX for go actions. My current effort for the next few days is to clean up a bunch of DX issues like this, so if you agree with my sentiment here I will include generating operations.graphql as part of that effort.

[shykes]

The topic of how and when to generate stubs, and the role of operations.graphql, is still very relevant, but this issue is no longer up-to-date. I'm closing it to avoid confusion. This should not be understood as this topic being entirely resolved, as we know :)