코드 훔쳐보는 변태 코더
춤 좋아하는 백엔드 개발자(였으면 좋겠다)
23-01-10 TIL

오늘 진행한 것들 🤔

  • 토이프로젝트 진행
    • 캐릭터 검색 뷰 수정/ 캐릭터 검색시에 모험단 이름, 모험가 명성까지 조회가능
    • 여러 계정에 한 캐릭터 등록 가능하도록 구조 변경
    • 비동기식으로 데이터 처리하도록 수정 (중요!)

오늘 겪었던 문제 🤔

  • 페이지네이션
    • 페이징을 할 때 sublist로 내보내다 보니 인덱스가 맞지 않을따 발생하는 예외를 생각하지 못했다.
    • 프런트에서는 disable 추가, 백에서는 예외처리 추가 예정
  • 프런트 이미지 출력 문제
  • 대표 캐릭터 등록 설정 -> 한 계정당 하나  (이미 등록 시에 등록 더 이상 못함)
  • 수정 중 -> DTO response로 내보내기 (캐릭터에 유저정보 포함되어 있음)

깔끔하게 변경한모습

오늘 해결한 오류 🤔

  • 오류라기보다는 문제였던 점
    • 100개의 데이터를 한 번에 가져올 때 어떻게 해야지 검색결과에 각 캐릭터의 주요 능력치까지 가져와버리면 한 번의 클릭에 총 101번의 작업을 진행해야 해서 속도가 느렸다.
      • 문제는 스프링은 기본적으로 한 요청을 완료하고 그다음 요청을 진행하기 때문에 속도가 느렸던 것이었다..!
      • 방법은 비동기 처리로 해결완료
      • 하지만 이렇게 처리해버리니 API별 허용된 호출 횟수에 오류가 발생했다.
      • 동시접속자가 100명 이상이라면? 1초에 허용되는 적절한 호출 횟수를 찾아야 했다.
      • 캐릭터 목록 100개를 조회 후 통계를 위해 저장하고, 각각의 세부데이터를 호출해 저장하면 한번 검색에 최대 101번을 호출하는 것이다.
        • 따라서 조건을 주고, 처음에 10개를 출력하는 페이지별로 조회해 11번의 호출을 하도록 했다.
          • 하지만 해당 방법도 사실 유령 캐릭터가 많기 때문에 불필요한 호출이 많아질 수도?
          • 따라서 페이지별로 캐릭터 레벨이 만렙에서 가까울 때 조회를 하도록 했다. (최근에 플레이하고 있을 확률이 높다.)
        • 매번 검색할 때마다 저장하지 않고, 조건에 맞춰서 호출을 추가로 더 진행하고, 캐릭터 상세 정보를 조회 시에 (스펙을 확인하기 위해) 따로 한번 더 호출하도록 해서 통계를 위해 저장하면 될 것 같았다.
          • 실제로도 타 사이트에서 해당 방법으로 데이터를 저장하는 것 같았다. (최근에 플레이하지 않거나 캐릭터를 검색해본 적이 없으면 스펙 랭킹에서는 제외되는 방식)
    • 캐릭터와 계정간 매핑 문제
      • 생각을 해보니 단순히 한캐릭터당 계정 하나를 등록할 수 있게 설계를 했던 것이었다.
        • 따라서 중간 연관관계용 테이블을 만들고, ManyToMany 를 지양한 설계를 진행하고 코드를 작성했다.
        • 여러 계정이 동시에 같은 캐릭터를 등록할 수 있도록 변경되었다. 굿!
    • 고쳐야 할점이나 추가해야할것
      • 계정 생성시 Validation 을 프론트에서만 진행하는 문제
      • 계정 대표캐릭터 생성 로직 설계 (어떻게 대표캐릭터를 설정하도록 할것인지? 어떠한 조건?)
      • 캐릭터 모험단 검색 (어떻게 검색을 구현해야할까? 모험단은 캐릭터 상세 스텟에서만 조회가 가능하다.)
        • 구현 완료! 외부 api를 이용하는 것이기 때문에, 검색할때마다 갱신을 하는 방법으로 저장을 해줘야 한다.

오늘의 배운 점🤔

  • 설계에 대한 고민을 했습니다.
    • 따라하고자 하는 시스템이 어떠한 구조로 돌아가고 있는지, 어떻게 처리속도를 빠르게 적용시켰을지, 어떻게 데이터를 저장할지에 대해서 고민을 해보았습니다.
    • 비동기 처리를 가능하게 해주는 Async 어노테이션을 사용해보았습니다.
      • 단순히 어노테이션만 붙이고 사용하는게 아닌, 제약 조건이 많았습니다. 그중에서는 어떠한 행동을 최소한으로 쪼개서 멀티스레드에서 동작시킬지를 고민하는것이었습니다.
        • 해당 문제는 따로 상세 정보를 가져와 저장할 일이 있을때 사용하도록 구현해보았습니다.
    • 뷰를 더 이쁘게 수정해보았습니다.
      • 가장 아쉬운건 반응형 사이트를 만들지 못한다는것입니다. 지금 상황에서 프론트까지 챙겨가기엔 너무 시간이 오래걸립니다. 타임리프로 만족해야겠습니다 ㅠㅠ.

 

'TIL' 카테고리의 다른 글

23-01-13 TIL  (0) 2023.01.14
23-01-12 TIL  (0) 2023.01.12
23-01-09 TIL  (0) 2023.01.09
23-01-07 TIL  (0) 2023.01.08
23-01-06 TIL  (0) 2023.01.07
  Comments,     Trackbacks