Support for limiting operations by field

[nadeemc]

Hi!

The goal of this PR is to be able to limit the predicates generated by field.

This was motivated by the fact that some fields, e.g. slug, should have less flexibility on how they are filtered, i.e. slug and slugIn as the only predicates instead of slugNEQ, slugNotIn, etc.

Linted using golangci-lint. Tests updated and passed for using the AllowedOps annotation on the username field.

[nadeemc]

Rebased onto latest changes from main branch. Conflict in schema_relay.graphql resolved and confirmed tests are still passing as well.

[nadeemc]

@a8m Can your provide feedback on what you wanted changed with this PR? I'd like to get those made so this is in a mergable state :)

[nadeemc]

Hi! Pinging this thread to see if there are any additional changes needed?

[nadeemc]

Thanks for the feedback! I'll get those changes made 😄

[nadeemc]

@a8m I've updated this PR with the requested changes. Please let me know if these match your expectations :)

Some notes:

1. I prefixed the values with Ops, i.e. entgql.OpsEQ instead of just entgql.EQ to make it easier to autocomplete when trying to select an ops value for a bitwise operation.
2. There is a mapping between entgql.Ops and entc/gen.Op, with a test function used to ensure the two types are kept in sync. Alternatively, we could move to a shared type between both packages, but I felt it was easier to use the Ops features if they were under the entgql package.

I've updated my project to use these changes and they work as expected. For those wanting to try the same, you can use a go.mod replace directive to try them more easily:

replace entgo.io/contrib => github.com/nadeemc/contrib v0.0.0-20240525181828-ded33d628a61

[nadeemc]

@a8m Please let me know if you'd like any other changes here :)

[nadeemc]

Hi @a8m! Checking in to see if you'd like any other changes before this can be merged.

[nadeemc]

Earlier today, I had an interesting conversation about this PR with a colleague. It is true that:

1. You can limit which entities hare visible in your GraphQL schema with entgql.SkipAll annotations at the table level.

2. You can limit which fields from those tables are visible in the GraphQL schema with entgql.Skip annotations as well.

3. [This PR] You can limit which operations are available on those fields in your GraphQL schema.

However, you really only need to limit available operations on a GraphQL visible field if you are not using persisted queries. When you do use persisted queries, you already have safety guarantees around which operations are valid anyway.

So, this PR practically helps the most with:

A) Non-persisted queries in production (likely a bad idea anyway) B) Limit which operations your developers can use on a field (likely an unnecessary constraint)

As a result, this PR may not be needed. It doesn't hurt, but not sure how much it helps.

[nadeemc]

Hi! Thank you for the earlier review and feedback, but I'm going to close this PR as unneeded. I'd recommend others use persisted queries to tackle this problem and that's the direction I'll be going in as well.