24.09.21 TIL : CH3 풋살온라인 프로젝트

 

 

오늘은 !  진행중인 브라우저 구현 부분에 대한 TIL 을 작성해보자.

 

사실, 프론트는 이번 과제의 목표도 아니고 !!

필수도, 도전도 아닌 선택의 영역이다.

 

하지만, 우리팀은 프론트를 진행하는 것으로 결정이 됐기 때문에,

백엔드, API가 어느정도 완성돼가는 인원부터 브라우저를 구현하도록 했다.

 

 

현재, 목표로 했던 팀=> 선수관리 API 관련한 부분은 대부분 브라우저에서 작동하도록 구현했다.

 

구현하고 싶으나 시간도, 방법도 모르겠는

오류 처리 방식, message 출력,  특정 div 영역 새로고침, API 에 맞춤형 Request 창 등등

아직 해야할것이 많지만, 백엔드가 완벽한 것이 아니기 때문에 이쯤에서 다시 백엔드로 돌아가기로 했다.

 

먼저, 어제 고민했던 중복선수 카운트 부분이다.

 

 

로우쿼리.. 돌아왔구나..

 

기존에 사용했던 Prisma 의 distinct는 count 를 하는데 어려움이 있다.

그래서 prisma의 group by 를 사용하려고 했으나, join과 그룹화, 카운트를 동시에 진행하는것이 굉장히 난해했다.

 

오히려 쿼리문을 사용한다면 쉬울것 같은데? 라는 생각에서 작성을 해 보았다.

 

한번에 해결될 리가 없다 

 

count 를 한 결과값이 5n...  아마도, bigint 의 형식으로 출력되는듯 하다.

아무래도, 얼마나 될지 모르는 양의 데이터를 count 하는것이기 때문에

기본적으로 mysql에서는 bigint를 출력하게 되어있는듯 하다. 

 

bigint 는 json 형태로 값을 전달할 수 없는것인지, 에러가 발생한다.

::int  CAST() 등등 으로 제발int를 출력하도록 유도했지만, 계속해서 에러만 발생했다.

 

게다가  boolean 값이어야 할 isPicked 컬럼은 아예 정수로 반환이 되었다.

 

어차피, player능력치에 해당하는 부분은 강화수치를 적용하기 위해 재가공을 해야하는 만큼,

한번에 map으로 재가공을 하기로 했다.

 

 

수량에는 parseInt를, isPicked 에는 Boolean() 을, 능력치 부분에는 강화수치를 적용하는 것으로 처리했다.

 

 

 api 자체는 선수의 조회기능이기 때문에, 능력치를 가독성 있게 문자열로 표현하게했다.

 

결과는 그럴싸 하지만, 탐탁치는 않은 부분이다 !!

보유한선수를 모두 조회하고, 꽤 많은 데이터를 map을 통해 재가공 하기 때문에 리소스 소모가 클 수 밖에 없다.

 

당장 최적화 방법이 떠오르지 않고, 추후 브라우저의 보유선수 조회 기능에서 많은 기능이 연계될 것으로 계획했기 때문에

일단은 이 상태로 진행하기로 했다.

 

사실, 이미 어느정도는 작동한다

 

 

하나 하나 쌓여가는 API 들 

 

다음 목표는 트랜잭션과 오류 처리 부분이다 !