"but then you have to lock all adds and updates on your schema, which is not a good thing" what exactly do you mean with that? that the data added through DQL mutations is not accessable via GraphQL (because of that whole transpilation thing)? or do you mean something different?
My main job is not in IT, but I do have a CS degree and have been programming for over 20 years (only born in 1984). I hate dealing with Servers, and want Graph Databases to be the new norm.
If you create a custom mutation, which is different than using a lambda webhook -- what this article is talking about --, then a person could still add data through add / update unless you prevent them from using the regular graphql endpoint by adding the NEVER / ALWAYS rule above. Basically your regular graphql endpoint is accessible to add / update data without the timestamp, so you must "lock it" from allowing people to add data that way.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
"but then you have to lock all adds and updates on your schema, which is not a good thing" what exactly do you mean with that? that the data added through DQL mutations is not accessable via GraphQL (because of that whole transpilation thing)? or do you mean something different?
If you create a custom mutation, which is different than using a lambda webhook -- what this article is talking about --, then a person could still add data through add / update unless you prevent them from using the regular graphql endpoint by adding the NEVER / ALWAYS rule above. Basically your regular graphql endpoint is accessible to add / update data without the timestamp, so you must "lock it" from allowing people to add data that way.