29 results found

1. Add GraphQL Subscriptions
   163 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   20 comments  ·  GraphQL API  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close
   under review  ·  AdminKaylee (Admin, MongoDB) responded

   Please send any feedback to kaylee.won@mongodb.com going forward – this feature is under review, so we would love to hear from you. Thanks!

2. Pagination in GraphQL

   We have slicing via limit: INT, but we do not have the ability to specify an offset. Are there plans to add this soon?
   GraphQL Documentation actually specifies their pagination terms as follows:
   first: int
   offset: int
   after: _id
   Are there plans to implement this at all?

   88 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   11 comments  ·  GraphQL API  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

3. Adding or removing elements from array fields

   It would be helpful to support array add/remove in update mutations. I've been running into this most often when dealing with one-to-many relationships.

   For example, adding/removing books from an author. Currently, you would have to fetch the entire array of books to add or remove the book linked to the author. If I could supply the foreign key to add/remove from the relationship that would be fantastic.

   36 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   1 comment  ·  GraphQL API  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

4. Custom GraphQL Schema for MongoDB Realm

   Dear MongoDb GraphQl Stitch developers,

   Is it possible to add an ability to modify the final GraphQl schema (in order to remove unnecessary for my API stuff)
   OR
   Build it based on existed roles?

   For example, Im building a "read only" GraphQl API and have NO roles that can actually modify the data. So I find it illogically to have mutations in the Final GraphQl schema.

   It would be great to have an ability to choose which exactly mutations/queries I need for my GraphQl.

   Thank you.

   24 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   3 comments  ·  GraphQL API  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

5. Allow deeper relationships under Rules

   I really like being able to use GraphQL and how you can auto generate a schema but when trying to relate fields I noticed it would only let me relate top level fields.

   For example - we have "accounts" and "users" under accounts with user Id on a related object. But I cannot do related userId back to account.user.userid since user is an object. I was hoping after I generated a schema for all the collection I would be able to drill down deeper but no such luck.

   •  

   20 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  GraphQL API  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

6. Add federated graph support

   Unable to upload apollo federation dependency on the beta version of MongoDB Realm, it would be great if that dependency would be supported soon.

   FYR: https://www.npmjs.com/package/@apollo/federation

   14 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  GraphQL API  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

7. Support relationships for fields inside arrays of embedded objects in GraphQL

   Currently, as explained in the App Services documentation, the "GraphQL API does not currently support relationships for fields inside arrays of embedded objects. You can use a custom resolver to manually look up and resolve embedded object array relationships."

   There is a contradiction with this other documentation that explains it's possible: https://www.mongodb.com/docs/atlas/app-services/schemas/relationships/#embedded-object-within-a-list

   But it's not possible.

   For example, with this schema:

   {
     "title": "Person",
     "properties": {
       "_id": { "bsonType": "objectId" },
       "pets": {
         "bsonType":"array",
         "items": {
           "title":"PersonPet",
           "bsonType": "object",
           "properties": {
             "favoriteToyBrand": { "bsonType": "objectId" }
           }
         }
       }
      // ...additional model properties
     }
   }
   

   and this relationship:

   {
     "pets.[].favoriteToyBrand": {
       "ref": "#/relationship/mongodb-atlas/example/ToyBrand",
       "foreign_key": "_id",
       "is_list": false
     }
   }
   

   ... the generated GraphQL schema will be:

   type PersonPet {
     favoriteToyBrand: String
     // ...additional model properties
   }
   

   Please note that the type of the favoriteToyBrand is String instead of ToyBrand.

   Therefore, you cannot do something like favoriteToyBrand.name in your code.

   I've contacted the Altas Pro support team. Here is their message: "We do have an internal ticket that is tracking this improvement, however we do not have an estimated timeframe when it will be implemented.".

   Currently, as explained in the App Services documentation, the "GraphQL API does not currently support relationships for fields inside arrays of embedded objects. You can use a custom resolver to manually look up and resolve embedded object array relationships."

   There is a contradiction with this other documentation that explains it's possible: https://www.mongodb.com/docs/atlas/app-services/schemas/relationships/#embedded-object-within-a-list

   But it's not possible.

   For example, with this schema:

   {
     "title": "Person",
     "properties": {
       "_id": { "bsonType": "objectId" },
       "pets": {
         "bsonType":"array",
         "items": {
           "title":"PersonPet",
           "bsonType": "object",
           "properties": {
             "favoriteToyBrand": { "bsonType": "objectId" }
           }
         }
       }
      // ...additional model properties
     }
   }
   

   and this relationship:

   {
     "pets.[].favoriteToyBrand":

   … more
   10 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  GraphQL API  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

8. Single schema of truth: JSON Schema / Realm Schema / GraphQL Schema / TypeScript Types

   I think the current recommended initial prototyping workflow for a Realm web SDK user is like this:

   1) Add first data in collection (manually, on Compass etc.)
   2) Generate JSON Schema (manually click a button on web UI)
   3) Set up relationship (manually, on web UI)
   4) Download GraphQL Schema (manually click a button on web UI)
   5) Get TypeScript types and React hooks (automatically generated by graphql-codegen CLI)
   6) If you use another Realm SDK somewhere else (ex. Node.js sdk for server side), write Realm Schema (manually)

   This is not very developer friendly, and requires back-and-forth work between CLI, browser, VSCode, and Compass etc. It is not a one-time operation; you need to repeat it whenever you change your model structures, which frequently happens when you prototype.

   What I think the ideal way is AWS Amplify's one. In Amplify, you just:
   1) Write (a part of) GraphQL schema on editor
   2) Run a CLI command to apply

   Although I noticed pro/cons, it feels like Realm is going with data-first approach. If we can use schema-first approach too, it will be more wonderful. It will be great to have a single source of schema.

   At this moment, it seems developers are required to manually check all the schema are aligned and the same, if I understand correctly.

   PS. I also checked if I can use mongoose ORM. It seems it also requires another schema of its own.

   I think the current recommended initial prototyping workflow for a Realm web SDK user is like this:

   1) Add first data in collection (manually, on Compass etc.)
   2) Generate JSON Schema (manually click a button on web UI)
   3) Set up relationship (manually, on web UI)
   4) Download GraphQL Schema (manually click a button on web UI)
   5) Get TypeScript types and React hooks (automatically generated by graphql-codegen CLI)
   6) If you use another Realm SDK somewhere else (ex. Node.js sdk for server side), write Realm Schema (manually)

   This is not very developer friendly, and requires back-and-forth work between CLI,… more

   8 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   6 comments  ·  GraphQL API  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

9. Array types in generated GraphQL schema should follow JSON schema of a collection or custom type

   Hello!

   Realm generates GraphQL schema that does not reflect the exact JSON schema of a collection or custom type when it comes to array fields. Generated GraphQL schema allow arrays to contain NULLs even if this is not stated in JSON schema.

   For example, please see collection schema in the attachment. (Not able to insert JSON here in a readable manner)

   For this schema, I expect Realm to generate following GraphQL type for my collection:
   
type MyCollection {
_id: ObjectId!
arrField: [String!]!
}

   Please note the exclamation sign inside the square brackets. This states that the array item can only be a string, no nulls or other types are allowed - exactly what is defined in JSON schema above.

   But instead, Realm generates following:
   
type MyCollection {
_id: ObjectId!
arrField: [String]!
}

   So, it makes array element nullable, which looks like a bug and results in typecheck issues in client apps that are using generated GraphQL schema.

   Related topic on forum: https://developer.mongodb.com/community/forums/t/graphql-schema-wrongly-allows-nullable-values-as-array-items/106005

   I think this behavior is confirmed to be a bug there. Would be very nice to have it fixed or at least have an explicit way to make array elements not nullable.

   Hello!

   Realm generates GraphQL schema that does not reflect the exact JSON schema of a collection or custom type when it comes to array fields. Generated GraphQL schema allow arrays to contain NULLs even if this is not stated in JSON schema.

   For example, please see collection schema in the attachment. (Not able to insert JSON here in a readable manner)

   For this schema, I expect Realm to generate following GraphQL type for my collection:
   
type MyCollection {
_id: ObjectId!
arrField: [String!]!
}

   Please note the exclamation sign inside the square brackets. This states that the array item can only… more

   •  

   6 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   1 comment  ·  GraphQL API  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

10. Allow editing of the generated GraphQL schema and resolver

    The data model that I want to expose to the user is not the one that I have in MongoDB, having this feature would be nice

    5 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  GraphQL API  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

11. GraphQL in Realm Functions

    It would be useful to have an integrated GraphQL client that is authenticated against the cluster available in Realm functions, to create stored queries and modify these in postprocessing in a Realm function.

    5 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  GraphQL API  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

12. Default value for fields

    A way to set default value to a field, when this is not given in the input.

    GraphQl already has this functionality..

    5 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  GraphQL API  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

13. Ability to Reuse Types in Custom Resolver Schemas

    We are in the process of migrating from a hand-implemented Apollo server to Mongo Realm, but are finding the inability to reuse types on custom resolvers to be a serious impediment.

    For example, we have a number of custom resolvers that use the same type to define a temporal interval, but we cannot reuse that type in the arguments for our custom resolvers as Stitch will throw an error upon encountering those duplicated types. Additionally, many of these custom resolvers return the exact same type, but if we try to reuse that same type definition Stitch will throw errors about duplicate types.

    If implemented, this feature would probably look something like having a new tab on the 'GraphQL' page of Realm, or having a richer interface under the 'Schema' tab that allows for the definition of types that don't belong to a specific collection/custom resolver. There would additionally need to be a way to reference these types in the schema definitions for custom resolvers, something that I understand could present a major technical/UX challenge given the way that system currently works.

    As a simpler way of achieving this functionality, if Stitch better understood how to handle duplicate types when stitching together the final GraphQL schema then types could simply be fully redefined everywhere they are needed. This would be far from DRY and overall sub-optimal, but would be a good stop-gap measure on the way towards a more flexible and powerful solution.

    We are in the process of migrating from a hand-implemented Apollo server to Mongo Realm, but are finding the inability to reuse types on custom resolvers to be a serious impediment.

    For example, we have a number of custom resolvers that use the same type to define a temporal interval, but we cannot reuse that type in the arguments for our custom resolvers as Stitch will throw an error upon encountering those duplicated types. Additionally, many of these custom resolvers return the exact same type, but if we try to reuse that same type definition Stitch will throw errors about… more

    5 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    1 comment  ·  GraphQL API  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close
    planned  ·  Drew responded

    Hi Folks – This improvement is already planned and should be completed shortly.

14. Allow one-to-many relationships in Realm GraphQL

    Two collections A & B. One field say _id of collection A is the "foreign key" for a field say "field1" in collection B.

    A: {_id:1, k1:v1, k2:v2}

    B: {f1:1, x1:y1} //Values of field f1 correspond to values of _id in A
    B: {f1:1, x1:y2}

    For one value of _id in A, there can be multiple corresponding documents in B. If we create a relationship currently in Realm GraphQL, only one document is fetched. The expected result set is 2 documents.

    The current cumbersome workaround is to add an array field in collection A with all corresponding document IDs from collection B. This is not intuitive.

    A simple approach to this without GraphQL is a $lookup between the two collections.

    One to many is a common design pattern and exists in our sample_mflix database where documents from collection Comments relate to documents from the collection Movies.

    Two collections A & B. One field say _id of collection A is the "foreign key" for a field say "field1" in collection B.

    A: {_id:1, k1:v1, k2:v2}

    B: {f1:1, x1:y1} //Values of field f1 correspond to values of _id in A
    B: {f1:1, x1:y2}

    For one value of _id in A, there can be multiple corresponding documents in B. If we create a relationship currently in Realm GraphQL, only one document is fetched. The expected result set is 2 documents.

    The current cumbersome workaround is to add an array field in collection A with all corresponding document IDs from… more

    4 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  GraphQL API  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

15. Support for updating nested fields in GraphQL mutations

    I want to do the equivalent of {$set: {"details.pm_stage": "...."}}

    export const UPDATEPROJECTDETAILS = gql
mutation UpdateProjectDetails($query: PsprojectQueryInput!, $pmStage: String!) {
updateOnePsproject(query: $query, set: {details: {pm_stage: $pmStage}}) {
_id
}
}
;

    right now the whole "details" subdocument gets overridden

    4 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  GraphQL API  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

16. Support for JSON schema oneOf / anyOf / allOf

    In our current project we have the requirement to support slightly differently shaped documents, contained within in the same collection, that are identified by an enumerated "type" field. In order to do this we require the ability to make use of the oneOf / anyOf / allOf polymorphic features of the JSON schema which would then ideally be relflected in the MongoDB Realm GraphQL endpoint. I was informed that this was being looked at a while ago but can see no associated feature request.

    3 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  GraphQL API  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

17. Custom Query Filters

    While you can create custom resolvers for 3rd party data or functions, this doesnt help me use graphQL to search existing types. I want to be able to query an existing type based on a contains. I know that this is a complex issue, but if we could create a custom query filter like we do for in, gt, lt, etc, I think this would help make the graphQL API more usable.

    Currently, we are reduced to either using the limited query abilities, or recreate everything from scratch.

    For instance:

    I have a query currently:
    
query {
authorizationGroup(query: { name: "exactValue" }) {
_id
description
name
permissions
}
}


    With this, I can ONLY search exact values. But if we could create custom Query Inputs, I think it would make the GraphQL query much more usable:

    query {
      authorizationGroup(query: { name_contains: "part*" }) {
                    _id
            description
            name
            permissions
      }
    }
    

    Then you can implement a function to process this as needed.

    While you can create custom resolvers for 3rd party data or functions, this doesnt help me use graphQL to search existing types. I want to be able to query an existing type based on a contains. I know that this is a complex issue, but if we could create a custom query filter like we do for in, gt, lt, etc, I think this would help make the graphQL API more usable.

    Currently, we are reduced to either using the limited query abilities, or recreate everything from scratch.

    For instance:

    I have a query currently:
    
query {
authorizationGroup(query: { name:… more

    3 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    1 comment  ·  GraphQL API  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

18. GraphiQL Description field

    I would like to add descriptions to improve the documentation of my GraphQL queries. When browsing the API through GraphiQL, all types and queries say "No description", so one could figure that this would be able to edit, but it's currently not possible (https://developer.mongodb.com/community/forums/t/add-description-to-custom-resolver/14227).

    It would be nice to have the possibility to add a "description" key in a custom resolver JSON schema, like suggested in the post above.

    3 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  GraphQL API  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

19. Able to overwrite default value of Limit in GraphQL Query

    In Realm GraphQL Query there are default value of Limit set to 100 and it is not changeable. It would be good to be able to overwrite default value

    2 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  GraphQL API  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

20. Retain GraphQL Query History

    The GraphQL feature has a history list while you stay on the page. It would be a great improvement if it maintained that history even if you navigated away and came back.

    2 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  GraphQL API  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close