[API]Tag - gyunam-bark/nb02-how-do-i-look-team1 GitHub Wiki

설계

flowchart TD
    FRONT_END --> ENDPOINT
    ENDPOINT -->|'/tags'| ROUTER
    ROUTER --> CONTROLLER
    CONTROLLER <--> SERVICE
    SERVICE <--> DATABASE
    CONTROLLER -->|FAIL| GLOBAL_ERROR_HANDLER
    GLOBAL_ERROR_HANDLER --> FRONT_END
    CONTROLLER -->|SUCCESS| FRONT_END

스키마

model Tag {
  tagId Int    @id @default(autoincrement())
  name  String @unique

  styleTags StyleTag[]
}

model StyleTag {
  styleId Int
  tagId   Int

  tag   Tag   @relation(fields: [tagId], references: [tagId])
  style Style @relation(fields: [styleId], references: [styleId])

  @@id([styleId, tagId]) // 복합 PK
}

시행착오

1. FE 코드를 보아야 아는 것도 있다.

현상

처음 FE 코드를 연동할 때 /tags 와 관련된 에러가 발생했다.

원인

/tags 은 특이하게도 엔드포인트를 제외하고는 API 명세서에 아무것도 정리된 것이 없다.

스크린샷 2025-06-12 오전 11 44 57

그래서 FE 연동 전에는 스키마에 작성 된 것과 다른 API 명세서를 참고해서 아래와 같은 구조로 반환하도록 코드를 작성했었다.

return {
  totalItemCount: totalItemCount,
  data: tagList,
};

근데 FE 를 연동하는 과정에서 tags 를 정상적으로 불러올 수 없다고 에러가 발생했다.

tags 를 가져오는 FE 코드를 확인했더니, 아래와 같이 { "tags":["string"] }로 받아온다는 것을 확인 할 수 있었다.

const getGalleryTags = async () => {
  const { tags } = await getGalleryTagsApi()
  return tags as string[]
}

해결책

크게 두 가지의 방향성이 있었다.

  1. 문자열 배열을 반환하도록 API 코드를 수정
  2. FE 코드에 Tags 타입을 추가해서 처리

약간의 고민 끝에 1. 문자열 배열을 반환하도록 API 코드를 수정 하는 것을 선택했다.

가능한 다른 API 들의 목록을 가져오는 구조를 지키고 싶었지만, 이 /tags 가 FE 가 실행될 때 초창기에 불린다는 구조적 특징이 있었다.

즉, 내가 이 문제를 빨리 해결 할 수록 팀원들이 빨리 개인의 엔드포인트를 작업할 수 있었다.

그리고 우리가 현재 개발 중인 서비스에서 이 /tags 엔드포인트는 그렇게까지 중요한 부분을 차지하는 것도 아니었다.

그냥 빨리 수정하고, 다른 수정 사항 또는 추가 사항을 고려하는 것이 훨씬 생산적이라고 판단 되었다.

그리하여 최종적으로 반환 객체의 모습은 아래와 같다.

const tagList = await TagService.getTagList();

res.status(200).json({ tags: tagList });

개인메모

API 명세서에 자유롭게 하라고 되어 있었는데, 정작 Response 는 형태를 정해서 받고 있었다.

FE 연동을 예정보다 일찍 할 수 있어서 수정할 시간이 여유로웠어서 다행이다. 다음에는 미리 확인하고 설계해야겠다..