Lambda Mutation for Every Mutation
I should add that near complete security is possible with Dgraph Cloud (with the exception of limiting the number of queries and RBAC in the DB).
However, you basically have to ONLY use custom lambda mutations for every single add or update mutation. You have to block out all regular mutations like in this post:
Firebase Function?
You could also technically use a Firebase Function to do all of your mutations (only if you use Firebase Authentication for your JWT). Queries need to be fast, not necessarily your mutation (depending on your own app’s philosophy). While this seems like a bad idea because you’re running cold start functions on an external server, they are actually pretty quick and really easy to implement and test.
It is worth noting that anyone who takes this method seriously would have to run a separate graphql query immediately after each mutation in order to keep the other graphql cache up-to-date. Here is the URQL version, although Apollo has something similar:
client.query(
query,
{ /* variables */ },
{ requestPolicy: 'network-only' },
).toPromise();
I have also written something like this in my easy-dgraph package.
If you don’t use graphql to update the mutation, your graphql client will not have an updated cache and will get the wrong results unless there is a refresh. Even custom mutations allow you to return the query for a reason. You could also technically just do a cache-update manually returning the query from the Firebase function, if Dgraph ever charges per query.
Answer
So, to answer your question, no. Lambdas do not have any test sweets like Firebase Functions do. You could, however, compile the lambdas on your frontend from typescript, and do unit tests on a separate test-database (which you should have anyway). You can’t add any external modules though, but for simple stuff, this is recommended.
Just having @auth for basic front end queries is pretty awesome, even though it is very limited. It is just not sufficient for any mutations or some cases with queries. This is a huge step in the right direction from other products.
So, please stick with Dgraph. I have done my research. There is no other graphdb that does everything out-of-the-box for a good price. There always seems to be a third-party module in most cases just to use it on the front-end, there is an extreme price, AND (not OR here), there is insufficient documentation with a high learning curve. If you don’t need a graphdb, there ARE better options. I think every database should be a graphdb, but that is just me.
I believe the main thread of these problems will be fixed in the next year, but you can work with it now just fine. I would develop without the backend security, and add the lambdas or firebase functions last.
J