A few questions / ideas about vesper HOT 6 CLOSED

Just my opinion on the first question.

The resolver are there for the fields you need a customized answer or the field that doesn't exist on your entity.

For example, on your entity POST you have field blogs(OneToMany with BLOG) on your GraphQL type, you have one field called blogNames: [String]. You want to use the resolver for blogName, since it doesnt exist on your entity.

from vesper.

I understand the difference, I just feel that schema stiching would be done better via decorators and you can define all the logic in each entities respective resolver.

Leave controllers for REST APIs :)

from vesper.

Why do controllers and resolvers need to be defined in separate files? I feel like with Graphql, the resolver pattern is all that is needed, and I'm not sure why the distinction needs to be made.

distinction is made by graphql itself, and by conception itself. Root queries are unique, that's why controllers are separate for them. If you think about real difference in vesper, then what it will be? @Controller over @Resolver because resolver resolves some entity while controller is root-based. @Query and @Mutation - only controller can have a mutation, query is much more like a @Resolve, but still terminology of root queries. Think about controllers as root queries.

I started my own Express setup before seeing Vesper, and I'm autoloading my entities, typeDefs and resolvers based on file naming conventions. Is this something that you'd be interested in doing with Vesper? (I know Typeorm already allows this for entities.)

please provide more info. "file naming conventions" - typeorm does not have file naming conventions, and it does not make sense to use file names.

How risky would you say it'd be to use Vesper at this stage of the project?

decide yourself, use it if you like it, like any project it just needs to get more people attention.

Have you looked into Prisma? It auto generates CRUD operations based on graphql models. Is this something you'd be interested in doing with Vesper?

prisma is much more opinionated and provides you certain limits, with vesper you have much more freedom and control on what you are doing.

from vesper.

distinction is made by graphql itself

Technically it's incorrect. Query and Mutation are just normal GraphQLObjectType and getUser query or editProject mutation are just fields of that object type. The only difference is when we attach this "special" object types to schema, so multiple mutations are resolved sequentially while queries - parallel.

from vesper.

I didn't say that typeorm enforces conventions. What I mean is that you can load entities based on configured path, e.g. { entities: ['./src/**/entity{.ts,.js}'] }.

And ah, to be clear, I've specifically been using Apollo Graphql, which generates a schema based on typedefs and resolvers: https://www.apollographql.com/docs/graphql-tools/generate-schema.html

Nest.js also works similarly https://docs.nestjs.com/graphql/resolvers-map

But anyway, I'll go ahead and close this, thanks

from vesper.

What I mean is that you can load entities based on configured path

you can load controllers, resolvers and schemas based on paths as well.

from vesper.