I've moved from Firebase because of the lack of support for React-Native and I've just discovered that I need to use Firebase to receive Push Notifications from my App. I'm aware of the complexity of adding this layer to SDKs, but you're already much ahead of Firebase in terms of SDK maintenance and support, being able to make a full app's stack would be wonderful for many, I think.

Logs can only be filtered by type, user and timestamps. Would be very useful to filter by function name

We need the following enhancements
1. Need more than 80 characters
2. Need ability to turn it on and off by level (Log4J)
3. Need ability to turn to higher level of logging on a single call

It would be nice to use webhook path to pass payload to the webhook for example:
/api/mypath/{deviceId}/data

Instead of
/api/mypath/data?deviceId={deviceId}

Currently, you only support Google and Facebook for social logins. Can Twitter also be added?

We would like to expose the APIs created directly to our clients. But we would like them to utilize a domain from our company. At this time we are going to use AWS API Gateway as a reverse proxy.

But all we really would need is the ability to host our ssl cert that corresponds to our domain

I want to port my application but I can't port all my old users.

It would be great to add security to requests by being able to respect the relevant Atlas project peering and IP Whitelisting to reach Functions.

We need the ability to be able to accept new releases, similarly to how you push updates to clusters so we can 1)be aware and test new releases in test environments 2)schedule updates for least disruptive periods.

In writing any app, there are likely to be multiple Functions stored. A developer should have the ability to search for specific snippets or text elements across all Functions.

It would be really awesome to be able to roll back deployments to a previous or a specific version.

Currently, the app urls are extremely long and unreadable, for example: https://realm.mongodb.com/groups/5ab028594e6581148629dc65/apps/5b28f4615fdce07a74cd7f50/triggers/5bcf226fe707c05350750dcc
This looks pretty ugly. It would be a lot more user friendly to:
- eliminate the /groups/<groupID>/ portion of the URL entirely - the app ID already uniquely identifies the group anyway
- use the clientAppID instead of the raw objectID for /apps/<appID>.
For example, the above URL could instead be represented as
https://realm.mongodb.com/apps/my-app-xyz/triggers/5bcf226fe707c05350750dcc
with no loss of functionality or precision