The new subscription setup is much nicer than the previous one, good work everyone 🙂 👍

@lprocks just asked how our subscriptions compare to Scaphold’s. Here is my answer for those who are interested: @lprocks That's indeed a good and valid question. As I am a part of Graphcool, this answer will probably be opinionated, but I try to stay as objective as I can. First of all, we’re in contact with Scaphold and highly respect the work they’re doing. Both Scaphold and Graphcool had subscriptions out there now for months, Graphcool however in beta, so we could iterate over our Implementation more easily. What you see now is the 2nd iteration of our API. And now a feature breakdown: In Scaphold and Graphcool you can subscribe to multiple mutations in one subscription query. That allows you to write less code and maintain less subscriptions. In Scaphold however, you can not distinguish the behavior of the subscriptions per mutation type. Graphcool allows that by having the

mutation

on the level of the

filter

. People who are used to the

AND

and

OR

syntax know, which powerful filters you can write with that. Scaphold supports basic scalar filters in their subscriptions. However, as soon as you’re building a real big application, relational filters on subscriptions are a necessity. Imagine you want to build Facebook and only get notified when a friend creates a Post, but not when someone else of the hundred millions of users post something. As far as I can see, in Scaphold you currently can’t define a filter for that. So before we released the Subscriptions it was very important to us to support that use case. Graphcool not only supports scalar and relational filters in the subscription, but you can also combine the normal filters with subscription specific filters like

mutation_in

or

updatedFields_contains

. That means in a chat you can say I am interested in all related messages and if the

text

of a message has been updated. This is how you would express it with Graphcools API:

Message(filter: {
	node: {
		room: {
			name: "my chatroom"
		}	
	}
	mutation_in: [CREATED,UPDATED]
	updatedFields_contains: "text"
}) {
	mutation
	updatedFields
	node {
		id
		text
		author {
			id
			name
		}
	}
	previousValues {
		text
	}
}

There is much more to say, especially when it comes to our backend implementation, but I hope this could already give you an overview about the two implementations. In the next weeks we will release a blog article discussing our backend implementation of the GraphQL Subscriptions.

Hi everyone, with Auth0 and React-router is enough to check for the token in localstorage in a route with "onEnter" prop?

hello @fh @oliver welcome to our slack! let us know if you have any questions graphcool 🚀

Hi, I get random internal server errors like this: "GraphQL error: Whoops. Looks like an internal server error. Please contact us in Slack (https://slack.graph.cool) and send us your Request ID: cizr59rs7yp000115tajq8alv"

hello @mathieusylvain @davidyoung 🙌 👋 !

Cheers!

hey @artyom, thanks!

When setting a default date, can it be set to "today" or "now" or some other type of reasonable default?

I've checked the documentation, and it doesn't seem to indicate a way to do this.

thanks for writing this up @martin !

Yeah, no worries. Thanks for everything you do!

Hey there, great work on the new subscriptions!

Wondering if there exists an example for using vanilla js for setting up the query

ie a combo of watchquery and subscribe

we are not using react in our app

@martin Great article, thank you! I have one question, could a user hypothetically just call updateUser with paid set to true manually to skip purchasing?

@theraccoun the API should work just as is, but you call

watchQuery

instead of using the

graphql

container

so you can use

subscribeToMore

or call

client.subscribe

directly

@sashko thanks. I did try calling subscribe directly, but that does not return a promise. I then tried subscribe().result().then() and got "result is not a funciton"

according to the docs subscribe takes some argument that is an observer type

@theraccoun it returns an observable

@sashko hmmm. Still confused. Docs say: subscribe(observer): Subscription

so subscribe takes an observer and returns a subscription

I think you're looking at subscribe on watchQuery

I'm talking about subscribe on the client instance.

It might not be documented

yeah, so the docs aren't updated for that