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.

It would make a lot of sense to me if one could configure a Realm app to use a collection in the Atlas Cluster to store users instead of having a separate users database managed outside of Atlas, as the case is today.

To avoid a breaking change, this could be implemented as an option to how users are managed today.

This would solve most user-related feature requests and issues, as it would give the app developer full control of the user DB to do whatever queries or customization they want to. Maybe call the option "advanced" or such—more manual labor, more control, for those who want that. I'd even be fine if all auth methods except JWT were disabled when the "Store users in Atlas collection" option is enabled if that helps the implementation.

I get that if someone makes incompatible changes, it could break the auth and access system, but that almost goes without saying, and I think that would be an acceptable compromise.

In my use case, we have an app (https://bikerider.app/) running Atlas with a separate custom GraphQL node server, and I was looking at Realm Cloud to simplify our backend (e.g., the goal would be to replace our node servers with Realm Cloud). That said, we already have a user collection, so with how Realm Cloud is working, I am going to see if I can use our existing users' collection as "custom user data" and use JWT for auth since we already have a custom auth system. But there may be issues with IDs etc. Since we already have relationships between different users and other entities (ex cycling events) based on our existing user IDs and Realm Cloud will create new user IDs. Not 100% sure about this yet, I will need to explore more and see if it can be mapped somehow, but I believe it would help a lot if I could say which collection to use for Realm users.

Related to (would be solved as part of this feature):

https://feedback.mongodb.com/forums/923521-realm/suggestions/42924606-export-import-users-in-realm-app

https://feedback.mongodb.com/forums/923521-realm/suggestions/40550683-importing-users-in-bulk

https://feedback.mongodb.com/forums/923521-realm/suggestions/40550650-ability-to-change-update-email-address-of-applicat

https://feedback.mongodb.com/forums/923521-realm/suggestions/41390221-search-users-by-email

https://feedback.mongodb.com/forums/923521-realm/suggestions/40476781-more-flexible-custom-user-data-user-linking

And so on.

https://feedback.mongodb.com/forums/923521-realm?category_id=388675&query=user

You could actually increase the awesomeness of MongoRealm, when you support multiple partition keys on one object.

Example:
We have a collection of customers in MongoDB, our App is showing the customer information to the users, but only for those users, that are "allowed" to see the customers. So the customer object has a partition key holding the userName it is assigned to:

customer { _id: "12345", partition: "bob", name: "MongoDB Inc."}
customer { _id: "12346", partition: "alice", name: "Microsoft"}

now we want, that alice also sees the customer "MongoDB Inc." in the App.

The solution could look something like that:

customer { _id: "12345", partition: ["bob","alice"], name: "MongoDB Inc."}
customer { _id: "12346", partition: "alice", name: "Microsoft"}

So that object with id "12345" will be distributed in the realm for alice and also in the realm for bob. MongoRealm will take care of all the nifty synchronization stuff.

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.

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.

Advanced Nodejs/React/Vue/Angular Developers have tried Strapi for sure once or at least heard of it. It is a headless-cms/graphical UI for building APIs, The first thing that came into my mind when I tried Stitch + the new GraphQL feature was, Nice product but the UI Strapi gives you for creating Schemas/Data is something MongoDB needs in thair Stitch App to take off since nobody does this currently.

So my suggestion for Stitch is to have a Strapi like UI so we don't need to write Schemas manually, I'm sure this product will take off since everyone I talked to would use it over the current Stitch!

MongoDB is a big Company so why not maybe talk to the guys of Strapi, it is OpenSource so MongoDB could have a managed solution for it like Stitch and also people can host it on their own as we can with MongoDB, but like I said most people will choose ATLAS because it's managed by professionals. The best would, of course, be to acquire Strapi + Team but this is something MongoDB needs to decide.

For those not familiar with Strapi I suggest trying it and imagine having the possibility to build Strapi Apps in MongoDB ALTAS, it will be for sure an amazing experience.

Strapi: http://strapi.io/