06-04

1. Is GQL more trouble than its worth?

Biggest troubles I am facing:

• Why in the h*ll is it not possible to organize mutations? It makes Apollo client so much harder to inspect.
• So my team decided to use GQL only for CRUD heavy purposes for resources and other POST operations on REST.
  • Still don't know if this is the best practice. I will have to go through multiple more projects to see how it goes.

2. Some of my biggest mistakes I made while usin GQL for the first time (in production)

Maybe I would have done better with more expreience in GQL but GQL feels like you have to make APIs very abstract from the beginning, focusing on the data.

However, timeline squeezed and I couldn't quite make resolvers that scalable. It was more of a page basis fit.

# biggest problem here is that single Paper object item is not callable without it being sub-instance of Lab
Lab {
 PaperSection {
  total_count
  items {
    title
    journal
    # some more fields
  }
 }
}

Could be problem with how data is setup, as each column is just JSONB, not a normalized table. So each Lab table has Paper JSON array, Award JSON array, Publication JSON array, ... It was like that since we made a super lean system last year and never really was urged to revamp and normalize them. Since they are arrays of JSONs, we need to use GIN index against those JSONB columns in order to index them.

Since that is the case, I just figured I would rather make query like below:

# kind of anti pattern we are currently using
paperByUuid(lab_id, paper_uuid) {
  title
  journal
}

# BP - actually should have been
paper(paper_uuid) {
  title
  journal
}

Project Timeframe, No Expreience, and Unerlying Data Structure seduced me to use that anti pattern you are seeing above.

Now that gql is not that scalable in multiple places througout the platform, I felt like it was a bottleneck for future projects.

Might have to revamp into the BP structure? I will have to see after I actually do it.

3. Kind of not liking HttpError object I made a year ago

/**
 * 학생 사이드 가입 함수
 * @param registerData 가입을 위한 데이터
 * @param userId 가입한 유저의 id
 * @param t 트랜잭션
 */
const handleStudentRegistration = async (
  registerData: RegisterData,
  userId: string,
  t: Transaction
) => {
  try {
    await studentResearcherRepository.create(
      {
        user_id: userId,
        organization: registerData.details.organization,
        department: registerData.details.department,
        position: registerData.details.level,
      },
      t
    );
  } catch (error) {
    if (error instanceof HttpError) throw error;
    if (error instanceof Error)
      throw new HttpError(
        500,
        "UNKNOWN_ERROR_CREATING_STUDENT_RESEARCHER",
        "학생 연구원 생성에 실패했습니다.",
        error
      );
  }
};

We have this kind of error handling and it was lean enough in the beginning. Obviously, it looks better to handle Http Error codes either in controller or all within Express Error Handler. Now that the system is large, it feels much safter and controllable to move all those error codes into single constant Enum and centralize http error code handling at express error handling module.

4. Some thoughts about reviewing new / quick change figma docs

When receiving slack alert for some design changes or flow changes, I would only try to read ones that are directly related to me. However, I realized most of the design changes contain some kind of changes not only in FE but also in BE. As I of suck at imagining how a product should be implemented (I am still figuring out why), I also think it would be a great practice to try to imagine every bits of implementation until there is no murky bit.

Also trying to find best practices to imagine the implementation.

5. Feeling like TIL is quite nice

TIL lets me come up with Action Plan and direct feedback in a couple days.

6. How do you create an immaculate backend api, even with time crunch?

• exploring edge cases?

• just loads of experience?

• test cases? => seems to help a lot. also llms generate test cases quite well.

  • only down side with test cases is that testing becomes slower and slower as we use integration tests mostly.

I need more contemplation on this topic.

7. Thoughts are PR review

• Currently I am the only when that can fully understand all the codes produced in the team.
• I cannot physically go through every bits.
• My new goal:
  • For important bits, manually git pull and test the software
  • For less important bits, capture
    • what is the issue (ticket)
      • for fix: the bug scenario itself
      • for feat: the feature itself
    • what caused that issue (ticket)
      • for fix: cause of the bug
      • for feat: why was this feature added in the first place?
    • what was done to solve that issue
      • for fix: the approach & main code snippets
      • for feat: the approach & main code snippets
    • not the details.