isayaksh commented 1 year ago

✏️ Topic of Discussion

🔥 API 호출에 대한 2가지 접근

Request

GET http://api.jari-bean.com/api/cafe/{cafeId}

Response

{
  "cafeDetailDto": {
    "cafeSummaryDto": {
      "id": "string",
      "name": "string",
      "address": "string",
      "imageUrl": "string"
    },
    "openingHour": "2023-08-27T12:01:06.970Z",
    "closingHour": "2023-08-27T12:01:06.970Z",
    "phoneNumber": "string",
    "description": "string",
    "instagram": "string",
    "image": "string"
  },
  "tableReserveResDtoList": [
    {
      "tableDetailDto": {},
      "availableTimeList": [
        {
          "startTime": "2023-08-27T12:01:06.970Z",
          "endTime": "2023-08-27T12:01:06.970Z"
        }
      ]
    }
  ]
}

💡 1. 카페 정보, 카페 테이블 예약 내역 2개를 1번의 API 호출로 조회

위 화면은 카페의 카페 정보 와 카페 테이블 예약 내역 을 볼 수 있는 화면이다. 해당 화면에서 데이터를 요청할 경우 1번의 API Call로 카페 정보 와 카페 테이블 예약 내역 총 2개의 데이터를 한번에 조회한다.

현재는 1개의 화면에 보이는 모든 데이터를 한번에 제공하는 방식을 사용하고 있고 해당 방식을 우리 팀이 선정한 이유는 다음과 같다.

HTTP 요청 수를 최대한 줄이기 위해서
DB 커넥션을 최소화하기 위해서

즉, 현재 사용중인 조회 방식은 네트워크를 효율적으로 사용하기 위한 최적을 고려한 방식이라고 할 수 있다.

💡 2. 카페 정보 1번, 카페 테이블 내역 1번 총 2번의 API 호출로 조회

제안하고자 하는 방법은 1개의 화면에 여러 타입의 데이터가 존재할 경우 각 데이터에 맞는 API를 호출하는 방법이다. 위 화면을 예로 들면 카페 정보 에 대한 요청 1번, 카페 테이블 예약 내역 에 대한 요청 1번 총 2번의 요청을 통해 데이터를 조회하는 방식이다.

각 데이터에 맞는 API 호출 방법을 제안하는 이유는 다음과 같다.

만약 카페 정보 와 카페 테이블 예약 내역 을 한번에 반환하는 API를 만들 경우 카페 정보 만 필요할 경우 혹은 카페 테이블 예약 내역 만 필요할 경우에도 API를 새롭게 만들어야 한다.
객체는 단 하나만의 책임을 가져야 한다는 원칙처럼 API도 하나의 책임을 가져야 한다고 생각한다. 물론 데이터를 한번에 조회하면 성능적인 측면에서 좋을 수 있지만, 대신 해당 API는 해당 화면에 종속적인 즉 그 화면에서만 사용할 수 있는 상태가 될 것이다.
DB 순차적으로 조회해서 한번에 2개의 데이터를 가져와 화면에 그리는 것보다, 서로 독립된 쓰레드로 여러개의 데이터를 동시에 조회해서 조회된 데이터를 먼저 그리는 것이 더 빠를 것이라고 추측(?)한다.
```
만약 API를 호출할 때 A는 3초, B는 5초가 걸린다고 했을 때,
한번에 조회할 경우 총 8초 후에 모든 결과를 받을 수 있지만
나누어서 조회할 경우 3초 후에는 A를 받아볼 수 있고, 5초에는 B를 받아볼 수 있다.
```
각 데이터를 따로 조회하도록 하는 것이 로직이 간단하기 때문에 유지보수 측면과 테스트 과정에서 굉장히 편리하다.
만약 화면 구성이 변경이 필요한 경우 백엔드에서는 DTO, Controller, Service 단계의 로직을 수정해야 한다. 즉, 결합도를 낮추기 위해서라도 분리하는 것이 좋을 것 같다.

🙏 Discussion

해당 주제는 각각의 장단점이 있다고 생각한다. 장단점에 대해 서로 논하면서 해당 주제에 대해 좀 더 깊이 있는 생각을 할 기회를 얻고싶습니다 여러분

psy-choi commented 1 year ago

만약 카페 정보가 필요하다면, 해당 부분에 대한 API를 따로 생성하면 될 일이라고 생각합니다. ex. api/cafe/{cafeId}/info 와 같이요

물론 저희가 엄청난 어플은 아니기에 API를 많이 호출할 일이 없어서 네트워크 비용에 대한 고려가 웃기는 일이라고 생각이 들수도 있지만,

많은 멘토님들과 이야기를 통해서 한 화면을 구성하는 API를 동시에 가져오는 편이 좋다는 조언을 충분히 많이 받았다고 생각합니다. 확장성을 정말로 고려한다면 코드를 더 생성하는 것보다 비용적인 측면에 대한 고려가 더 중요하다고 생각하구요.

그리고 성능적인 부분에서도 그렇게 큰 차이가 생길 것 같지 않아서 개인적으로는 반대입니다...

LineNo2 commented 1 year ago

그리고 성능적인 부분에서도 그렇게 큰 차이가 생길 것 같지 않아서 개인적으로는 반대입니다...

성능에 대한 부분은 저도 동의합니다. 두개를 분리한다고 한들 큰 성능 개선은 이루어지지 않을 수도 있을 것 같습니다. 라고 하려고 했는데, 이 부분을 읽고 마음이 바뀌었습니다.

만약 API를 호출할 때 A는 3초, B는 5초가 걸린다고 했을 때, 한번에 조회할 경우 총 8초 후에 모든 결과를 받을 수 있지만 나누어서 조회할 경우 3초 후에는 A를 받아볼 수 있고, 5초에는 B를 받아볼 수 있다.

백엔드에서 수행되는 DB 조회도 멀티쓰레드이기 때문에 동시에 병렬로 두 작업이 수행되는 것도 물론 성능 개선에 이점이 있을 것 같습니다. 저는 여기서 추가로 네트워크를 타고 넘어올 때를 주목하고싶습니다. http2.0은 멀티플렉싱을 지원합니다. 여러개의 요청들을 동시에 병렬로 처리할 수 있어서, 기존의 파이프라이닝인 http1.1보다 더 빠른 것으로 알고 있습니다. 이런 측면에서 봤을 때 두개로 분리하는 것도 일리가 있을 것 같습니다. 10초동안 보내야 하는 파일을 3초, 7초로 나누어 보내면 4초만에 프론트에서는 로딩을 시작해 UX가 향상될 수 있을테니까요. 라고 말씀드리려고 했으나, 현재 서버에 적용되어있는것은 http1.1인것으로 확인되었습니다. 쉽지는 않겠지만, 다음을 참고하시면 아마 적용이 가능 할 것이라고 사려됩니다.

프론트단에서의 이야기도 상현님이 언급하신 5, 6번에 관점에서 이야기하고자 합니다. 프론트에서도 마찬가지로 서버에서의 응답을 처리하기 위한 DTO를 가지고있고, 만약 서비스의 업데이트로 화면 구조가 바뀌어 요청받는 데이터가 바뀌게 된다면 DTO는 추가로 수정되어야 할 것입니다. 추가로, 제가 채용하고 있는 MVVM 아키텍쳐에서는 ViewModel 중 Repository라는 개념이 있어 서버와의 통신 결과를 가지고 있으나, DTO가 추가되거나 변경되면 Repository도 추가되거나 변경되어야 합니다. 이는 물론 한번에 통합해서 보내는 1번의 방법 뿐만 아니라 2번에서도 수반될 수 있을것입니다. 저도 이건 해봐야 알 것 같아서 조심스럽긴 합니다만, 당장은 2번 구조가 더 편해보이는 것은 사실입니다.

이 문제에 대해서 다시 이야기 나눌 수 있으면 좋을 것 같습니다.

SWM-99-degree / jariBean

[DISCUSSION] API 구조 설계에 관한 의견 공유 #129