Jacob's Development Blog

파일 시스템 관련 개발하던 중, MongoDB에 재밌는 컬렉션이 있어서 기록을 남겨본다. 민감 정보가 있는 다운로드 내역이라면, signedUrl로 일정 시간만 다운로드를 가능하게 하고 일정 기간이 지나면 완전히 컬렉션에서 사라지게 한다면 조금 더 안전한 운영이 가능하지 않을까? 또는 일정 기간만 로깅용으로 데이터를 보유하고 그 이후에는 사용하지 않는다면, 이 컬렉션은 매력적일 거 같다. TTL 컬렉션(Time-To-Live) MongoDB는 컬렉션에서 특별한 인덱스를 사용하여 구현한, 특정 시간이 경과한 도큐먼트를 자동으로 제거(remove)시킬 수 있는 기능을 제공한다. 위 명령을 통해 lastModifiedDate에 인덱스를 생성하게 된다. TTL 인덱스를 생성하는 조건은 날짜 또는 날짜 값을 포함..

현 회사에서 GraphQL + mongoDB를 사용하다 보니, (물론 관계형 데이터 베이스도 사용하지만) 몽고 디비의 관한 내용을 얼추 알지만, 조금 더 정리하고 싶어서 시작한 포스팅. 얼른 뽀개자. MongoDB란? MongoDB는 도큐먼트 지향적인 데이터베이스다. NoSQL (비관계형 데이터베이스)로 JSON Type의 데이터 저장 구조를 가지며, Memory Mapping 기술을 기반으로 Big Data 처리에 탁월한 성능을 제공하고 있다. 또한 시스템 장애가 발생하더라도 안전하게 데이터를 보관하고 운영할 수 있도록 샤딩(분산, Sharding)과 레플리카(복제, Replica)를 제공하고 있다. 좀 더 자세한 내용은 이후에 설명하도록 하겠다. 내부적으로 MongoDB는 Binary JSON 혹은 ..

업무 규칙 업무 규칙에는 여러 가지가 존재한다. 업무 규칙이란 쉽게 말하면 사업적으로 수익을 얻거나 비용을 줄일 수 있는 규칙 또는 절차이다. 컴퓨터상으로 구현했는지 여부는 중요하지 않다. 예를 들어 대출에 N%의 이자를 부과한다는 사실은 은행이 돈을 버는 업무 규칙이다. 이것을 컴퓨터가 계산하건 직원이 계산하건 중요하지 않다. 그리고 이러한 규칙을 클린 아키텍처에서는 핵심 업무 규칙(Critical Business Rule)이라고 부른다. 사업 자체에 핵심적이며, 규칙을 자동화하는 시스템이 없더라도 업무 규칙은 그래도 존재하기 때문이다. 이러한 핵심 규칙은 보통 데이터를 요구한다. 예를 들어 대출에는 대출 잔액, 이자율, 지급 일정이 필요하다. 클린 아키텍처에서는 이를 핵심 업무 데이터(Critical..

클린 아키텍처를 읽으며 정리 중이다. 봐도 봐도 좋은 책인 거 같다(까먹는 내가 문제지만...). 꼭 이 책에 의존적인 내용을 다루진 않겠지만 기초는 클린 아키텍처에 두고 있다고 알고 보면 좋을 거 같다. REP: 재사용/릴리스 등가 원칙(Reuse/Release Equivalence Principle) CCP: 공통 폐쇄 원칙(Common Closure Principle) CRP: 공통 재사용 원칙(Common Reuse Principle) REP: 재사용/릴리스 등가 원칙 재사용 단위는 릴리스 단위이다. 효과적인 재사용을 위해서는 변경 제어 시스템에서 릴리스를 추적해야 한다. 패키지는 효과적인 재사용 및 해제 단위이다. 소프트웨어 컴포넌트가 릴리스 절차를 통해 추적 관리되지 않거나 릴리스 번호가 부여..

이번 글은 MobX의 사용에 관한 부분이나 코드 등을 다루진 않는다. 그냥 배워보기 전에 약간의 배경지식(?)이라고 하면 될 거 같다. 꼭 필요한 글은 아니니, 궁금하지 않다면 바로 다음 글을 읽어봐도 좋다. 시작 전 넋두리.. 리액트로 앱을 만들면서 얼마 안돼, 우리는 상태 관리에 대한 고민을 시작한다. 특정 컴포넌트의 상태 값을 다른 컴포넌트와 공유하고 싶다는 생각이다. 그래서 처음에는 prop을 통해 상위 컴포넌트로 상태 값을 전달하기 시작한다. 물론 매우 훌륭한 방법이다. 하지만, 또다시 위기에 봉착한다. 컴포넌트가 많아지고 그 깊이가 깊어질수록 상태 값을 전달하는 게 너무 복잡해지기 때문이다. Redux is a predictable state container for JavaScript app..

아래 그림은 내가 평소에 사용하던 github branching stategy이다. 이슈마다 feature 브랜치를 생성 후 마스터 브랜치에 merge 하는 방식이다. 경우에 따라서 여기에 develop 브런치나 release 브런치를 추가로 만들어 관리하는 경우가 있다. 이 방식은 git branching stategy보다 적용하기 쉬워 평소에도 협업할 일이 있다면 이 방식으로 많이 사용하는 편이다. 다른 것들을 검토하기 전에 먼저 내가 자주 사용하던 GitHub Flow를 먼저 살펴보자. 이슈 관리툴(Jira 등)에서 백로그(BackLog)를 확인하고 작업할 내용을 선택한다. 개발자는 master에서 새 브랜치(feature)를 만들고 작업을 한다. 원하는 지점에서 commit하고 push 하며 이를..

집에도 가고 이번주만 쉬자.

RxJS는 파일 읽기, HTTP 호출, 키 입력 또는 마우스 움직임 등의 이벤트 데이터 소스를 처리하는 단일 프로그래밍을 사용하여 콜백 또는 Promise 기반 라이브러리를 정확히 같은 방식으로 대체한다. 그리고 RxJS를 사용하면 시간 경과에 따라 분리된 대용량 데이터를 보다 간결하고 선언적으로 처리할 수 있다. 파이프라인은 데이터를 사용할 수 있을 대 순서대로 실행되는 일련의 로직 영역(비즈니스 로직 영역)이다. 그리고 왼쪽에 있는 웹은 이벤트 생성자이며, 애플리케이션에서 소비될 다양한 형태의 데이터를 생산하는 데이터 소스가 있는 곳이다. 소바자는 받은 데이터로 무엇인가를 하거나 이벤트들을 구독하는 개체이다. 마지막으로 파이프라인에 스트림을 변환한다고 써있는데, 스트림은 시간에 따라 발생하는 일련의 ..

2020/01/27 - [Javascript] - 1부 - 자바스크립트 함수 표현식, IIFE 그리고 비동기 2020/01/28 - [Javascript] - 2부 - 자바스크립트 비동기적 프로그래밍(콜백, 프라미스) 이미 앞에서 콜백(callback)과 프라미스(promise)라는 멋진 개념들을 살펴봤다(asnyc await는 나중에 살펴볼 것이다). 그런데 궁금해 진다. 웹이 커지며 여러 요구 사항이 등장하여 여러 콜백을 중첩시켜 연속 전달 스타일(CPS, Continuation-Passing Style)을 사용했다. 그리고 가독성부터 코드 추측이 어렵기 때문에 ES6에서는 FP(Functional Programing) 패턴을 따른 Promise을 대안으로 제시했다. 그런데 왜 RxJS를 공부해야 할..

사실 이 주제는 자바스크립트에만 종속된 이야기는 아니지만, 대부분의 개념을 자바스크립트를 통해 설명할 것이기 때문에 자바스크립트라는 카테고리에 위치시켰다. 동기(Synchronous) vs 비동기(asynchronous) 동기와 비동기로 작성한 코드의 가장 큰 차이 중 하나는 런타임(runtime)시에 발생하는 지연시간(latency)이다. 모든 코드가 동기적으로(순서대로만) 실행된다면 어떤일이 벌어질까? 내가 만약 메시지를 보낸다고 하면 메시지를 보내고 응답이 오기까지 아무것도 할 수가 없다. 왜냐하면 앞에 작업이 아직 안 끝났기 때문이다. 물론 이런 방식이 전혀 사용이 안되는 것은 아니다. ATM 기계, 키오스크, 단순 단말기 같은 방식은 이런 동기적인 방식을 따르고 있다. 동기적 방식의 장점은 코드..