Migrate GraphQL enums and relationships to TypeScript

[sandy4242]

• Created shared constants in constants.ts mapping to Prisma/GraphQL enum values, and defined matching programmatic GraphQLEnumType instances in enums.ts (such as AccountStatusEnum, VoteTypeEnum, etc.).
• Implemented database-backed resolvers linking core types (User, Post, Comment, Vote, Message, MessageRoom, Group, Roster, Presence, TypingIndicator, Notification, Reaction, Activity, UserInvite, UserReport)
• TESTS WERE DONE USING AI and no errors found

issue link - #138

[vercel]

@sandy4242 is attempting to deploy a commit to the Louis Girifalco's projects Team on Vercel.

A member of the Team first needs to authorize it.

[sandy4242]

@flyblackbox

[motirebuma]

Hey @sandy4242, the structure of this PR is clean. Shared constants in constants.ts, programmatic GraphQLEnumType instances in enums.ts, and database-backed resolvers across all the core types. The toEnumValues helper is a nice touch for keeping the enum definitions DRY. Expanding AccountStatus in common.ts to include 'suspended' | 'pending' is correct. Test coverage is updated. CI is all green.

Three things need attention:

1. N+1 query problem. Every relationship field does a separate Model.findById() or Model.find() call. When a client queries a list of posts, each post individually hits the DB for its creator, comments, votes, quotes, and messageRoom. At scale this will be a serious performance issue. This doesn't need to block the PR, but it should be tracked as follow-up work — a DataLoader layer (or batch query strategy) is the standard fix for this in GraphQL.

2. Group.rosters resolver looks wrong. You have:

   rosters: {
     type: new GraphQLList(RosterType),
     resolve: (group) => Roster.find({ userId: group.creatorId }).lean(),
   }

   This finds rosters where the creator is the user, not rosters belonging to the group. Should this be querying by groupId or by the group's member list instead?

3. Enum values added to constants but not to common.ts type unions. You updated AccountStatus in common.ts, but the constants also add new values for RosterStatus ('declined'), MessageType ('SYSTEM'), and others that don't have matching updates in the TypeScript union types. The GraphQL enums will accept these values at runtime, but TypeScript won't know about them — which defeats the purpose of the migration. Please sync the common.ts type unions with the new constant values.

Also a minor note: the PR description says "TESTS WERE DONE USING AI and no errors found." The tests do pass in CI, but please double-check that the test assertions are actually verifying the new enum values and resolver behavior, not just checking that the types compile.

Verdict: address items 1, 2 and 3 above, then this is ready to merge.

Thank you @sandy4242

@flyblackbox @sandy4242

[sandy4242]

@motirebuma @flyblackbox
the test previously failed, later were fixed by me and a bit of ai

[motirebuma]

Hey @sandy4242 good work addressing the feedback. Both requested changes are fixed:

1. Group.rosters resolver — fixed. Now queries rosters where any group member (creator + allowed users) appears as either userId or buddyId. The $or query with $in on the combined member list is the right approach. The new test verifies this exact query shape.

2. common.ts type unions — fixed. NotificationType, MessageType, RosterStatus, AccountStatus are all updated to match the constant values. InviteStatus type added. Message.type properly typed from string to MessageType. Good.

The new test coverage is solid — runtime enum value validation against the schema, and a resolver integration test with proper model mocking.

One note for future work: the N+1 query pattern (every relationship field doing a separate findById) will need a DataLoader layer at scale. Not a blocker for this PR, but worth tracking as a follow-up issue.

Verdict: approved, ready to merge.

Thank you @sandy4242

@flyblackbox @sandy4242