8 results found

1. Add GraphQL Subscriptions
   155 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

   19 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
   planned  ·  Sumedha Mehta responded

   Looking for feedback around this feature, please reach out to sumedha.mehta@mongodb.com if you have any.

2. Terraform Provider

   It would be nice to be able to managed Realm Applications via Terraform, similar to how MongoDB Atlas can currently be managed via the mongodb_atlas from Terraform provider.

   12 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

   planned  ·  3 comments  ·  App Services General  ·  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. Support for arrayFilters in Functions

   Can we add arrayFilters and other array update capabilities that already exist in MQL? Its is difficult to update arrays, and very easy to update an array in MQL in node.js for example.

   11 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

   planned  ·  3 comments  ·  Functions  ·  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. Allow manually disabled trigger to resume without resume token

   I am filing a feature request for the option to: Disable a trigger manually and be able to restart it without using a resume token (i.e. such that DB events that occurred while it was disabled will be ignored by the trigger, and it will simply start listening for new events upon restart).

   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

   planned  ·  2 comments  ·  Triggers  ·  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. Application Deployment in GCP

   Currently deployent is only available to AWS but Atlas allows deployment in GCP.
   
   We need to have deployment close to GCP for better performance consideration.

   7 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

   planned  ·  0 comments  ·  Developer Experience  ·  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. Increase RealmReturn Body Max Size

   The maximum return body size of a realm webhook is 4MiB (4194304 bytes). That might seem enough for most applications but when dealing with massive amounts of data, e.g. timeseries data over years, that is a hard limitation.
   It requires the client to make many more requests that would be necessary.

   In our special case we want to return one whole year worth of data per request to make things easier for our clients (currently they can get 3 months).

   Given a 16MB Limit on a MongoDB Collection Document, this would seem like a sensable option for a limit if there has to be one at all.

   The argument, that GraphQL can be used without a limit is not a good one as this is a different means of communication with the API. We are using REST for a reason.
   Switching does not only mean work on our part but also on the clients part.

   The feature requested here in short:
   Increase the maximum return body size from 4MiB to at least 16MB to allow for large payloads to be sent. The argument for that, is that the maximum document size is also 16MB.

   The maximum return body size of a realm webhook is 4MiB (4194304 bytes). That might seem enough for most applications but when dealing with massive amounts of data, e.g. timeseries data over years, that is a hard limitation.
   It requires the client to make many more requests that would be necessary.

   In our special case we want to return one whole year worth of data per request to make things easier for our clients (currently they can get 3 months).

   Given a 16MB Limit on a MongoDB Collection Document, this would seem like a sensable option for a limit if… 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

   2 comments  ·  App Services General  ·  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 Marc – We have a ticket for this that’s near the top of the backlog and plan to increase the limit to 16MB in the near future.

7. 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.

8. Triggers on DB level rather than single collections only

   Change streams support events on DB level or single collections, but triggers are limited to single collections. Which means that if we wanted to listen on changes in a generic way, we would have to setup a trigger for each collection and set them up with AWS EventBridge (and think about new triggers when new collections are generated).

   Given that the underlying tech (change streams) supports DB-level subscriptions, we would really like to see that on the UI, too.

   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

   planned  ·  0 comments  ·  Triggers  ·  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