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/

Using Realm as an authentication service and a separate backend that then allows the user to connect to separate external APIs, I need to be able to verify that the user is an authenticated user and that their data (only email in this case) match those of the third party external API.

The request to the third party API runs via admin API channels so it's critical to ensure the user is only able to manipulate their own data (orders, subscriptions etc).

As far as I've been told there is no way to verify a user that logged into my frontend if the request has to go via my backend API.

Firebase Admin SDK provides exactly this method here: https://firebase.google.com/docs/auth/admin/verify-id-tokens

To fit into a modern jamstack where multiple external services are tied together, Realm needs something similar.

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.

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.