Segregation of `src/data/queries` and `src/data/types` is contra-intuitive

Too wide (and falsy) segregation of GraphQL Types and Resolvers

The first example of this is new ObjectType in src/data/queries/index.js importing fields. Fields should be taken in context of parent type, not as standalone information.

This can ensure some users that custom types cannot have own field resolvers which is false.

In fact, much of fields which can have own resolvers are handled level up (which is possible but not always desired) and makes thinking about GraphQL harder than it actually are.

There is place where I need collect all the opinion and experience. Please, comments are welcomed!

[tim-soft]

Can I propose a rewrite of the example schema with graphql-tools a la https://github.com/kriasoft/react-starter-kit/issues/1379#issuecomment-324509512? This opens up the possibility of schema stitching and I believe also solves your problem pretty easily?

I’m still of the opinion that writing the schema in straight JS feels a little contra-intuitive.

What is too wide is the authorization, could use a query/mutation example with some sort of access control

[ulani]

@langpavel thank you very much for crating this issue! Unfortunately, we have close it due to inactivity. Feel free to re-open it or join our Discord channel for discussion.

NOTE: The main branch has been updated with React Starter Kit v2, using JAM-style architecture.