search

graphql-compose / graphql-compose-mongoose

Mongoose model converter to GraphQL types with resolvers for graphql-compose https://github.com/nodkz/graphql-compose
MIT License
708 stars 94 forks source link

Rethinking graphql-compose-mongoose #101

Open st0ffern opened 6 years ago

st0ffern commented 6 years ago

Hi @nodkz,

I just started working on a knex adapter for graphql-compose and was looking into graphql-compose-mongoose source.

Would it not be cleaner and better to use TypeComposers as main objects and then create mongoose schemas from the TC Objects ? This would be a better standard when integrating other adapters like rest, knex, elastic and so on..

nodkz commented 6 years ago

Hi, Kristoffer. Nice to hear that you start developing knex adapter.

Yep, for "generating" exists two approaches:

  1. Models -> GraphQL Types (current graphql-compose-mongoose implementation)
  2. GraphQL Types -> Models (Prisma/Graphcool approach) screen shot 2018-05-22 at 13 59 06

Honestly, I dislike what Prisma do. They make API as the main edge of your backend. Put API in the first place.

But I think that backend is not only API! There are many other tasks which may/should do not via API (cront task, some internal operation, jobs, manual migration scripts, analytics, complex internal scripts and so on). And all this data/model may not/should not be exposed via public API.

ORMs have history and great experience under the hood, great communities. They may have some crazy initialization options and lifecycle hooks (compound indexes, full-text search configs, geospatial indexes, custom lifecycle hooks). All this cannot be natively expressed via SDL (need to write a bunch of directives, what Prisma do. But all they are very primitive for now).

That's why I preach Model -> GraphQL approach which not lock developers by our plugins/adapters features and allows to use the full power of ORMs and generate from its models only that what need to end-developer for API.

screen shot 2018-05-22 at 13 59 21

PS. Prisma takes this way because it allows creating GaaS (SaaS) and sells their products as ready solution as a service. And the can earn money on it. They take care about Models, Hosting, and Operations. And it very useful for startups and medium businesses.

Please excuse me for maybe unproper comparison: Prisma like Wordpress. Allows solving 95% of tasks very easy. But rest 5% is not their care and you should do it via crazy hacks or other services.

graphql-compose gives freedom for backenders, but not provide many ready solutions. And many things should be done by hands.

All tools have its trade-offs.

So what I think about graphql-compose-knex? I want to see it like graphql-compose-mongoose. BUT graphql-compose does not enforce any approaches for plugins/adapters. They may be realized in any manner. Even they may provide both approaches for better DX ;)

st0ffern commented 6 years ago

Ok, thanks for the headsup! I will rewrite the script 👍

nodkz commented 6 years ago

Will you transfer your repo to graphql-compose organization in future? Or will maintain it yourself?

st0ffern commented 6 years ago

I can transfer it and the others i have.. i also have graphql-compose-dataloader.

Is it possible to join the organisation if i want to continue to maintain?

nodkz commented 6 years ago

Of course! Just send invitation