출근 100일차 - TypeORM JSON

·2023년 1월 17일
2

회사이야기

목록 보기
36/48

와! 출근 100일차!

오늘은 이래저래 많이 했던 날이다.

LEFT JOIN을 하고 싶어.

기존의 LEFT JOIN이 필요한 것이 아니라, 테이블에 없는 LEFT JOIN이 하고 싶었다.

기존의 TypeORM이라면

그저 @LeftJoin()을 사용하는 것으로 넘어갈 수 있었지만
테이블 컬럼이 존재하지 않는 것은 어떻게 할 방법이 없더라

그래서 불가능할리가 없는데, 라는 생각으로 계속 보다보니 @leftJoinAndMapMany() 라는게 계속 보였다.

면밀히 살펴보니, 이게 SQL의 Left Join과 같은 역할을 해준다는 것을 알았다!

@leftJoinAndMapMany(가상의 필드의 명칭, Join할 Entity, Join한 Entity의 별칭, 조인조건)

이렇게 사용할 수 있었다!

Json을 가지고 놀아보자

그렇다 어쩔 수 없이 현재 JSON 필드를 쓰고 있다.

문제는 이 JSON 필드에 어쩔 수 없이 담궈놨는데, 이게 좀 문제가 있었다.
해당 값을 가져오는데 이래저래 복잡하게 돌아서 속도를 많이 잡아먹었고 있었기 때문에...

그래서 위의 메소드를 찾기도 했는데, JSON의 array object의 value를 JOIN을 해야했다.

아무튼 그래서 결론은?

했다

.leftJoinAndMapMany(
  'user.mapList',Map,'map',
   `JSON_CONTAINS(mapIds->'$[*].mapName', cast(map.id as json))`
)
  1. user를 반환할건데
  2. mapList라는 임시 필드에 해당 값을 넣는다.
  3. Map 테이블을 LEFT JOIN하고, map이라고 별칭을 지정한다.
  4. user 테이블에 mapIds [{mapName:"어쩌구"}] 라는 JSON 필드에서 mapName의 모든 값을 추출한다.
  5. 추출한 값으로 map.id에 집어넣어서 일치하는 일치하는 데이터를 가져온다.

라는 느낌으로 테이블을 조인해서 해당 값을 한번에 가져올 수 있게 됐다.

이 동작 하나로 리스트를 가져오던 쿼리의 속도가 30%정도 감소해서 성능적으로 많은 이점을 얻어냈다.

기존 API를 개선해보자.

리팩토링은 크게 2갈래로 나눠지는 것 같다.

  1. 기존 API를 같은 동작으로 새롭게 만든다.
  2. 기존 API 자체를 개선해서 성능 향상을 시킨다.

1번 같은 경우 모듈단위를 분리하면서 진행을 했는데

이번에는 2번이 필요했다.

조만간 고도화가 예정되어있는데, 비즈니스적 문제로 일단 쓸 수 있게 만들어야하는 상황이 왔기 때문인데...

서비스 초창기에 작성된 API다보니 이제는 필요없는 정보들도 정말 많았다.
오버페칭때문에 과도하게 응답 데이터가 큰 것도 문제라서 이런 부분도 조율이 필요했다.

프론트와 협의를 하고, 필요한 필드를 재정립 한 후 API 호출을 반복해보았는데

기존의 속도보다 절반이나 줄어들었고, 추가적인 기능도 넣을 수 있었다!


100일차 출근, 5개월이 된 지금 나는 잘 하고 있을까?
나의 목표는 무엇이고, 다른 사람들만큼 하고 있을까?

비교를 하는 것은 아니지만, 조금 궁금한 것 같다

한달 전의 나와 지금의 나는 갭이 크다고 생각하는 만큼
한달 뒤의 나는 지금과 상당히 다른 모습을 가지고 있을 것이다.

화이팅!

profile
물류 서비스 Backend Software Developer

1개의 댓글

comment-user-thumbnail
2023년 1월 18일

100일 축하드립니다

답글 달기