kakasoo

수직확장과 수평확장 사람들은 확장성과 관련해 용량 확장(수직 확장), 규모 확장(수평 확장) 을 말한다. 수직 확장은 좀 더 강력한 장비로 이동하는 것이고, 수평 확장은 여러 기기들로 부하를 분산하는 것을 말한다. 서로 다른 기기로 부하를 나누기 때문에 수평 확장은 다시 비공유 아키텍처라고 부르기도 한다. 단일 장비에서 수행하는 시스템이 비교적 간단하기는 하지만, 고사양 장비는 매우 비싸 대개 규모 확장을 택한다. 적절한 장비 몇 대가 다량의 낮은 사양 가상 장비, 또는 몇 대의 높은 사양 가상 장비보다 저렴하고 효율적이다. 탄력적 (Elastic) 일부 시스템은 탄력적(elastic)이다. 즉, 부하 증가를 감지하면 컴퓨팅 자원을 자동으로 추가할 수 있다. 탄력적인 시스템은 부하를 예측할 수 없을 경우..

TypeORM에는 setFindOptions 라는 메서드가 있고, 이걸 활용하면 할 수 있는 일이 참 많습니다. 하지만 공식문서에는 이 메서드에 대한 소개가 전혀 없는데요, 이건 TypeORM이 반성해야 할 부분 같습니다. 이 메서드는, QueryBuilder가 가진 문제점을 부분적이나마 해소해줍니다. 코드를 통해 보겠습니다. QueryBuilder 사용법 const posts = await connection .createQueryBuilder(Post, "post") .where('post.author IS NULL') .orderBy("post.id", "ASC") .getMany() post를 조회할 때 우리는 where문과 order를 where, orderBy라는 메서드를 통해 해결할 수 있습..

원래 Repository에서 조인 대상에 대해 IsNull로 체크하는 것은 자잘한 버그들이 있었습니다. IsNull로 할 경우, 사용자가 기대하던 방식대로 동작하지 않았는데, 이게 버그인지 의도인지는 알 수 없었습니다. 그래서 이런 경우는, 차라리 쿼리빌더에서 InnerJoin을 하는 것이 낫다는 판단이었습니다. 어떤 식으로 동작할지 명확한 것이 차라리 낫다는 판단이었습니다. 그러고 나서 몇 달의 시간이 지나니 새로운 업데이트가 나왔습니다. 새 업데이트 내용을 보니, 기존의 코드가 의도된 게 아니라 버그였음을 확인할 수 있겠네요. 이 내용은 issue number #8890에 있는 코드를 그대로 옮겨, 해석을 달은 것입니다. 일단 기존에 코드가 어떤 문제가 있었는지, 예제 코드를 통해 이해해보겠습니다. ..

issue number #8524에서 JoinColumn에서의 제약 조건 이름을 추가하는 법이 추가되었습니다. 이 내용은, 기존의 방식처럼 Entity 위에 @index() 데코레이터를 통해 제약조건을 거는 것보다 명시적입니다. 인덱스 데코레이터의 경우에는 하나의 데코레이터를 이용해 Primary와 복합키, 외래키 등을 모두 표현했습니다. 따라서 그 의미가 무엇을 뜻하는지는 인덱스 데코레이터와 엔티티 칼럼과의 관계를 보고 이해해야 했습니다. issue number #8900에서는 위의 변화와 더불어 Column 데코레이터에서도 제약조건 명시를 허용했습니다. 새로이 명시된 방법은 아래와 같습니다. @Entity() export class Post { @ManyToOne((type) => Category) ..