Code design decisions

• Prefix GraphQL mutation names with the model they belong to:

  // ✅ Do this
  @Mutation(() => ConMentorshipMatchesApplyForMentorshipOutputDto, {
    name: 'conMentorshipMatchesApplyForMentorship',
  })
  
  // ❌ Not this
  @Mutation(() => ConMentorshipMatchesApplyForMentorshipOutputDto, {
    name: 'applyForMentorship',
  })

• Return {ok: true, id:<id of affected entity>} or an error from mutations. Let client query run a query. This follows CQRS: segregate commands and queries.

• Simple queries and mutations get one resolver function + one service function. More complex queries/mutations should get a use case folder. See apps/nestjs-api/src/tp-company-profiles/use-cases/tp-company-profile-sign-up for a use case example.

• Some properties of entities are computed at the Salesforce level. E.g. ConProfile.fullName.

• A lot of things can be done better. The NestJS API was created with a “let’s make it fairly good but essentially let’s just refactor code” approach. Eric has a fairly big list of future things that can be done to greatly improve nestjs-api and the CON/TP frontends.

• For server state data used “globally” in CON or TP, such as the profile of the current user, we use a single GraphQL query and a single react-query query to load that data. See libs/data-access/src/lib/con/my-con-profile/my-con-profile.graphql, libs/data-access/src/lib/tp/my-tp-jobseeker-profile and libs/data-access/src/lib/tp/my-tp-company-profile.