Prisma1: Ability to define a relationship without it appearing on both types.

[ragnorc]

There should be the possibility to define a relationship without it appearing on both types. E.g: If somebody wants to have a feed type in the users node with the posts but does not want to have a field with that relation in the post type.

[marktani]

What's the disadvantage for you specifically in having the "backrelation"?

Possible drawbacks I can think of:

• it "clutters" your schema/api
• permission concerns

[joarwilk]

I would like to +1 this request. I really think this is crucial.

[sedubois]

I concur, forcing a relation both ways can pollute the schema (when one direction would have been enough). It becomes unclear what exactly are the relations which are supporting the business logic and which ones are "stale".

Right now the UI forces the creation of an a-to-b relationship on type A and a b-to-a relationship on type B. It should be possible to define just a-to-b on type A, or just b-to-a on type B.

However it also would be great to be able to easily migrate, e.g if I only have a-to-b on type A, then by the flip of a button I could activate the symmetrical b-to-a on type B (and all the proper data would be put there). Conversely, by the click of a button I could drop the relation on one of the types (which would allow to migrate away from the current situation).

[sedubois]

IMHO this is getting actually rather important. Now as I'm building my types, the types referenced from multiple other types, such a File referenced from Course, Module, Track, etc for their hero image, gets cluttered very fast with plenty of sparse columns (vast majority of values are null).

These columns pollute the view, make navigation more difficult, pollute the exposed GraphQL API, and might also impact DB performance?

[ynuska]

I would like to +1 this request.

[marktani]

Thanks for your feedback! The "backrelation" fields have no impact on performance 🙂

[pbassut]

That would be really good to have. As @sedubois pointed out, most reverse relations are nulled because sometimes it doesn't even make sense to have them. Thus, they're just dead columns for some rows - which is even more strange.

[joarwilk]

I'm already seeing some confusion related to this in my team. People see these relationships in the API and assume they are there for a reason, and then start using them incorrectly. There is a lot of API misdirection related to this.

[pbassut]

@marktani Will this get implemented or we still don't have enough demand for it?

[CrocoDillon]

Sharing my current workaround in case anyone is interested.

We prefix the "backrelation" field (if we are not interested in it) with something like "ignore_", that way it's a little bit less confusing and easier to leave those fields out of (read) permissions.

[ynuska]

@CrocoDillon suggestion works like a charm !

[kbrandwijk]

A big +1. Also, being able to give the two directions of the relationship a different name.

[angineering]

Hi, what is the status on this feature? A big +1 for me.

Not having the ability to do one-sided relations is currently making me consider moving to another database solution, as it is cluttering up my schema quite a lot. As an example, multiple things can have an address or coordinates, but having back-relations on all of those doesn't become all that nice over time. It's a shame, as Graphcool is otherwise such a great solution.

[kbrandwijk]

In some cases, the schema generated by Graphcool, given that it is a full CRUD schema on all types, with, among other things, mandatory back-relations, is not the most suitable to expose directly to the clients. For this reason, the GraphQL Gateway Pattern is a very good fit, as it gives you full control over the final schema exposed to the clients, so you can just leave those back-relation fields out. Have a look at https://github.com/graphcool/graphql-server-example for more information.

[sorenbs]

Thanks for bringing up the graphql-server-example Kim. The Schema Stitching pattern is evolving very fast right now, and I would encourage everyone to take a look at the tooling currently being created by Graphcool and Apollo.

@angineering and everyone else who has commented on this issue - we will make back-relations optional starting with the 1.0 release early next year. Please read the proposal and contribute comments as soon as possible, so we can make sure to implement this in the best possible way.

Additionally, we will remove the relation specific mutations and instead make nested mutations more powerful. I would love your feedback on this decision as well in #1280

[marktani]

I'm closing this feature request, please join the discussion in https://github.com/graphcool/framework/issues/1280, which has progressed quite far already 🙂

[smojtabai]

@marktani can you re-link that by chance, I am trying to find more info on this.