Clarify connections with naming, count field, and convenience field

[dschafer]

The connections in this repo are designed to allow efficient pagination
by associating cursors with each item in a connection:

{
  allPeople {
    edges {
      cursor
      node {
        name
      }
    }
  }
}

When quickly exploring the API, though, it can be useful to have a shortcut
to just get the list of objects:

{
  allPeople {
    people {
      name
    }
  }
}

While this shortcut would not allow for the efficient cursor-based pagination
that Relay and other clients might implement, it's quite convenient for browsing
the API.

To clarify naming once that shortcut is added, each field that returns a
connection is renamed:

{
  personConnection {
    people {
      name
    }
  }
}

Finally, it's useful to have a total count of the number of items in each
connections, so that field is added:

{
  personConnection(first: 5) {
    totalCount
    people {
      name
    }
  }
}

[leebyron]

is array.length here the result of a first limit? Or is this the info derived from the swapi API request that tells you total count?

[dschafer]

This is for the case where we're converting a list of URLs into a connection, so we're just counting the URLs here.

[dschafer]

facebook/relay#185 allows Relay to detect usages of fields like this, and suggest using edges { node } instead to allow for efficient cursor-based pagination.

[josephsavona]

👍

[leebyron]

I'm curious what @schrockn thinks about this case. To me, the "xConnection" naming scheme seems less clear here, as a connection implies a source node, and these are just paginateable lists from the query's root. I think allX is actually clearer in this case.

[dschafer]

Agreed, I could go either way on this one.

[schrockn-zz]

although allFilmsConnection is strictly more consistent I think I prefer allFilms

[schrockn-zz]

This PR is excellent. Thanks.