-
Notifications
You must be signed in to change notification settings - Fork 113
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
Comments
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
Wish List
I hope some of this is helpful to hear or resonates with other users of this CLI. Looking forward to seeing where this goes! |
Thanks a lot for picking it up that's really appreciated. I also like to use graphql-cli for new APIs. 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. https://github.com/neo4j-graphql/graphql-cli-load 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. |
Cheers my friends! Congratulations on the partnership between Prisma and The Guild. Primary Use CaseWe use the command The Node.js framework Nest has a Nest + Prisma Recipe which makes heavy use of
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: "datamodel.prisma" type TuDefinition {
id: Int! @id
word: String!
definition: String!
} "tu-definition.resolver.ts" import { UseGuards } from '@nestjs/common';
import { Query, Mutation, Resolver, Args, Info } from '@nestjs/graphql';
import { GqlGuard, Roles } from '../../auth';
import { PrismaService } from '../../prisma';
@Resolver('TuDefinition')
@UseGuards(GqlGuard)
@Roles('EDITOR') // This gives those with this role read/write access to this GraphQL type
export class TuDefinitionResolver {
constructor(private readonly prisma: PrismaService) {}
@Query()
@Roles('REGISTERED')
async tuDefinition(@Args() args, @Info() info) {
return await this.prisma.binding.query.tuDefinition(args, info);
}
@Query()
@Roles('REGISTERED')
async tuDefinitions(@Args() args, @Info() info) {
return await this.prisma.binding.query.tuDefinitions(args, info);
}
@Query()
@Roles('REGISTERED')
async tuDefinitionsConnection(@Args() args, @Info() info) {
return await this.prisma.binding.query.tuDefinitionsConnection(args, info);
}
@Mutation()
async createTuDefinition(@Args() args, @Info() info) {
return await this.prisma.binding.mutation.createTuDefinition(args, info);
}
@Mutation()
async updateTuDefinition(@Args() args, @Info() info) {
return await this.prisma.binding.mutation.updateTuDefinition(args, info);
}
@Mutation()
async updateManyTuDefinitions(@Args() args, @Info() info) {
return await this.prisma.binding.mutation.updateManyTuDefinitions(args, info);
}
@Mutation()
async upsertTuDefinition(@Args() args, @Info() info) {
return await this.prisma.binding.mutation.upsertTuDefinition(args, info);
}
@Mutation()
async deleteTuDefinition(@Args() args, @Info() info) {
return await this.prisma.binding.mutation.deleteTuDefinition(args, info);
}
@Mutation()
async deleteManyTuDefinitions(@Args() args, @Info() info) {
return await this.prisma.binding.mutation.deleteManyTuDefinitions(args, info);
}
} Deprecated dependency concern
Due to |
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):
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) |
This is already possible using https://github.com/Urigo/graphql-cli/blob/master/packages/commands/serve/src/index.ts To make it more roboust this can be the responsibility of the generate command that will have some layers that developers can use.
This will be awesome as app template that has voyager enabled.
@ZenSoftware Those are the use cases that generate command can provide. Underlying lib (https://graphback.dev)) will support data-loading layer along with connections etc. All in the next release. Current generate is very simple as we wanted to integrate as fast as possible for feedback This is currently possible using |
Integrate GraphQL Boilerplates? From Discord (humarkx / ardatan ) who does maintain https://github.com/graphql-boilerplates/typescript-graphql-server/tree/master/advanced ? graphql-boilerplates |
Docs pages, create them |
Stop splitting the code in dozens of packages, why should i download all these different plugins before using the cli? The reasons to stop using “plugin system” are obvious to me:
|
@remorses I can under your point of view. But, we would like to have a generic CLI for GraphQL, that isn't too much opinionated.
I think it's a matter of preference, and the reasons for choosing a plugin system are:
We are thinking about adding some plugins as default, it might make it a bit opinionated but will reduce the need for installing all default plugins. One more thing, we encourage people that are building GraphQL tools that has CLI to build a simple plugin instead of maintaining their own CLI wrapper, and have the benefit of using GraphQL Config and GraphQL CLI which loads schema and documents in an easy way. I hope this covers the background for choosing that. If you really think it's something we should improve - feel free to share an alternative solution that answers the requirements above :) |
auto detect |
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!
The text was updated successfully, but these errors were encountered: