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.

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.

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/

Let's face it, the Realm documentation as a whole is really lacking in comparison to the level of documentation of Atlas and other enterprise-level products. There have even been times I've had to search the old stitch documentation to understand how something works, and many other times I'm left experimenting or abandon a feature completely (for example, I gave up on Environments).

Other places have had success putting documentation on GitHub and allowing community submissions via pull requests.

Please allow the same -- I would happily contribute rather than needing to maintain my own notes (for me and my team) separate from the official documentation.

Currently the API has a hard limit of returning 100 results. For any sort of real diagnostics with the logs, this is pretty much worthless -- with a large quantity of transactions, the only thing I can think of to do would be to write a script to loop through time intervals and aggregate them on my side.

As a real-world scenario, I was trying to identify the full scope of impact of a bug that went out and was not caught for a couple days and ran into the limit. It was also difficult to even identify exactly when the errors started. I ended up having to sample random times and hope that covered enough.

Please remove or greatly increase the limit that we can return more data.

(I agree there should be a relatively small default limit, put please make it over-ridable with the limit parameter.)

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