chore(docs): gqlorm auth implementation plan (not)#1783
Conversation
✅ Deploy Preview for cedarjs ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
Greptile SummaryThis PR adds an AI-generated planning document (
Confidence Score: 4/5Docs-only change; no runtime behavior is affected and the project overview remains accurate, but the plan itself contains factual gaps that future implementers should be aware of before treating it as a reliable reference. The change is purely a documentation addition with no code modifications. The three factual issues found are all in the planning document itself — anyone using the plan as a spec without cross-checking the real code could introduce bugs, but merging this file as a reference artifact carries no direct runtime risk. docs/implementation-plans/gqlorm-auth-scoping-implementation-plan.md — three sections describe current or proposed behavior that doesn't quite match the actual codebase Important Files Changed
Reviews (1): Last reviewed commit: "chore(docs): gqlorm auth implementation ..." | Re-trigger Greptile |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
|
|
||
| 1. **Per-model scoping is the right abstraction** | ||
| - The current implementation already reasons per model during codegen. | ||
| - Replacing hard-coded convention branches with per-model scope providers |
There was a problem hiding this comment.
The plan states the frontend "generates GraphQL query documents" with a plural field for findMany, implying the generated field names align with the backend. They don't — packages/gqlorm/src/generator/graphqlGenerator.ts uses naive ${model}s (append-s) pluralization, and even has a // TODO: Use Cedar's pluralization function comment acknowledging the gap. The backend codegen uses pluralize(camelName) from @cedarjs/utils/cedarPluralize. For any model with an irregular plural (Person → people, Category → categories), the frontend would query a field that doesn't exist in the generated backend schema. This divergence is directly relevant to Stages 1–2, which assume the frontend and backend field names are already aligned.
| - add tests for `defineGqlormAuth`, merge helpers, and scope result semantics | ||
|
|
||
| #### `packages/internal/src/generate/gqlormSchema.ts` | ||
|
|
||
| - add auth config file detection | ||
| - refactor current auth emission logic |
There was a problem hiding this comment.
GqlormDb interface doesn't include findFirst for scoped non-membership models
The plan recommends using findFirst internally for all scoped singular queries (to merge id lookup with an auth where clause). However, the current generateGqlormBackendContent in gqlormSchema.ts only adds findFirst to the GqlormDb interface for the membership model when anyModelNeedsOrgScoping is true — not for the other models being scoped. Implementing item 7 without also updating the interface-generation loop would produce TypeScript errors in the generated backend.ts for any scoped model that tries to call db.<model>.findFirst(…).
|
|
||
| - `where` | ||
| - `orderBy` | ||
| - `first` | ||
| - `skip` | ||
|
|
||
| for singular and plural operations. | ||
|
|
There was a problem hiding this comment.
first: Int should be take: Int to match frontend query builder conventions
The proposed Stage 2 plural field shape uses first: Int as the limit argument, but the frontend QueryBuilder / FindManyArgs uses Prisma's take convention throughout. If the generated backend SDL exposes a first argument and the frontend generator sends take, the limit will be silently ignored on every paginated query. The arg should be take: Int (or the frontend generator updated in the same stage to emit first) so both sides agree.
1 participant
AI slop vomit. Just wanted to keep this here for AI to reference later