GraphQL Field Alias Spec Compliance

Reference: GraphQL

Currently Realm GraphQL only allows field aliases on top level queries, and not on keys. An error will get returned stating:

"message": "runtime error: slice bounds out of range [-1:]"

Are there any plans on compliance with this GraphQL specification? It would be very much appreciated.

2 Likes

Can I get an official response on this? A lot of the tooling that we use at the agency I work with have fully compliant GraphQL specs which are causing errors when queries are being sent to the Realm GraphQL service. Thanks.

Hey @Andrew_Edgar - I’m sorry for such a late response. This isn’t an available feature at the moment - can you provide more insight into why you want to use @alias and the general need for full GraphQL compliance? While this isn’t on our roadmap right now, Adding it here would help us gauge interest - Realm: Realm GraphQL (19 ideas) – MongoDB Feedback Engine

1 Like

Field aliasing is an integral feature of the GraphQL spec with very clear use cases documented elsewhere – https://graphql.org/learn/queries/#aliases – I would argue not being able to use it limits the usage of the GraphQL API in a myriad of situations.

1 Like

As @Nikolaj_Selvik stated field aliasing is integral and the spec compliance has nested aliasing. Many tools/libraries for various language and frameworks are compliant with GraphQL specs which therefore makes them unable to work with MongoDB Realm GraphQL. Realm GraphQL is a great time saver but it would be much more useful if it was fully spec compliant.

If you desire further specifics - something like https://github.com/dillonkearns/elm-graphql is incapable of working with MongoDB Realm GraphQL because it utilizes nested field aliases when generating type-safe code for interacting with GraphQL schema. Dillon Kearns package uses GraphQL specification.

Spec compliance shouldn’t be a feature request, it should be available out the box to assure there aren’t unnecessary hinderances for anyone naturally expecting spec compliance. It would strengthen use cases.

Frankly I am shocked that this feature is not included. The idea that any large project would not need to transform / map names on some data in this case via the use of an alias seems extremely short sighted. In my 20 years of working in hundreds of projects I have never seen or heard of a project that did not need some kind of mapping. In an ideal world we would all follow some common naming schema, reducing the bureaucracy and sending many programmers to the unemployment office. Fortunately we don’t live such a technocratic utopia, and the people consuming that data can’t seem to agree, hence the need to change name here and there.