최근 인프랩 면접에서 얻게 된 코드 리뷰를 통해 현업에서 사용하고 있는 코드들에 대해 되짚어 보고 있다. 값진 경험을 통해 메타인지를 할 수 있게 되었고, 오답이라고 생각하는 부분에 대한 리팩토링을 진행하고 있다. 특히 이번에는 면접 당시에 서비스 레이어와 인프라(DB) 레이어 사이의 의존성에 대해 피드백을 들었던 부분을 바탕으로 실제 코드를 개선하고 그 과정에서 꼬리에 꼬리를 무는 의문들을 정리해보는 시간을 가지고자 한다.  import { Injectable } from '@nestjs/common';import { InjectRepository } from '@nestjs/typeorm';import { Repository } from 'typeorm';import { User } from './u..

ORM을 사용하다보면 N + 1 문제를 마주하곤 하는데, 특히 ORM의 Default Fetch Type설정이 Lazy일 경우 더 그렇다. 이제 막 typeORM을 사용해보고 있다고 하시는 분과 커피챗을 할 기회가 생겼는데 typeORM에서는 N + 1을 어떻게 해결하냐는 얘기가 나왔었다. N + 1이 어떤 것인지는 알고 있었으나 나는 typeORM을 사용하면서 실제적으로 N + 1을 마주한 경험이 없다. 실제로 실무에서도 페이징을 위한 paginate 라이브러리 사용 시 Distinct로 클러스터 인덱스를 가져와서 리스트, 페이징에 총 세 번의 쿼리를 사용하는 경우를 제외하고는 본 적이 없다. 왜 그럴까 곰곰이 생각을 해봤다. 최근에 nest에서 graphQL을 사용하고자 했을 때에도 N + 1 문제를..

graphQL에 대해 알아보자 - 1 (with NestJS, typeORM)학습을 위해 생성한 예제 코드는 깃헙에 있습니다.(링크)  graphQLgraphQL은 기존 데이터로 쿼리를 실행하기 위한 API를 위한 쿼리 언어이자 런타임이다. 클라이언트가 필요한 것만 정확히 요청할mag1c.tistory.com  N + 1이전 글의 예제에서 Post를 가져오는데에 Post와 Comments는 1:N 관계를 가진다.이 관계에서 comments를 조회할 때 comment가 lazy loding되어 N + 1 문제가 발생할 수 있다. //lazy loadingasync findAll(authorId?: number): Promise {    if (authorId) return await this.postRep..

GitHub - mag123c/nest-graphQLContribute to mag123c/nest-graphQL development by creating an account on GitHub.github.com graphQLgraphQL은 기존 데이터로 쿼리를 실행하기 위한 API를 위한 쿼리 언어이자 런타임이다. 클라이언트가 필요한 것만 정확히 요청할 수 있게 해준다. 공식 문서의 설명을 읽어보면 자세한 특징을 서술해두었고, 읽어보면 공통적으로 나오는 키워드들은 빠르다, 단일 요청, 쿼리와 타입 정도가 있다. 또한 공식 문서 내의 포스팅 중 REST와 비교한 글이 있었는데, "graphQL은 REST와 크게 다르지 않지만, API를 구축하고 소비하는 개발자 경험에 큰 차이를 만드는 작은 몇가지의 변..

초년차 백엔드 개발자의 사이드 프로젝트 앱 배포 경험기입니다.(기술적 서술이 없습니다.) NextJS로 구성된 웹앱을 React Native + Expo를 사용해 안드로이드 앱으로 전환하고 배포하는 과정의 기록입니다.(기본 도메인 세팅이 완료되었고, Vercel로 배포해놓은 상태입니다.)    개발서버기존 NextJS로 구성된 프론트를 React Native로 EXPO를 통해 테스트용 APK를 만들어보기로했음.  expo-cli는 deprecated되었고, node 17v 이상과 호환성 문제가 발생할 수 있다고 합니다.프로젝트 내 자체 cli를 설치하여 사용하는 걸 권장한다고 합니다.expo build명령어도 eas build로 대체되었다고 하네요# expo cli 설치npm install expo-cl..

정확한 정보 전달이 아닌, 여러 좋은 포스팅들을 보며 적용해보고개인의 관점에서의 의견 서술입니다. 여러 피드백들을 적극 환영합니다.    요약트리 쉐이킹(Tree Shaking)은 번들링 시 사용하지 않는 불필요한 코드를 제거하는 최적화 작업을 말한다.프론트에서의 트리쉐이킹은 번들의 크기를 최소화해서 UX의 향상에 목적이 있다고 하지만 백엔드 관점에서의 최적화는 코드의 안정성, 유지보수 등에 초점이 맞춰지고, 프로젝트의 특성과 요구사항과 등을 고려하는 것이 좋다고 생각한다.TypeScript4.1에 추가된 Template Literal Type처럼, 명시된 타입들을 조합하는 복잡한 타입 조합이 필요하지 않을 경우, 이넘을 사용하는 것이 어떠한 이넘 값으로 강제되기 때문에 오히려 더 명확한 의도를 전달할 ..

해당 글을 보고 오시면 좋아요  [쿼리튜닝] 신입 개발자의 간단한 사내 조회 쿼리의 쿼리튜닝 여정.발단 계속해서 짧은 주기로 프로젝트를 쏟아내고 있던 와중에 DB연산이 많은 작업을 수행하는 경우가 생겼다. 개발 단계에서 API 자체를 돌리는 과정에서도 1~2000ms가 되어 걱정하고 있던 과정에 Qmag1c.tistory.com     서론팀장님께서 나를 불렀다."집계 함수를 사용해서 요청사항 집계를 하는 SQL문이 있는데 ~~~ 성능 최적화를 좀 할 수 있을까요?" 기존 쿼리를 받아들고 돌려보았다.    기존 상태SELECT    YEAR(a.registe_time) AS year,    MONTH(a.registe_time) AS month,    a.code,    count(a.code) AS t..

발단계속해서 짧은 주기로 프로젝트를 쏟아내고 있던 와중에 DB연산이 많은 작업을 수행하는 경우가 생겼다.개발 단계에서 API 자체를 돌리는 과정에서도 1~2000ms가 되어 걱정하고 있던 과정에QA를 진행했더니 난리가났다.이상하게 이에 대해 아무도 피드백을 해 주지 않았다.  들쭉날쭉한 건 요청이 한번에 서버로 몰릴 때로 인식을 하겠다지만,30건 정도밖에 안되는 데이터를 연산하는데 말이 안된다고 생각했고, 작업에 들어갔다.  원인 파악하기 원인을 파악하기 위해, 어쩔 수 없이 로직의 각 구간별로 로깅을 시도했다.  연산 처리속도는 빨랐는데, 애초에 데이터를 그렇게 많이 들고나오지 않기 때문이다.연산은 간략히 설명하자면 다음과 같다 데이터를 row형태로 가져나오는데, PK가 일치할 경우, 같은 문의에 상품..