[bestpractices] Add caching section to talk about identifiers

[dschafer]

Add a caching section, talking about how to replace a URL-based cache. This mentions globally unique identifier as a recommendation, describes how to use additional fields for backwards compatibility, then talks about how you can also allow the client to derive this, which is ideal in situations where existing APIs already have an established pattern for what ID means.

[dschafer]

Goal here was to have the article establish three major things:

• You really, really want the client to be able to derive a globally unique ID, for caching.
• If the server can provide that ID? That's a pretty short path to the above, do that.
• There server does not have to provide that ID, though. If the server doesn't, have a plan for how the client will derive it.

@stubailo - really interested in your thoughts on this one , I tried to incorporate some of what you wrote up in https://medium.com/apollo-stack/graphql-at-facebook-by-dan-schafer-38d65ef075af#.x1mwck563

[stubailo]

Going to take a look in a bit!

[lacker]

I don't think you need a globally unique id for caching per se. You pretty much always have an object type, so as long as you have a per-type-unique id, it should be fine for caching. Ember.js requires this, for example - in the ember store, every object needs both a type and a per-type-unique-id. So to me this is one way to do it but I wouldn't really describe it as best practices, to think in terms of "globally unique ids".

[stubailo]

@lacker yeah that's about what we do in our example app: https://github.com/apollostack/GitHunt-React/blob/a1756d31ac5f6c1d048eab642b5b507c91c302c2/ui/client.js#L43

I think the way this section is worded has enough caveats that it makes sense to me. I think it's reasonable to say that life becomes a bit easier if you have unique IDs provided by the server, but this page reinforces that it's not a hard requirement.

[lacker]

OK, YOLO let's run with it 🏃

[stubailo]

I disagree that this is associated with whether or not it is possible to build a rich cache, since it's definitely achievable without one. So I think this is a best practice, but not because it's easier to cache - it just makes your API cleaner since you have a consistent source of IDs for all objects.

[leebyron]

This looks good.

Something to mention just on this thread is that we've been toying with a __id meta-field which would expose a globally unique ID, so it's not too crazy to assert it as a best practice for now.

[stubailo]

Yeah for sure.

[taion]

I'm not sure if this is relevant here, but UUID-based caches are in general not enough for Relay-style patterns that allow refetching based on these IDs. I guess maybe this is one of those things that Relay 2 fixes and makes non-existent, but I had to think a bit before realizing why I couldn't just use my UUIDs as my global IDs for my Relay-compatible GraphQL server.