Returning to explore dgraph, a few questions

Last time I checked on dgraph was around v1.04. Back then I had an issue with how ID generation was used and that it was limited to int64 and that this sequence was used and increased for all operations on this dgraph database. The answer was I didn’t do the math and that it’s big enough. I still disagree. It might be enough for small to mid scale but not huge scale (thinking 1 million operations per day).
I know, don’t fixate yourself on this issue, I can already see you trying to “fight” this. Don’t. An int64 sequence for all operations is not large enough.
MongoDB has ObjectID, which you’re probably familliar with, a time and machine id based sequence.
Was anything done in regards of ID generation?

I read GraphQL is now natively supported. Good job. I’ll spare you the discussion about it’s usefulness.

What means are there to protect your endpoint from create, update and delete operations?

I read that there’s an enterprise feature about ACL. I’m not an enterprise, I can’t afford those prices.
What are my options to protect my endpoints?
Can I, for instance, use GET queries for queries and POST queries for mutations?
Or let’s rephrase that, is there anything to distinguish queries from mutations via the HTTP API?

1 Like

Hi @dalu,

We have some ways to secure the endpoint in the community version.

  1. For schema protection, you could use auth token while deploying (https://dgraph.io/docs/deploy/#securing-alter-operations)
  2. GraphQL admin endpoint also can be secured using auth token (Authentication for admin endpoints)
  3. For queries and mutation protection in graphql you can use @auth directive (https://graphql.dgraph.io/doc/authorization/)
2 Likes