3 results found

1. Please Support CORS from the Data API

   It would be amazing if the Data API supported CORS (via some sort of authentication mechanism in addition to the API key).
   As it stands right now, we'd have to write a proxy API to consume the Data API, which would take about the same amount of coding as creating webhooks on Atlas to modify the collections.

   109 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

   9 comments  ·  Data API / HTTPS Endpoints  ·  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
   completed  ·  AdminKaylee (Admin, MongoDB) responded

   Hi! We are excited to announce that we now support client side access for Data API using Bearer Authentication. You can use the Data API to connect to MongoDB Atlas from any platform that supports HTTPS, including web browsers, and get around CORS errors. Check out our docs page here that goes over how to authenticate Data API requests for web browser access. If you would like to share any additional context on your use case or general feedback regarding this newly released feature, please feel free to email me at kaylee.won@mongodb.com.

2. Add REST API Services

   Add REST Services support analogous the GraphQL.
   Some users on Realm desire a REST API to their clients as
   oppose to a GraphQL API.

   Although this can somewhat be accomplished by adding a HTTP '3rd Party Service' and query the mongo collections, you don't get all Rules, Schema, and other useful tools and services which are provided with the GraphQL option.

   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

   0 comments  ·  Data API / HTTPS Endpoints  ·  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
   completed  ·  Sumedha Mehta responded

   Check out the Atlas Data API https://www.mongodb.com/docs/atlas/api/data-api/

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

   completed  ·  2 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