Apollo/GraphQL field type for object with dynamic keys

35
votes

Let's say my graphql server wants to fetch the following data as JSON where person3 and person5 are some id's:

"persons": {
  "person3": {
    "id": "person3",
    "name": "Mike"
  },
  "person5": {
    "id": "person5",
    "name": "Lisa"
  }
}

Question: How to create the schema type definition with apollo?

The keys person3 and person5 here are dynamically generated depending on my query (i.e. the area used in the query). So at another time I might get person1, person2, person3 returned. As you see persons is not an Iterable, so the following won't work as a graphql type definition I did with apollo:

type Person {
  id: String
  name: String
}
type Query {
  persons(area: String): [Person]
}

The keys in the persons object may always be different.

One solution of course would be to transform the incoming JSON data to use an array for persons, but is there no way to work with the data as such?

3
graphqlapolloapollo-server
Can you clarify what you mean by b and g being dynamically generated depending on my query? Does the presence of one or the other depend on the fields present in the request? – Daniel Rearden
@DanielRearden So b and g are id's. Perhaps I should make that clearer in the question. The query will contain options to only get a subset of people, so for one query the response will contain people with id's a, b, c and for another query for example b and g as in the question. – Andru
@DanielRearden I now changed b to person3 and g to person 5 and added some text and a variable to make it clearer. The query will contain options to only get a subset of people as now outlined in the text. – Andru
github.com/graphql/graphql-spec/issues/101 – Bergi

3 Answers

31
votes

GraphQL relies on both the server and the client knowing ahead of time what fields are available available for each type. In some cases, the client can discover those fields (via introspection), but for the server, they always need to be known ahead of time. So to somehow dynamically generate those fields based on the returned data is not really possible.

You could utilize a custom JSON scalar (graphql-type-json module) and return that for your query:

type Query {
  persons(area: String): JSON
}

By utilizing JSON, you bypass the requirement for the returned data to fit any specific structure, so you can send back whatever you want as long it's properly formatted JSON.

Of course, there's significant disadvantages in doing this. For example, you lose the safety net provided by the type(s) you would have previously used (literally any structure could be returned, and if you're returning the wrong one, you won't find out about it until the client tries to use it and fails). You also lose the ability to use resolvers for any fields within the returned data.

But... your funeral :)

As an aside, I would consider flattening out the data into an array (like you suggested in your question) before sending it back to the client. If you're writing the client code, and working with a dynamically-sized list of customers, chances are an array will be much easier to work with rather than an object keyed by id. If you're using React, for example, and displaying a component for each customer, you'll end up converting that object to an array to map it anyway. In designing your API, I would make client usability a higher consideration than avoiding additional processing of your data.

2
votes

You can write your own GraphQLScalarType and precisely describe your object and your dynamic keys, what you allow and what you do not allow or transform.

See https://graphql.org/graphql-js/type/#graphqlscalartype

You can have a look at taion/graphql-type-json where he creates a Scalar that allows and transforms any kind of content:

https://github.com/taion/graphql-type-json/blob/master/src/index.js

0
votes

I had a similar problem with dynamic keys in a schema, and ended up going with a solution like this:

query lookupPersons {
  persons {
    personKeys
    person3: personValue(key: "person3") {
      id
      name
    }
  }
}

returns:

{
  data: {
    persons: {
      personKeys: ["person1", "person2", "person3"]
      person3: {
        id: "person3"
        name: "Mike"
      }
    }
  }
}

by shifting the complexity to the query, it simplifies the response shape. the advantage compared to the JSON approach is it doesn't need any deserialisation from the client

Additional info for Venryx: a possible schema to fit my query looks like this:

type Person {
  id: String
  name: String
}

type PersonsResult {
  personKeys: [String]
  personValue(key: String): Person
}

type Query {
  persons(area: String): PersonsResult
}

As an aside, if your data set for persons gets large enough, you're going to probably want pagination on personKeys as well, at which point, you should look into https://relay.dev/graphql/connections.htm