even after running twitter validator https://cards-dev.twitter.com/validator

Thanks for catching that Sebastien - we include a prerendered image in the meta tags. We just have to update it 🙂

I also naively searched for "authentication", "Auth0" in the page and didn't find anything. Might be nice to have text and Auth0/Digits logos there + possibly Facebook and other social things

You are right - A lot of text is hidden behind interactive elements. We should make that more accessible, so it can be searched on page and properly indexed by google. Great point!

Did you record the latest meetup or something? The subject of the talks sounded interesting.

yes! the videos are in our YouTube channel

Talks: http://www.youtube.com/playlist?list=PLn2e1F9Rfr6lOjIpdhj6HVXKCkUzLQ-WN

I’ve been doing some thinking about versioning APIs in graphql… does anyone have experience with this?

he’s essentially saying “if you can achieve the desired change by adding fields that’s preferable to changing the existing fields”, which is obvious, and not very helpful. there are cases where that’s not sufficient, and that’s what I’d like to discuss

Thanks @nilan 🙂

applying the same concept to mutations: if you want to change the behaviour of a mutation

doSomething

you'd create a new mutation

doSomethingInASimilarManner

... but that naming scheme doesn't seem very scalable. I'm wondering if it could make sense to version individual mutations like

doSomethingV1

doSomethingV2

If you are talking about graphql in general you could always have multiple roots.

/graphql/v1/...

/graphql/v2/...

If you really need to

in fact this is how the url on graph.cool looks like

<https://api.graph.cool/simple/v1/{cuid}>

Facebook has 400 old versions of their mobile app running against the same endpoint. Quite an achievement 🙂

We included a version number in the Graphcool url, but will do everything we can to not have to bump it.

@pedro Do you have a concrete example where you would have to introduce a breaking change?

for example, if you change the nature of a relation. so that it returns more or less items. you could add a new relation, but then the naming could start to get weird...

I think whole-api versioning is not super useful

unless you have a lot application logic behind it like stripe does, so that it’s actually one api, but it exposes various versions.

i mean, surely the concept of a breaking api change is not just a theoretical construct no? if fb doesn’t break the api, it’s not coincidental... they have to have a set of rules. (and it’s likely it involves naming of some sort) the ways that come to my mind are naming descriptively (doSomethingInSpecificManner) or versioning (doSomethingV3)… but maybe I’m just missing something.

I think there are two cases for you to consider. Let’s use your example with a relation. If you are introducing a breaking change because the business logic demands a change, this change should probably apply to all clients, so just introduce the change without any name change. If you have two different clients that need to retrieve a different number of items from the relation this should be handled by arguments on the relation field. Luckily you can introduce optional arguments to an existing field without breaking existing consumers.

So none of these introduced a breaking change

ok, cool. I didn’t know about the optional relation arguments. that makes sense 👍

just to be clear it is NOT optional relation arguments but arguments on the relation field

@sdubois new landing page looks fabulous!

the general case would be “pass arguments to change the behaviour”, so that works for me

Can you use interfaces in graph.cool ?

Hey @willotter we don't support interfaces yet, but it is coming. Maybe you could describe your use case?