Local development tooling
Similar to AWS SAM (https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-sam-cli-using-invoke.html) or Google Cloud Functions Framework (https://cloud.google.com/functions/docs/functions-framework).
I.e. the ability to run functions locally. It's expensive and slow to have to run and test code in a project remotely all the time even for small changes.
+1 this needs to be a thing, for realz
This is also crucial for us, especially for the development of lambda functions. That's why we have moved part of our Realm app logic to Azure (API, Azure Functions, etc.). We had a call with one of the MongoDB architects and product owners, and they advised us also to move to another provider for everything else than Atlas (database and Sync engine are great!).
MongoDB, do you have an ETA for this feature? What is the priority?
This is crucial to consider app service for a real project and not just a demo app.
For me, this is a deal breaker for using App Services.
This should be as easy as running "netlify dev"
+1 Want to test my trigger locally
+1 please!.... developers are not the enemy, we need tools!
+1 The number one reason I keep choosing to not use MongoDB Realm to build my apps is the lack of local tooling. I cringe at the idea of coding and testing functions remotely via the browser. Once Realm catches up with the rest of the world on this feature I'll gladly use it for my projects.
+1 Realm is not a developer friendly environment
I have some calculation intensive functions I've been trying to test and it has been painful trying to optimise them for performance. Not being able to see the logs until the function finishes is frustrating, especially if the function then errors and I don't get to see any of the logs! Maybe someone would like to write an extension for VS code that simulates the MongoDB Realm environment?
Matt Price commented
+ 1 for this. Testing and developing functions is a real time killer. We've also found that once you deploy a function, it takes time to propagate so multiple calls to the function are required to see the change.
Not only for functions, but also please consider local tooling for graphql.
AWS Amplify has a local development feature which is really useful. Just run a simple command `amplify mock api` then you get a locally running graphql endpoint. It really speeds up both development and testing.