Move graphql folder out of src

[maticzav]

I have mixed opinion about having src folder because next omits that all together as well and it seems genuinely clearer for a framework with a fixed structure. I don't know whether this might be important for TS to work as expected, but I believe it is possible to get that running as well.

I believe it would be really cool if you could have Next and Yoga, for example, in the same folder and simply have pages and graphql folder. Having src folder for Yoga kind of brakes that because then there’s this src which adds to the vagueness of where to start reading the source. The idea of having all of them in the same folder sounds very nostalgic to all the great features of GraphCool which I believe attracted many other people as well.

cc @schickling

[DevanB]

Are you proposing that the src folder be removed (and only a graphql folder containing types) be in the root? Or that the graphql be alongside the src folder?

[maticzav]

@DevanB, sorry for a vague explanation. Indeed, I am proposing that we remove the src folder by default. Nevertheless, users could still have it for other purposes or could configure root to point to a particular folder in the yoga config. (That's why I titled the issue "moving graphql out of src".)

[Weakky]

Hey @maticzav 👋,

I like your proposal, does the tree below properly sums up the tree structure you're describing?

.
├── graphql
│   ├── context.ts // (optional)
│   ├── resolvers
│   │   ├── Mutation.ts
│   │   └── Query.ts
│   └── server.ts // (optional)
├── package.json
└── pages
    ├── ComponentA.tsx
    └── ComponentB.tsx

I added a resolvers folder to properly separate the additional files that you might have and your actual resolvers. Flattening every might be a better option, I don't know, the tree below feels weird to me:

.
├── graphql
│   ├── Mutation.ts
│   ├── Query.ts
│   ├── context.ts
│   └── server.ts
├── package.json
└── pages
    ├── ComponentA.tsx
    └── ComponentB.tsx

What do you think?

[maticzav]

@Weakky the first option seems excellent. I like the separation of concepts and folder names do their job very well. I also added my initial idea below, but I think your suggestion might do an even better job. Could you maybe also add the database (prisma) files?

I also added yoga-config.ts, yoga-context.ts and yoga-server.ts files which are all inspired by how GatsbyJS handles configuration files as opposed to keeping them in the folder (names explain their purpose).
I like this approach because it feels like you are only working on frontend even though there's a significant amount of logic that you can put in the resolvers. Besides that, I believe it feels more natural to have an additional resolvers folder which holds more complex structures alongside the graphql folder (similar to components and pages).

I think it would be fascinating to compare the folder structure of Yoga alongside NextJS and GatsbyJS which I believe will be used most frequently together.

[robinduerhager]

little disclaimer: i just stumbled across this repo and i'm quite interested in this, so maybe you already considered my thoughts on this 😄. Anyway thank you for creating such beautiful and fun to use GraphQL solutions 👍 .

@Weakky you can see in @maticzav reply that he also separates yoga-server from the graphql folder. My proposal would be to give the developer the freedom of choosing where certain modules of his yoga2 application can be found.

'Hardcoding' paths and names like the parent folder 'graphql' seems reasonable at first, however we can't ever be sure that a developer would name this folder exactly this way and keep this folder structure for each project he has (See the False consensus effect).

For example: a developer could or might want to for example also just call this parent folder frontend-api to make clear, that this is the interface for the frontend to communicate with the backend while separating his resolvers into a /Query/ and /Mutation/ folder respectively.

I think default values are fine for people which don't want to configure a lot or just use the boilerplate to get started, but quite a lot of people tend to customize stuff.

My approach on one of my projects with graphql-yoga for example:

• resolver functions were separated by functionality into subfolders but then imported in the /src/resolvers/ folder
• graphql-yoga server instance in server.js in /server/
• prisma content inside a /database/ folder instead of a /prisma/ folder

I try to make clear that each developer might think different in this 😄