Feature Request Standardize Declarative Authorization and Validation via Pothos Plugins

[h30s]

Is your feature request related to a problem? Please describe.

Currently, almost every GraphQL resolver manually handles authentication, authorization, and input validation within the resolve function (e.g., createUser.ts, allUsers.ts). This results in significant code duplication (15-30 lines of boilerplate per file), makes security audits difficult, and increases the risk of forgetting a critical auth check in new fields.

Describe the solution you'd like

I'd like to implement a declarative approach using Pothos plugins (AuthPlugin and a validation plugin like @pothos/plugin-zod). This would move auth and validation logic out of the resolver body and into the field definition.
Benefits:

• Secure by default: Permissions are explicit and verified at the schema level.
• Cleaner code: Resolvers focus only on business logic/database operations.
• Self-documenting: Required roles and validation rules become visible via schema introspection.

Describe alternatives you've considered

• Continuing with imperative logic: High maintenance overhead and prone to human error.
• Custom wrapper functions: While possible, using native Pothos plugins is more idiomatic, type-safe, and provides better integration with the GraphQL lifecycle.

Approach to be followed (optional)

1. Enable AuthPlugin and ValidationPlugin in src/graphql/builder.ts.
2. Map ctx.currentClient roles (e.g., administrator) to named auth scopes.
3. Configure global error mapping to ensure validation/auth failures still throw TalawaGraphQLError with the correct extension codes.
4. Incrementally refactor existing resolvers to use these declarative options.

Additional context

This architectural shift would align the API with modern GraphQL best practices and significantly improve the developer experience for contributors.

[h30s]

@palisadoes What are your thoughts on it?

[palisadoes]

1. The package isn't supported by an organization. It's the repo of an individual. I'm concerned that support could be withdrawn unexpectedly.
2. Are there other approaches?

[h30s]

Hmmm @palisadoes, dependency risk is definitely worth considering. Here are some alternative approaches that don't rely on third-party plugins:

1. Lightweight wrapper utility (no new dependencies)
Create a shared higher-order function like withAuth(role, resolver) that wraps resolvers with the auth/validation boilerplate. This keeps everything in-house and achieves most of the deduplication benefit.

// Example usage
resolve: withAuth("administrator", async (parsedArgs, ctx) => {
  // only business logic here
})

2. Use Pothos's built-in AuthScopePlugin (already part of @pothos/core) Pothos ships @pothos/plugin-scope-auth which is maintained by the same author as the core library (@pothos/core) that the project already depends on. Since the project is already committed to Pothos as its schema builder, this plugin carries no additional maintainer risk. Validation can still be handled via the in-house wrapper approach.

3. Middleware-style approach using Pothos's SchemaBuilder hooks Pothos supports field-level middleware through its plugin system. We could write a small internal plugin that reads custom field options (like requiresAuth: true) and automatically injects the auth checks — no external packages needed.

I'd recommend option 2 for auth (since we already trust the Pothos ecosystem) combined with option 1 for validation (keeping Zod validation in a shared utility). This gives us the security benefits without adding any risky dependencies. Happy to prototype either approach.

[palisadoes]

OK proceed.

[h30s]

@palisadoes I’d like to work on this issue.

Proposed approach:

• Integrate @pothos/plugin-scope-auth in builder.ts

• Map ctx.currentClient roles to auth scopes

• Implement a lightweight in-house validation wrapper

• Refactor 1–2 resolvers as a proof of concept first

If this plan looks good, could you please assign this issue to me?

[palisadoes]

@meetulr
@DMills27
@noman2002

PTAL