[seminar4.5] 과제

[gahyuun]

ERD

API

1. /shopping GET

✅ Response Body

[
   {id:1,
    name:'배민B마트',
    image: // 이미지 주소
    },
    {id:3,
    name:'홈플러스',
    image: // 이미지 주소
    },
    {id:1,
    name:'CU',
    image: // 이미지 주소
    },
    ....
]

1. /store?category=분식&sort=기본순&hasCoupon=true&deliveryMode=한집배달&page=1 GET

• 쿼리스트링의 값은 예시입니다
• 배달시간과 배달료는 사용자의 주소 위치와 가게의 위치를 고려하여 정해질 것 같아 ERD에는 위치만 저장하였습니다.

✅ Response Body

[
   {id:1,
    name:'운정김밥야당본점',
    thumbnail:[
    {
      menu:'운정김밥',
      price:4000,
      image:'주소'
    },.....
    ] ,// 이미지 주소들
    minimum_order:15000,
    grade:4.7,
    category:'분식',
    delivery_fee:0,
    min_delivery_time:18,
    max_delivery_time:33
    },
    {id:2,
    name:'셀렉커피랩 커피 파주야당점',
    thumbnail:[
    {
      menu:'[배달 | v ~~~~~',
      price:3800,
      image:'주소'
    },.....
    ], // 이미지 주소들,
    minimum_order:9500,
    grade:5.0,
    category:'분식',
    delivery_fee:0,
    min_delivery_time:22,
    max_delivery_time:37,
    },
    ....
]

고민

❗ Category를 하나의 테이블로 만들어야 할까?

확장성을 고려하여 Category를 하나의 테이블로 만들까 고민을 했습니다. Category를 하나의 테이블로 만들게 되면, 카테고리 설명이나 카테고리 우선순위 등 카테고리에 대한 부가적인 설명이 추가가 되었을 때 유용할 것이라고 생각했습니다. 하지만 캡쳐 사진만 보았을 때는 카테고리가 딱히 부가적인 정보가 필요해보이지 않았고 자주 바뀌지 않는 정보라고 판단했기 때문에 따로 테이블로 만들지 않았습니다. 딱 diary service의 카테고리정도의 용도라고만 생각했습니다!

결론적으로 Category 테이블을 만들 이유가 충분해보이지 않아 따로 구현하지 않고 Store 테이블의 필드로 추가했습니다

물론 현재 캡쳐 사진에서 카테고리 중 일부만 노출되어있기 때문에 데이터 기반으로 일부 노출을 한거면 테이블이 필요할 수도 있지 않을까? 라는 고민도 해보았는데, 화면만 보았을 때는 그렇게 느껴지지 않았습니다 ,,,

❗ Category를 API로 받아야 할까?

위 고민이랑 비슷한 맥락일 수 있는데, 카테고리 정보들을 API로 받아야 하나? 라는 고민을 했습니다.

1. 카테고리는 모든 사람에게 전역적으로 같은가?
2. 카테고리는 변동적인가?

실제 배민 서비스는 다르겠지만 사진으로만 봤을 땐 카테고리가 전역적이고 변동적이지도 않아서 스타벅스를 제외한 카테고리는 백엔드 <-> 프론트가 합의한 Enum으로 프론트에서 렌더링하고 카테고리를 눌렀을 때 합의된 Enum 값을 넘기면 카테고리에 해당하는 값을 넘기는 방식으로 생각했습니다.

전역적이지도 않고 변동적이지도 않은 데이터를 서버로부터 받게 된다면 네트워크 에러가 발생했을 때를 고려한 에러처리, 데이터 응답올 때까지 로딩 처리, 요청 수 증가 등 고려해야하는 것들이 불필요하게 늘어나니까요!

결론적으로 배민에서 카테고리 역할이나 server-driven-ui 등 여러 제약에 따라 다르겠지만, 사진으로만 보았을 때 카테고리에는 별도의 API가 필요없다고 느껴 카테고리 API를 따로 구현하지 않았습니다.

스타벅스는 카테고리가 아닌 것 같은데 노출되어서 찾아봤지만 어떤 도메인이고 어떤 기준에 의해서 노출되는지 파악을 못해서 따로 api를 만들진 않았습니다!

❗store api의 쿼리스트링

store api에는 많은 쿼리스트링이 존재하는데 쿼리 스트링은 필터링의 역할을 하기에 필터링이 필요한 정보들을 다 쿼리스트링으로 할당했습니다. 카테고리, 정렬순, 쿠폰 유무, 배달방식, 페이징 ….

배달의 민족 서비스를 들어갔을 때 매장들이 무한 스크롤로 보여지는 것을 확인했습니다. 무한 스크롤로 진행을 하면 클라이언트가 서버로부터 일정 개수의 데이터만 받아오기 때문에 페이징 처리를 진행했습니다.