search

aerogear / graphback

Graphback - Out of the box GraphQL server and client
https://graphback.dev
Apache License 2.0
409 stars 73 forks source link

Graphback templates improvments #2035

Open wtrocki opened 4 years ago

wtrocki commented 4 years ago

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: https://github.com/RedHat-Middleware-Workshops/rhtr-2020-api-mgmt-kafka-workshop/pull/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 commented 4 years ago

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

machi1990 commented 4 years ago

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 commented 4 years ago

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.

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

machi1990 commented 4 years ago

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,

machi1990 commented 4 years ago

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