Add relation trigger for subscriptions

[marktani]

Currently, updates to a relation don't trigger any subscriptions. Related to #14.

[myagoo]

Any update on this ?

[kbrandwijk]

@myagoo Apparently, it's WIP now 👍

[dohomi]

+1

[nigeltiany]

Anything new on this?

[danmkent]

So will this change mean that a subscription listening for UPDATED on a type will be triggered when relationships are connected or disconnected? Or will there be a new kind of mutation to listen for?

[nigeltiany]

@danmkent for now subscribing to mutations when [CREATED,UPDATED,DELETED] only work for the fields of the type. This improvement is supposed to listen for edge mutations as well, such that if type A has a field comments where comments is another type, a mutation on the comments type should publish as a mutation on type A.

[myagoo]

Does an added comment trigger a CREATED mutation on A ? I would expect a UPDATED mutation Le mar. 25 juil. 2017 à 18:21, Nigel Tiany <notifications@github.com> a écrit :

…

@danmkent <https://github.com/danmkent> for now subscribing to mutations when when [CREATED,UPDATED,DELETED] only work for the fields of the type. This improvement is supposed to listen for edge mutations as well, such that if type A has a field comments where comments is another type, a mutation on the comments type should publish as a mutation on type A. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <https://github.com/graphcool/feature-requests/issues/146#issuecomment-317790506>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA_QRG2RwP_2JBakexHbw3OUPc-PQmJSks5sRhYigaJpZM4Mk74r> .

[nigeltiany]

@myagoo me 2. Because the array of related types(comment type by id) just got larger.

[sorenbs]

Hi all - thanks for the patience.

When we introduce this it will be in the form of two new mutations, probably called CONNECT and DISCONNECT in line with the naming for Permission Queries. So the behavior of subscriptions for CREATE, UPDATE and DELETE will not change.

We currently don't have a timeline for this, and unfortunately the WIP label is not accurate.

[nigeltiany]

@sorenbs From the naming of the two new mutations, will a schema will only publish updates when a relationship is created/destroyed with another schema? Since a connection/disconnection only happens once, how will the parent schema be able to continually subscribe to mutations on its [ CONNECT ]ED schema(s)?

[nigeltiany]

It is a challenging problem because sometimes the behavior this issues proposes is a bug, is a wanted behavior for certain cases. I propose setting a flag to enable edge mutations or a way to denote queries that subscribe to edge mutations.

subscription newPosts{
      Post(filter: {
               mutation_in: [CREATED, UPDATED, DELETED] 
          }) 
           {
               mutation
               node {
                   id
                   title
                   slug
                   imageUrl
                   description
             // Just like this one right below counts connections
                   _likesMeta {
                       count
                   }
             // and is different from 
                   likes {
                        id
                   }
             // comment being another schema updates only if title, slug, imageUrl Changes if updates exist
                   comment {
                        comment
                   }
             // but maybe if written like this, any updates on comment publish this subscription
                  :comment {
                        comment
                  }
            }
       }

Although this would probably have to come from graphql core.

Another alternative is server functions

import graph_cool_admin from 'graph-cool-admin'

graph_cool_admin.schema('comment').onWrite(() => {
   // if post schema has a subscription query
   graph_cool_admin.schema('post').subscriptions.publish()
})
// Or
// A WYISWYG UI that does the same thing

Server functions are probably a better alternative because it is a flag (the current behavior is retained if the function is not written) and it does not need the graphql core to be changed

[marktani]

@nigeltiany I am not quite following, can you make an example of what changes you'd like to be notified of?

This feature request covers changes introduced by connecting or disconnecting two nodes for a given relation, what have you thought of instead?

[nigeltiany]

All I'm saying is that. Imagine a post with many comments. The relation would be a One - Many. If a post is created, it does not have comments at first. When a comment is created and added to the relation, the proposed connect mutation should publish the post as updated with a new comment. All this is fine. But what if the connected comment changes? When the comment changes, a subscription query on posts would not be published because the comment is already connected and to get the updated comment, one would need to delete (disconnect) the comment and add the relation once more (connect) to the comment with the changes.

If there was an admin API, much like the firebase admin api that allowed developers to write code based on database events, then there wouldn't be a need for the proposed connect/disconnect mutations. Developers would be able to write functions on the console like so

import graph_cool_admin from 'graph-cool-admin'

graph_cool_admin.schema('comment').onCreate(() => { // or onUpdate // or onDelete
   // if post schema has a subscription query
   graph_cool_admin.schema('post').subscriptions.publish()
})

[marktani]

Thanks, now I understand what you mean! This use case can be currently tackled by subscribing to updates to all comments that are connected to a specific post for example.

Your suggestion is also very interesting, I think it's worth a separate feature request. Could you create one? 🙂

[nigeltiany]

Sure.

[myagoo]

If nigel understood well, then the CONNECT and DISCONNECT subscriptions will be useless to me (and others which are waiting on this issue). I want to be able to create subscriptions which represent a full domain, and if anything change, i expect an UPDATE to be triggered. Creating others subscriptions and managing them is too much work. Le mer. 2 août 2017 à 19:52, Nigel Tiany <notifications@github.com> a écrit :

…

All I'm saying is that. Imagine a post with many comments. The relation would be a One - Many. If a post is created, it does not have comments at first. When a comment is created and added to the relation, the proposed connect mutation should publish the post as updated with a new comment. All this is fine. But what if the connected comment changes? When the comment changes, a subscription query on posts would not be published because the comment is already connected and to get the updated comment, one would need to delete (disconnect) the comment and add the relation once more (connect) to the comment with the changes. If there was an admin API, much like the firebase admin api <https://firebase.google.com/docs/functions/use-cases> that allowed developers to write code based on database events, then there wouldn't be a need for the proposed connect/disconnect mutations. Developers would be able to write functions on the console like so import graph_cool_admin from 'graph-cool-admin' graph_cool_admin.schema('comment').onCreate(() => { // or onUpdate // or onDelete // if post schema has a subscription query graph_cool_admin.schema('post').subscriptions.publish() }) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <https://github.com/graphcool/feature-requests/issues/146#issuecomment-319748229>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA_QRNrL6CBchT836dzzelpCnc0Pc71tks5sULdCgaJpZM4Mk74r> .

[nigeltiany]

#339

[kbrandwijk]

@myagoo I think this FR and the proposed additional Subscription triggers offer a great solution for many use cases. So I think your statement about its uselessness is a bit over an overstatement. Also, I do believe that your app component design is clearly going very wrong, if you need a single subscription for changes to an entire graph of nodes.

[benseitz]

I would also use these new subcriptions 👍
@marktani Any news on when they might be implemented?

[Jannis]

I wouldn't call CONNECT/DISCONNECT updates useless but I do agree with @myagoo that an UPDATE would be nice when nested data changes.

Imagine a subscription like

subscription User {
  User {
    node {
      id
      name
      friends {
        name
        interests {
          name
          tags {
            name
          }
        }
      }
    }
  }
}

Let's say a tag or interest changes that can be reached with the subscription query, then it seems like a desirable feature to receive an update with at least the affected users, their friends, their friends' interests and the tags of their friends' interests.

A simple (and slow) approach to implementing this could be to identify all models that are involved in a subscription query (in this case: User, Interest, Tag) and re-execute the subscription query if a database event comes in for any of these models. (It would be slow since there would be even more cases of subscription queries not being affected by the database event than right now.)

Another (quite complex) approach could be to identify exactly which data nodes (i.e. users, interests, tags with specific IDs) are involved in a subscription.

1. At the time the subscription is created, the query could be executed, all returned nodes collected,
2. Whenever a database event comes in, the subscription manager could check match the changed node (e.g. a specific interest) against the nodes of each subscription. The subscriptions that are a match would have their query re-executed, their nodes updated and the result returned back to the subscriber.

This second approach is doable but there are cases where it is still not sufficient. Pagination and filters are such a case - like how would the server know that a created/updated node affects a subscription query with a specific pagination range or specific filters. In these cases, falling back to the simple approach might be an option.

[mattferrin]

I suspect a simple predicate per subscription (that returns true or false) could accurately control whether a subscription updates. If any node of any type matches the predicate after an update, delete, or create, re-query the whole thing.

Allowing predicates on fields to recalculate fields would be interesting, but arguably more complicated.

Ideally, in my opinion, the industry needs a version of SQL databases that have live queries baked in. It's easy to imagine an SQL where clause that gathers all entities of all types that match before stitching them together. Then if any entity change causes that entity to newly match the SQL where clause, patch a cached result or re-calculate the whole thing.

[danielkcz]

Little bump here? I was kinda hoping that with Prisma there could be a solution to this. I think that @Jannis described the issue well in https://github.com/graphcool/prisma/issues/146#issuecomment-347549500.

@marktani @schickling Do you have at least some timeline now?

[senorcodecat]

Bump as well. Any timeline on this?

[schickling]

We're definitely looking into this. Apologies for the delay!

[Aetherall]

To me, the CONNECT and DISCONNECT mutations would solve many issues
I am really looking forward for an update, or any news on this topic :)

[mcmar]

Hi @schickling , it looks like you added this to roadmap/2018-Q3. Can you clarify what that means? Do you anticipate this being ready by the end of September?

[goulderb]

@schickling Given that we're now officially past Q3, what is the status of this issue? Is it still planned to be addressed this year?

[sorenbs]

This continues to be an important feature for us. I'm sorry that we failed to communicate properly as it became clear to us that this would not make it in Q3. I'll update this issue when we have a concrete timeframe. See also this explanation for why we were unable to ship this feature in Q3 as planned.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 10 days if no further activity occurs. Thank you for your contributions.

[benliger1987]

Any movement/ update on this one?

[alexisthual]

@sorenbs Has there been any update on this topic?

Of course, it'd be awesome to be able to track all nested objects from a subscription.
However, pushing information on CONNECT and DISCONNECT sounds like a quick-win that would partially solve the problem. Are there any plans on implementing this soon? 🙂

[stormfar]

For anyone willing to go with a workaround, this solution works:
https://www.graph.cool/docs/reference/graphql-api/subscription-api-aip7oojeiv/#relation-subscriptions

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 10 days if no further activity occurs. Thank you for your contributions.

[mcmar]

@sorenbs Can we re-open this issue? I hope this doesn't get lost on the roadmap just because stale-bot is a little trigger-happy.

[waneka]

i'm almost a little scared to bump this because it's such and old issue but i'm curious if there's any updates on this? i would love this feature on a project i have. thanks!