-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Map type #101
Comments
I think this is a valid concern as well. I currently thinking of ways to add GraphQL endpoint for our API. We are building project-based multi-tenant service. For example every project has a list of products which have name and description. Just like in your case these are localized strings as well. One way one can approach this problem is to parametrize the field: query ProductNames {
products {
nameEn: name(locale: "en")
nameDe: name(locale: "de_DE")
}
} Another approach, as you mentioned, would be to generate a schema of-the-fly. In our case it would be possible, since every project has a limited set of locales which are defined in the config of this project. Where it becomes more tricky is an addition user-defined data types. Users of our API can define new attributes for products (visually through the merchant-center application). These attributes are also typed, so it's possible to generate GraphQL schema for this project, but it has some implications:
I guess one can just put all custom attribute JSON in a string scalar, but I don't think that other developers will appreciate JSON inside of string inside of another JSON :) I feel that generic JSON/Map-like type can provide a very useful middle-ground for these use-cases. It can also help a lot with a migration to the GraphQL. One can quickly start with Map-like structure and after some time develop schema generation and caching mechanisms. |
Hello, I agree about this, and as @OlegIlyenko said, JSON string inside JSON string seems awkward. |
+1 |
Hi, I have a use case where I have 'server based schema' and 'client based schema'. The server based schema is pretty much static and will follow normal project/application changes through time. However the client based schema is specific to client side and generated on the fly for exclusive use by the client/user. It's shape is not ideal for a generic map type as it can become deeply hierarchical. What I need to do is store the resulting client side JSON blob against the user on the server side. I specifically do not want any validation or type checking done on this JSON blob server side except for checking for valid JSON. At the moment I'm storing it as stringified JSON against an attribute in server side schema which does not seem ideal. So I'm very much in favor of JSONObject/RawObject/UncheckedObject or whatever as simple JSON object as proposed here: graphql/graphql-js#172. |
It looks like the use case of @miracle2k can be solved by just using a list. So something like:
wherein @clintwood 's use case however looks different since there's no known schema and may be hierarchical. IMO, as long as there's a known structure, a list type could replace a map. |
@jvliwanag correct me if I am wrong, but this would mean that the values in the list would have to return as an array. This is OK if someone is developing an API from scratch and has control over defining the response payload. But if an existing API is being moved over to use GraphQL, which already has a defined contract returning a map of key value pairs (even if the values are always of a defined object type / structure), then it appears this is unavoidable. I am interested to know how it would be possible to use a list, unfortunately the the list type does not seem to accept anything except an array: Interestingly the error:
Suggests it could be possible to supply a |
+1. Maps would be useful in mutations for sending arbitrary key/value pairs. |
+1 as well, imagine this can also allow for embedded documents in query responses if using a record store on the backend? |
Support in the JS library itself for arbitrary iterables rather than just Arrays is coming soon. There are significant tradeoffs to a Map type vs a list of key/value pairs. One issue is paginating over the collection. Lists of values can have clear pagination rules while Maps which often have non-ordered key-value pairs are much more difficult to paginate. Another issue is usage. Most often Map is used within APIs where one field of the value is being indexed, which is in my opinion is an API anti-pattern as indexing is an issue of storage and an issue of client caching but not an issue of transport. This anti-pattern concerns me. While there are some good uses for Maps in APIs, I fear that the common usage will be for these anti-patterns so I'm suggesting proceeding with caution. For the original post, I think there are two good ways to solve this API puzzle: First is what @OlegIlyenko suggests. That you explicitly ask for the languages which you care about fetching. If you need multiple you can use aliases to query for multiple. This may be the right path if you know up front which you want to query.
Second is returning a list of tuples. This may be the right path if you don't know up front which you want, or if you specifically want them all.
such that you might get the result:
|
Please try to use JSON-LD language maps: http://www.w3.org/TR/json-ld/#index-maps |
I agree with @leebyron about the solution to the original problem. In the case of user-defined JSON data, can we just make it clear that custom scalars aren't restricted to how they can be serialized. E.g. with graphql-js you can serialize a custom JSON scalar using arrays, objects, etc. |
alternatively:
result:
You can specify the list of language in a variable Advantage of this approach: |
+1 for map support. This "anti-pattern" logic seems like over-thinking it to me. Sure some people will abuse it but that is true for anything.. |
+1, map support is useful for some situations that the system always return less data than expect, I think. |
+1 Currently I'm dealing with an API that data is arbitrary (as users can create their own contentTypes on the CMS), so there is no way I can create an Update: Just tried this and is working great so far!: https://github.com/taion/graphql-type-json (thank you @taion). |
I have the same use case as @juancabrera. Our API delivers content defined and managed through a custom CMS, and a main feature is being flexible and dynamic. In the application, we model the objects as a base set of common fields, and then a "fields" map with all of the dynamic properties that we don't know about on the server.
We'd like to give our client app devs the ability to query and transform the content in the way they want, but without having to create a strict schema on the server. |
+1 for maps. In my use-case I have objects of this shape (in typescript): interface GenericObject {
id: string,
label: string,
types: string[],
objectProps: {[key: string]: GenericObject[]}
dataProps: {[key: string]}: string[]}
} Using the list of key-values would mean I am doing a transformation on the server to send the data and then do the reverse transformation on the client to build up that map again. Also the size of data we talk about here is rather small. So paging is not an issue. |
We have the exact same need as @jarwol |
I am in agreement with @leebyron after watching what has happened in other "JSON" type apis at my company. The path of least resistance is the path most often traveled. This means that if there is a choice of creating a new type that has more semantic meaning to the UI or creating a map that has no tooling support or contract, but is "quick" to create on the server, then a map is going to be used. |
I would personally opt for 2 seperated types.
This might come across as perhaps anti-pattern, though in my opinion it is not. Since these are 2 completely separated concerns / representations even if the source for both is the same in your db. Thus:
Selected by:
Unified languages type
Plain object
|
We have the same issue as @OlegIlyenko: user defined data types. |
I have a similar use case. Instead of the value of the Map being a simple string, I'd need GraphQL types as I'd like to use field resolvers there. Consider a schema like this:
A response should look like this:
The book category names are dynamic and change often, therefore I'd like to not specify them in the GraphQL response. Note that this is just a contrived example. I'm not looking for a solution to this particular problem. I understand the value of using a list instead, but it would be great to use this to work with clients / server responses that were designed before the GraphQL layer was in place. |
I would like to support ES6 Map construction directly from json. The ES6 Map constructor accepts and array of Entries where the Entry "type" is a two element array where the elements are of different underlying types one for the key and one for the value e.g. [string object]. I can't do this currently in GraphQL. |
@amannn: Even "with clients / server responses that were designed before the GraphQL layer was in place", isn't a schema like the following similarly easy to produce/consume?
The obvious use case for having
|
This issue has been open for a very long time. While I'm still definitely leaning towards Reject for this proposal based on all the concerns above, I'm leaving this as Strawman and Needs Champion in recognition that this issue is not a real proposal and there are only soft suggestions as comments. If anyone is interested in carrying forward a Map type proposal, they should open a pull request with specific implementation recommendation. There is a ton of incidental complexity in all of the suggestions - an RFC proposal must account for all of this complexity. |
Lee Byron, I would like to create a concrete proposal to push this forward. But it is not clear to me what exactly pull request means here. |
@alkismavridis I recommend reading https://github.com/facebook/graphql/blob/master/CONTRIBUTING.md which explains what's expected of an RFC proposal. Any GraphQL library can be a useful testing ground for implementing ideas, however to be accepted a change to GraphQL.js (the reference implementation) is required. |
Hypothetical use case where a Map type could come in handy: Imagine dealing with a What would be the idiomatic GraphQL way to go about this? |
You'd do something like: type Human {
genome: [Gene]
}
type Gene {
name: String
value: String
} i.e. otherwise follow the "list of entries" pattern as above. |
To add to @taion's writings: In Protocol Buffers version 3, there is a handy support for a Map type. This type has an internal representation which follows the above. That is
It somewhat suggests that Map types is an artifact of the Client more than it is an artifact of the GraphQL "wire"-representation. Like the Relay NG specification adds special handling of objects with a "Connection" suffix, one could determine a special set of rules for a "Map" suffix, based on the above scheme. |
+1 for map support. |
+1 my team really really really need this!!! |
If someone is worried about abusing Map type, wouldn't it make much more sense to write a linter for GraphQL which allows you to limit the functionality instead of restricting it by design? |
It would be great if you could use Flow style like:
|
I think the most straight-forward syntax to define the map would be something like that:
|
type User { |
+1
|
I'd also realllllly need this, as im building an api server that serves key-value pairs the client can't know the keys for... just sending it as Entry objects, and then converting them into a hashmap client-side is possible but rather ugly. |
We really need this |
I'm going to lock this issue since it has become non-actionable. For anyone arriving here looking for a Map type, I suggest first reading the comments on this thread about the API design tradeoffs and alternative approaches available. If someone feels strongly that this concept deserves first-class support in GraphQL, then I suggest following the RFC procedure to take this from a general suggestion to an actual proposal. Find more information about that process here https://github.com/facebook/graphql/blob/master/CONTRIBUTING.md |
Should there be a map type?
I have a structure that looks like this:
The point here is that the number of language strings might be arbitrary. I find this hard to model using GraphQLObject, because:
If I make my GraphQL server return a JSON object for "title", the Relay client doesn't complain (although maybe shouldComponentUpdate breaks), but I think I'm skirting by here. At the very least, I think I couldn't generate a schema that confirms to the spec.
The text was updated successfully, but these errors were encountered: