Graphback templates improvments

[wtrocki]

Templates should have separation of concerns

When using Graphback templates we geting index.ts file that has multiple elements and concerns that developers need to read. It will be much better to have graphback.ts file

See example PR that has this:
RedHat-Middleware-Workshops/rhtr-2020-api-mgmt-kafka-workshop#3

Additionally, we could extract migrations and have this also visible for users as well.

Templates should use different subscription mechanisms

In memory, subscriptions are not helping to understand concepts.

Enterprise template is needed

We need to provide an enterprise template. See #2016

Template can be consumable as docker images (along with graphback code)

Building all templates into quay will be desirable to be able to test stuff in container land.

[machi1990]

/cc @craicoverflow, @machi1990
Automatically generated comment to notify maintainers

[machi1990]

Very good issue. Thank you for opening it @wtrocki

I think in this template we can push for a "certain" architecture / project structure. E.g instead of having a db.ts file, maybe we can have a database/create-data-provider.ts, subscriptions/setup-pub-sub.ts, resolvers/mutations/xxx-mutation.ts, resolvers/query/xxx-query.ts etc something self explanatory, with clear separations of folders to indicate a structure / organisation. Add a testing folder and an example test file, unit testing a custom resolver for example, and an integration test etc

/!\ Thinking out loud.

Enterprise template is needed

We need to provide an enterprise template. See #2016

Do you see this issue superseding #2016?

[craicoverflow]

In my view, the current templates are "starting points" and do need need to push a certain architecture. From experience I dislike when templates have a certain architecture which I don't plan on keeping, it then creates more work for me. I would like to see an opinionated, production/enterprise template though, this can have more stuff and be more organised.

• ts-apollo-mongodb-basic-backend
• ts-apollo-postgres-basic-backend
• ts-apollo-mongodb-enterprise-backend
• etc...

https://github.com/graphql-boilerplates/typescript-graphql-server/tree/master

[machi1990]

In my view, the current templates are "starting points" and do need need to push a certain architecture. From experience I dislike when templates have a certain architecture which I don't plan on keeping, it then creates more work for me. I would like to see an opinionated, production/enterprise template though, this can have more stuff and be more organised.

• ts-apollo-mongodb-basic-backend
• ts-apollo-postgres-basic-backend
• ts-apollo-mongodb-enterprise-backend
• etc...

I agree with you on templates being a "getting-started" and very fine with what we already have as a getting started. Having a different flavour, with a bit more structure, an example Dockerfile, testing, and possibly other scripts (e.g hot reloading with nodemon or node-dev ) that reflects the workflow likely to be encountered on a modern web API. The idea is to show more than just setting up a Graphback API,

• but how the project can be organised (this in accordance to our expertise and frankly, our opinion on how to structure a GraphQL API),
• how it can be tested,
• how it can be built, deployed etc

[machi1990]

https://github.com/graphql-boilerplates/typescript-graphql-server/tree/master

This is a good starting point but I see things like testing, which is core, are missing