So there's currently an issue with Partitions where if you have multiple complex relationships, files that need to be in multiple partitions aren't accessible.

Let's say you have a User Object and a Tribe Object.
Each user has a list of tribes they are in, and each tribe has a list of users they are in.

If you partition for each User, and User 1 and User 2 share a tribe, the User 2 partition will be unable to access the tribe.

If you partition for Tribes, and Tribe 1 and Tribe 2 that share a User, one partition will be unable to access that user.

What I would like is to create a realm by querying, much like you can query/filter a user object. So whenever you create a realm, you get exactly the data you need, and nothing more. (much like GraphQL).

MongoDB Realm is perfect for SaaS products but the hard part is always implementing recurring billing for customers, we would need to write and implement a system like this ourself and maintain it which costs time and money or use third party services like Chargebee or Recurly. Firebase already has a nice extension market where you can install the Stripe extension and you are ready to go and charge your Customers monthly, I would like to see the same in MongoDB Realm with Stripe & PayPal & maybe more, best would be as an official product of the MongoDB product family like Charts or Realm are, just call it MongoDB Realm Subscription Payments or something :)

We have a use-case where we need to compare an ObjectId on a document to the ObjectId of the user's custom data doc. However, because the ID of the user's custom data object is returned as a string and not as an ObjectId, there is no way to make this comparison without creating a function just to compare the ObjectId and the string. The overhead of invoking a function just to call toString on the ObjectId is going to be a major problem, especially because we need to make this comparison 5 times for every single operation on our most heavily trafficked collection.

This could be easily solved by what should be a rather simple feature to add, an operator that could be used to compare an ObjectId to a string within JSON expressions.

I think the best justification for this addition is that there are several situations where you simply cannot get an ID in ObjectId form as it is only provided as a string, like the ID on user custom data docs.

There is various documentation for the many Realm/Stitch SDKs but almost no information about the underlying API endpoints, this needs to change and we need some detailed docs for working with the API itself.

I am trying to get an app running with the GraphQL API but have found working with the authentication APIs to handle auth tokens and sessions to be a bit of a nightmare. This page https://docs.mongodb.com/realm/graphql/authenticate/ has some useful information but doesn't even give the endpoints for logging out or explain how to properly handle the email sign up process using API endpoints in place of the SDK. This is particularly important when working in an isomorphic environment like NextJS, which is perfectly doable with plain APIs but currently impossible with the current Node/Browser SDKs.

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.

It would be great to be able to disable a realm without deleting it. Currently, this is possible by unlinking the cluster or exporting the realm and deleting it. Both of which create more work when firing it back up.

It would also be amazing to be able to tie that in with billing alerts. Say I would rather my app crash than pay more than a certain amount because of Realm usage.

In essence, I'm asking for an "always free" Realm that just disables itself when the free tier has been hit so that I can be 100% certain that I wouldn't be charged. The realm wouldn't disappear and could be turned back on either the next month or if I chose to accept the charges for additional resources. This would allow me to gauge my usage in the first few months without the worry of being charged.