With respect, this is the most ignorant statement and shows you guys have not read any of my nor @amaster’s posts, nor do you actually understand the use cases of the average developer.
Here are the problems with this statement:
Lambdas
- Lambdas require using an external function in javascript / typescript
- Executing lambdas are not “easy” and take a lot of time to write code that should be built in to graphql for security.
- I can’t even use lambdas in a lot of cases. You guys do not offer a pre-mutation lambda. The post-mutation lambda “web-hook” that you do use is only viable for things like cascade delete and deep mutations (another feature that should be used in graphql, not lambdas).
- The post-mutation option that you offer does not have access to the changed data, so I cannot use a post-mutation to correct mutations I do not want to allow.
- Your argument for not having a pre-mutation is that it slows down the graphql. However, that is exactly what @custom muations do! They run before, which is what I need and should be included!
- For any real security, I have to use a @custom mutation. That means in order to have any real security for EVERY SINGLE mutation (add, delete, update), I have to disable usage on the adds, and create a custom mutation, not for each Type, but for each mutation type for each Type. Insane amounts of code.
- If I have to write a custom mutation for every single real security mutation and type, why do we even have graphql for? I am seriously better off using DQL on my own server. Please read that statement again, if you want us to use lambdas for everything, why do we even have graphql?
- Arguing with @MichelDiz about the usefulness of backend security is ridiculous, although he is the only person who even responds to my posts. You guys don’t seem to be actively developing graphql, which is a problem and will force your customers to find a better product.
- Every single one of your competitors gives you real security options outside of external nodejs functions: Firestore, Supabase, nhost, mongodb atlas, fauna, neo4j aura, neptune, mariadb, hasura cloud, tigergraph cloud, nebula graph, harperdb, couchbase… etc… etc… The list goes on and on. They each have their downfalls as well, but security is not one of them.
Use Cases
- There are two specific use-cases here regarding the user, and another one I spoke about above in your documentation. You guys admitted this is a known security hole.
The Real Use Case and Why this is really important
Right now we can prevent certain certain types of thing from being added, but not changed later. When you add this feature, as I have spoken about in several other posts (including this one), it opens up a plethora of new features as I said at the beginning of this post (that again I assume no one is reading):
- required fields
- not null fields
- field restrictions
- value restrictions
- min, max restraints
- enum restructions
- regex restrictions
- this list goes on and on and on…
This opens the door for security rules. They are needed!
IN SUM
- We are stuck with your graphql. Get rid of it and just be a cloud hosting platform, or start actively developing it.
- Lambdas are NOT EASY and you guys expect us to fix every security problem with them while actively not giving us any pre-mutation lambdas. This forces us to have to write 3 @custom mutations for every single type to have any sort of backend security, rendering graphql pointless.
- Every single one of your competitors has security outside of lambdas functions unless they are just cloud hosting and not a full blown platform.
- I personally would have several more projects with you guys making you more money etc. as well as at least 5 other people I have seen on these forms saying this is a deal breaker. I don’t want to waste my time with something that is not actively repairing its biggest problems, GraphQL. You will lose several clients if you don’t both:
- Actively work on fixing the many limitations with GraphQL (starting with security and basic database features like cascade delete and branching out to features like Nested Fields)
- Let your members know you’re actively working on fixing the many limitations with GraphQL. Are you guys? There is no evidence of this except for old empty promises. I love your product, but this is the truth.
What are you guys? A database as a service, or a full blown platform? The way GraphQL works on your platform with no field security, foreign key constraints, error messages, nested filters, and no sign of improvement, you are just a DBaaS. If that is your goal, then all power to you, get rid of GraphQL.
So yes, please fix this problem. It will give us basic front end security without having to write a custom mutation for every single field for every single type of mutation. Right now, that is ridiculous and the only way to secure your product.
That is my use case.
J