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

A new path for graphql-cli - help us decide on the roadmap! #519

Urigo opened this issue Aug 14, 2019 · 4 comments


Copy link

commented Aug 14, 2019

Hi everyone!

I'm @Urigo the founder of The Guild.

As recently been announced on the Prisma blog, we are taking over the maintenance of this library going forward.
I've expressed it in the blog post in more details but I would like to start by thanking Prisma for conceiving, creating and maintaining this library so far and also for doing the selfless act of providing it with fresh life by handing over the maintenance to us.

We already have a certain plan in mind going forward, some of it we've specified in the blog post, but we want you, the users and community of the library to be part of influencing the roadmap going forward.

One thing to note about The Guild - We place all the open source packages we maintain under individual person's Github profile instead of under a GitHub org or a company.
That is part of our philosophy - it puts more accountability on the maintainer and it also lowers the barrier of creating successful competing forks.
So we will transfer that repository from under its current org as part of the transition.

I'm looking forward to start the discussion here below.
Please share how and why you use the library today, what are your biggest pain points today and ideas and features you would like to see in the future.

I will add points into the description here as we go.

Let's make this happen!


This comment has been minimized.

Copy link

commented Aug 16, 2019

I'm really excited to see graphql-cli get attention and commitment! I'm also big fans of how Prisma has created and shepherded so many valuable OSS offerings in this space, so this move is fitting to their selflessness and interest in ensuring the long term value of these tools.

I'll share my use-cases and experiences, which are fairly simple but may resonate with others, as well as a few wish-list items. I'm also interested in helping out in whatever way makes sense.

Many of my use-cases involve introducing people to a GraphQL ecosystem/API during an architecture/planning phase or introducing devs to GraphQL concepts for the first time during new application development.

Personal Use Cases

  • This CLI is an incredibly easy way to get someone up and running with a .graphqlconfig file via graphql init. If the API already exists, step 1 for me is to install this CLI and start exploring the data.
  • Step 2 is graphql get-schema as I really appreciate the .graphql file instead of .json since it's much easier to poke around and show fellow devs what's there.
  • Step 3 is usually to add in the Voyager plugin, this view is really comfortable for people especially if GraphQL is a new concept for them.
  • Step 4 (that I haven't been doing) is to automate the pull of the schema file at build time. Recently I've been working with teams developing APIs on AWS so when we use GraphQL it has been AppSync serving (oftentimes) an SPA or static site. I would like a build hook that pulls the schema and validates all the client queries against it - however, the vulnerabilities reported by npm have kept me from being able to include the CLI as a dependency. So it's a manual task right now. On a recent install of graphql-cli npm reported: found 70 vulnerabilities (64 low, 1 moderate, 4 high, 1 critical) which is not ideal to add to a new project for a client 😏.

Wish List

  • Mock data API server. For a while on the README it has listed graphql-cli-faker as "coming soon". In lieu of something I could run from this CLI within dev/test scripts I make a very simple express server that lives alongside the app and uses makeExecutableSchema and addMockFunctionsToSchema from graphql-tools to get a mock API endpoint up and running quickly based on an existing schema. It would be great if the CLI could do this for me, and accept mocks and typeDefs modules as arguments to override or extend functionality.
  • Playground is nice, but I really like graphiql-explorer as it is such an easy way to show the power of GraphQL query building.

I hope some of this is helpful to hear or resonates with other users of this CLI. Looking forward to seeing where this goes!


This comment has been minimized.

Copy link

commented Aug 16, 2019

Thanks a lot for picking it up that's really appreciated. I also like to use graphql-cli for new APIs.
And agree on the storage of a schema as a plain file instead of JSON.

Something I would love to see in graphql-init is the addition of auth parameters for the graphql endpoint.

The use case I wrote a plugin for graphql-cli is to ease import of data into new graphql-apis using their mutations fed from CSV/JSON files.

I'm more of a JS noob so I guess my plugin would need more work to make it robust and great, but I'm happy to invest in it.

It would be good to learn about API and other changes of graphql-cli and perhaps even have some means of automatic testing for plugins with new builds.


This comment has been minimized.

Copy link

commented Aug 30, 2019

Cheers my friends! Congratulations on the partnership between Prisma and The Guild.

Primary Use Case

We use the command graphql codegen to generate our Typescript Prisma bindings.

The Node.js framework Nest has a Nest + Prisma Recipe which makes heavy use of graphql-cli. The recipe makes it extraordinarily simple to create a GraphQL gateway to a Prisma v1 server. The recipe uses prisma/prisma-binding as the generator for graphql-cli to generate the prisma.binding.ts file. This file does all the heavy lifting for the schema delegation to Prisma v1. Combining these technologies together allows for a declarative, idiomatic way of writing GraphQL resolvers for any new type defined in the datamodel.prisma. You get so much for free by leveraging off of code generation and a Prisma server:

  • Code generated Typescript static types for great dev tooling.
  • Access to Prisma GraphQL connections (cursor based data paging)
  • Access to Prisma server Subscription endpoints to react to any mutations occurring on a GraphQL type. Reactive, type safe, real-time networking over websockets for free!
  • Prisma data loader optimizations for resolving queries efficiently (solving the N+1 problem)
  • Prisma generated GraphQL SDL file to allow for remote schema introspection (query code completion)

The data layer has never had such a great dev experience. Really good code generation has enabled front-end devs to finally contribute to the back-end. (an industry first?) Allowing them to modifying the server's data model with confidence, and write their own GraphQL resolvers in a declarative manner. This gives teams much more agility than was previously possible. The following are code snippets that are deployed in production. You get all the listed above for free by simply writing something akin to:


type TuDefinition {
  id: Int! @id
  word: String!
  definition: String!


import { UseGuards } from '@nestjs/common';
import { Query, Mutation, Resolver, Args, Info } from '@nestjs/graphql';
import { GqlGuard, Roles } from '../../auth';
import { PrismaService } from '../../prisma';

@Roles('EDITOR') // This gives those with this role read/write access to this GraphQL type
export class TuDefinitionResolver {
  constructor(private readonly prisma: PrismaService) {}

  async tuDefinition(@Args() args, @Info() info) {
    return await this.prisma.binding.query.tuDefinition(args, info);

  async tuDefinitions(@Args() args, @Info() info) {
    return await this.prisma.binding.query.tuDefinitions(args, info);

  async tuDefinitionsConnection(@Args() args, @Info() info) {
    return await this.prisma.binding.query.tuDefinitionsConnection(args, info);

  async createTuDefinition(@Args() args, @Info() info) {
    return await this.prisma.binding.mutation.createTuDefinition(args, info);

  async updateTuDefinition(@Args() args, @Info() info) {
    return await this.prisma.binding.mutation.updateTuDefinition(args, info);

  async updateManyTuDefinitions(@Args() args, @Info() info) {
    return await this.prisma.binding.mutation.updateManyTuDefinitions(args, info);

  async upsertTuDefinition(@Args() args, @Info() info) {
    return await this.prisma.binding.mutation.upsertTuDefinition(args, info);

  async deleteTuDefinition(@Args() args, @Info() info) {
    return await this.prisma.binding.mutation.deleteTuDefinition(args, info);

  async deleteManyTuDefinitions(@Args() args, @Info() info) {
    return await this.prisma.binding.mutation.deleteManyTuDefinitions(args, info);

Deprecated dependency concern

graphql-cli@latest has a dependency on apollo-codegen@0.20.2.

$ npm view apollo-codegen
DEPRECATED!! - The 'apollo-codegen' command has been replaced with the more-powerful 'apollo' CLI. Switch to 'apollo' to ensure future updates and visit for more information.

$ npm ls graphql
+-- graphql-cli@3.0.14
| +-- apollo-codegen@0.20.2
| | `-- graphql@0.13.2         ←------- Notice this dependency
| +-- graphql@14.5.4  deduped
| `-- graphql-schema-linter@0.2.1
|   `-- graphql@14.5.4  deduped

Due to apollo-codegen being a deprecated library, it is pulling in an old version of graphql. This mismatch in graphql versions is causing npm to not dedupe the dependency. #366 (comment) This has caused me problems with apollographql/apollo-tooling in the same project as graphql-cli. Apollo would force me to only have 1 version of graphql in my node_modules folder. I would have to manually delete the old version of the pulled in graphql dependency every time I did a npm install. Fortunately, in recent updates, this issue of having only one version of graphql in the node_modules folder no longer seems to be an issue for us. At any rate, it would be really nice if there could be something done about this deprecated dependency.


This comment has been minimized.

Copy link

commented Sep 1, 2019

One thing i liked about graphql-cli's vs graphql-codegen is the ability to generate a full graphql typescript client with query/mutation/subscription functions that mirror all the possible graphql types.

for example (from hasura schema):

const userConnections = await client.query.userDataSource({
    where: {
      dataSourceId: { _eq: 'pocket' },
      _or: [
        { lastSuccessfulPoll: { _is_null: true } },
        { lastSuccessfulPoll: { _lte: '2019-09-01T22:02:07.000Z' } },

AFAICT, graphql-codegen only supports generating the types themselves, and you then have to use apollo client or similar to execute the queries...

can you talk a little bit about how the client-generation fits into your roadmap? This is fairly important to me as I use the generated Binding types and client in node projects (non-react, for example) that use graphql data access.

(cross posted from dotansimha/graphql-binding#325 (comment). not sure which is the appropriate place to discuss this use case)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
5 participants
You can’t perform that action at this time.