Predefined Folder Structure & Default Config

[iamvishnusankar]

This discussion is the continuation of the PR #238.

Ref: @Weakky https://github.com/prisma/graphqlgen/pull/238#issuecomment-435336822

Unfortunately, there are tons of design decisions embedded in your PR that needs to be discussed first

Not really!. What I've added is an orchestration for the config file before feeding it into the build pipeline. Current behaviour of the generator is to throw an error if no config file is present in the package root folder. Added orchestration will ensure the generation of files even without a config file if the project is in a structured format. Adding a config file will override the default file/folder lookup and will work as intended by the initial design.

• One of our design principle for this project is to be as unopinated as possible.
• Predefined folder structures: Please, take a look at this PR #106
• Default config (No config setup).: I suggest your create a GH issue so that we can discuss that further

I strongly agree with any tooling to stay un-opinionated. However, the mandatory requirement of a config file makes it sort of opinionated to begin with. If, so what's wrong with providing a default config behind the scene and let the user customise the structure according to their needs?.

Predefined folder structure is only for the look up of files using the default config. It doesn't mandate anyone to follow the folder structure for their project. But having such structure could be useful for a no-config setup. Again, we can override all these behavior by introducing a config file to the package root.

• Multiple schema files: This is actually already cover by graphql-import, which also handles lots possible errors by merging schemas.

Please refer #201

This has nothing to do with any schema validation or any other stuff. The only purpose of this is to concatenate multiple schema files into single file. This operation is conducted as part of the config orchestration.

Basically, it will find all the files mentioned in config.schema (wildcard/single file) and concatenate them to generate a single schema file. Once its done, config.schema path will get overrided by the newly created schema path before feeding into the build pipeline.

• Third party provider support: You haven't mentioned anything about it in the description, but I believe you are talking about the apollo-server template. If you could extract this work into a separate PR, it would be really appreciated.

Sorry, my mistake. I totally forgot to add this section when submitting the PR. However, the examples are there in the templates directory.

Having a predefined/predictable folder format would makes things a lot of easier in the long run. Also, this will help to modularise the grpahql contents regardless of the provider library. Please check the following examples, both are using the default structure

Templates : https://github.com/iamvishnusankar/graphqlgen/tree/master/packages/graphqlgen-templates

yoga example

import { GraphQLServer } from "graphql-yoga";

import { resolvers } from "./graphql";
import { data } from "./data";

const server = new GraphQLServer({
    typeDefs: "./src/graphql/__generated__/schema.graphql",
    resolvers,
    context: { data }
} as any);

server.start(() => console.log("Server is running on http://localhost:4000"));

apollo-server-express example

import { ApolloServer, gql } from "apollo-server-express";
import * as express from "express";
import { importSchema } from "graphql-import";

import { resolvers } from "./graphql";
import { data } from "./data";

const app = express();
const PORT = process.env.PORT || 5000;

// Import the schema as string
const schema = importSchema("./src/graphql/__generated__/schema.graphql");

const apolloServer = new ApolloServer({
    typeDefs: gql(schema),
    resolvers: resolvers as any,
    context: { data }
});

apolloServer.applyMiddleware({
    app
});

app.listen(PORT, () => {
    console.log(`server started on http://localhost:${PORT}`);
});