This deserves a blog post

[wtrocki]

GraphQL Serverless and Eventing is one of the most demanded topics with many people looking for example. I would love to promote the gql-source and even contribute after I will get some understanding how it works but it will be easier if there is simple blog post one can follow. I have tried to run example but still do not get how things work here.

@itsmurugappan

[itsmurugappan]

Thanks @wtrocki , I wrote a blog in medium, but i guess you are looking for more detailed one on how to get started right ?
I will write a detailed one on the pattern and how to use it.

[wtrocki]

Haven't seen it. It looks great. I have couple questions. Is this for subscriptions only?
What is the flow - Let's say that I have subscribed and created new item on client

In typical app my event source will be create mutation that publish event and sink would be subscription to divert data to client. Diagram is the other way around which made me think that I do not understand KNative enough to get it.

What is connecting to sink?
Would this work with serverless mutations?

[wtrocki]

The GqlSource subscribes to this endpoint and tracks the changes on menu and other info.

This sound to me like I have my own server and now GQL source will issue GraphQL subscriptions to that server and expose it to some sink. I think explanation that uses GraphQL queries will make your blog post every successful.

What query goes where etc.

What I was looking for is to have multiple serverless services that support GraphQL mutations that could become event sources and single statefull server that will utilize sink to send payload to subscribed clients. Are we in the same space? This will enable serverless GraphQL subscribtions - subscribtions typically require stateless info about clients so are unfit to become functions on it's own

[itsmurugappan]

sorry for a delayed response.

This sound to me like I have my own server and now GQL source will issue GraphQL subscriptions to that server and expose it to some sink. I think explanation that uses GraphQL queries will make your blog post every successful.

This is right , i will add the queries to the blog post. Thanks for the suggestion.

What I was looking for is to have multiple serverless services that support GraphQL mutations that could become event
sources and single statefull server that will utilize sink to send payload to subscribed clients. Are we in the same space?
This will enable serverless GraphQL subscribtions - subscribtions typically require stateless info about clients so are unfit to become functions on it's own

This is very interesting. Few q's

1. When you say multiple serverless services that support GraphQL mutations are those resolvers?
2. The client usually establishes a websocket connection with server to get the changes, how can this be delegated to a sink ?

[wtrocki]

1. Yes (subscription resolvers might need to be in statefull server instead of lambda)

2. Subscription resolvers are used to establish connection on non serverless server (Subscriptions handling) then publish subscribe mechanism is used on changes