INTHEJ.LOG

오늘은 실무에서 node 기반의 API 개발을 하면서 고민했었던 응답처리와 이를 해결했었던 알고리즘 구현에 대해서 포스팅 합니다.

어느날 같이 협업하고 있는 프론트엔드 엔지니어분이 응답 데이터중에서 특정 속성 값이 null 인 경우는 빈값으로 치환해 달라고 요청을 받게되었습니다. API 데이터에서 null 값이 내려와 프론트에서 에러가 난다는 내용과 함께.. 특정 속성필드는 DB 값은 null 이겠지만 응답에서는 빈값으로 치환해달라는 요청이였던 거죠.

요청을 받고 당시 좀 고민을 하였습니다. 과연 null 값을 응답하는 것이 부적절 한가? 에 대한 생각이 들었습니다.
그렇게 생각이 들었던 이유는.. 현재 채택한 스택의 데이터베이스는 NoSQL DB 가 아닌 SQL DB인 MySql 이였기 때문입니다.

차이점을 조금 살펴보면..
SQL (관계형DB) 의 데이터는 정해진 데이터 스키마에 따라 테이블에 저장되게 됩니다. 여기서 중요한건 SQL 은 지정된 틀이 있다는 점입니다. 스키마를 준수하지 않은 레코드들은 테이블에 추가할 수도 없습니다.

반면 NoSQL (비관계형 DB)는 말 그대로 SQL(관계형 DB) 와는 반대입니다. 스키마도 없고 관계도 없습니다. NoSQL 에서는 레코드를 문서(documents) 라고 부릅니다. 이것은 단순히 이름만 다른 것이 아니라, 핵심적인 차이점이 있습니다. SQL 세상에서는 정해진 스키마를 따르지 않는다면 데이터를 추가할 수 없지만, NoSQL 에서는 다른 구조의 데이터를 같은 컬렉션(=SQL에서의 테이블)에 추가할 수 있습니다.

필자는 당시 이에따라 API 응답데이터도 차이가 있어야 하지 않을까? 라고 생각이 들었습니다. SQL 에서는 값이 있던 없던 지정된 스키마의 순수데이터가 응답되는게 맞다는 생각이 들었고. 반면 NoSQL 에서는 속성값이 존재하지 않는다면 response 에서 생략해야 한다는 생각을 갖고 있었습니다.

지금 생각해보면 당시에는 REST API 에 대한 개념이 조금 부족했던거 같습니다..🥲

클라이언트에서 서버의 디비형태를 알수 있게 응답 데이터를 제공할 필요가 있었을까?.. 라는 생각이 듭니다. 

어쨋든 당시에 업무의 요청을 수용하고 싶었고 그래서 그동안 응답데이터들중 null 값을 가진 속성이 있다면 빈값으로 치환해 주는 작업을 진행하게 되었습니다. 

사실 express 에서는 json null 필드를 response 에서 생략하는 방법을 간단하게 제공합니다.

const app = express()
// JSON null 필드 생략
app.set('json replacer', (k, v) => (v === null ? undefined : v))

이렇게 간단한 방법이 있었는데...
제길... 노드와 express의 생태계를 제대로 숙련하지 못한 초보자인 필자는 방법을 알지 못하여 알고리즘을 짜기 시작하였습니다.

객체의 속성값에 접근하여 치환하는 알고리즘을 구현하여 결국 요청을 수용하였습니다. 🥲 모르면 몸이 고생한다는 말을 이런 상황을 두고 하는 말인거 같네요 

필자는 값을 구하는 utils 클래스의 함수를 구현하여 문제를 해결하였는데요.
구현 했던 코드를 한번 살펴보겠습니다.

const ValueUtils = {}

ValueUtils.empty = (str, includeBlank = true) => {
  const empty = str === null || str === undefined || (includeBlank && str === '')
  return empty
}

ValueUtils.nvl = (str, defaultValue = '') => {
  if (ValueUtils.empty(str)) { return defaultValue }
  return str
}

ValueUtils.clearNull = (obj, defaultValue = '') => {
  if (ValueUtils.empty(obj)) { 
    return ValueUtils.nvl(obj, defaultValue) 
  }
  
  if (Array.isArray(obj)) {
    obj.forEach((el) => ValueUtils.clearNull(el, defaultValue))
    return obj
  }

  Object.keys(obj).forEach((key) => {
    if (Array.isArray(obj[key])) {
      obj[`${key}`] = ValueUtils.clearNull(obj[key], defaultValue)
    } else {
      obj[`${key}`] = ValueUtils.nvl(obj[key], defaultValue)
    }
  })
  return obj
}

module.exports = ValueUtils

clearNull 이란 함수는 전달된 obj 의 속성을 접근하여 속성이 비어있는 값을 치환해 주는 역할을 하는 함수입니다.
- 전달된 속성이 있는지 확인
- 속성이 배열인지 확인 -> 배열인 경우는 요소에 접근하여 재귀호출
- Object 인 경우는 속성값이 배열인 경우는 요소에 접근하여 재귀호출, 배열이 아닌경우를 치환값으로 처리하는 로직입니다.

nvl 함수 오라클에서 사용되는 NULL 처리 함수로서 data 값이 null 값일 때 임의 설정값으로 처리해주는 함수를 구현하였습니다.

위 함수를 사용하게되면 아래와 같이 응답데이터중 null, undefined, 빈값등의 데이터를 원하는 값으로 치환해주는 작업을 손쉽게 할 수 있습니다. 🙂

exports.get = async (documentId) => {
  try {
    const responseModel = await Document.findById(documentId)
    return ValueUtils.clearNull(responseModel)
  } catch (err) {
    throw err
  }
}

이번에 다룰 내용은 팩토리 패턴의 캡슐화를 강제할 수 있는 메커니즘에 대해서 내용을 작성하게 되었습니다.
팩토리 패턴 첫번째 내용이 궁금하신분들은 여기를 살펴보세요🙂

팩토리는 클로저 덕분에 캡슐화 메커니즘으로 사용될 수도 있습니다.

캡슐화는 상속, 다형성 및 추상화와 함께 객체지향 디자인의 기본 원칙입니다. 캡슐화는 외부 코드가 컴포넌트의 내부 핵심에 직접 접근하여 조작하는 것을 방지하기 위해 접근을 제어하는 것을 의미합니다. 컴포넌트와의 상호작용은 public 인터페이스를 통해서만 가능하여, 컴포넌트의 상세 구현의 변경으로 부터 외부 코드를 분리시킬 수 있습니다.

JavaScript 에서 캡슐화를 적용하는 주요 방법은 함수에 스코프(Scope)와 클로저(Closure)를 사용하는 것입니다.
팩토리는 쉽게 private 변수들을 강제 할 수 있는데요 코드를 통해 확인해보겠습니다

function createPerson(name) {
  const privateProperties = {}
  
  const person = {
    setName (name) {
      if (!name) {
        throw new Error('A person must have a name')
      }
      privateProperties.name = name
    },
    getName () {
      return privateProperties.name
    }
  }
  
  person.setName(name)
  return person
}

코드에서 팩토리 함수안에 클로저를 사용해서 두 개의 객체를 생성했습니다.
첫번째. 팩토리가 반환하는 퍼블릭 인터페이스인 person 객체
두번째. 외부에서 접근할 수 없고 person 객체가 제공하는 인터페이스만을 통해 접근할 수 있는 privateProperties

마치 class 에서 private 필드를 선언하여 객체를 생성한 방식의 처리를..
팩토리 함수에 클로저를 두어 구현한 코드라고 이해하면 될거 같습니다.
(name 값은 필수값으로 두었기 때문에 생성된 person 객체는 name 속성을 반드시 가지고 있다는 것을 알 수 있습니다.)

이렇게 팩토리에서도 손쉽게 캡슐화 처리를 할 수 있는 메커니즘을 알아 보았습니다.

JS 에서 팩토리에 대한 다양한 방식이 있습니다. 하지만 중요한건 캡슐화를 지킬 수 있다는 매커니즘입니다.
이 방식을 이해했다면 다양하게 응용할 수 있을거 같습니다.

반변 캡슐화의 장점을 모른다면 어떤게 좋은지 이해하지 못한 내용일 수도 있을거 같습니다.
저는 프로그래밍을 하면서 제일 중요하다고 생각하는게 캡슐화라고 생각합니다.
캡슐화에 대한 자세한 내용은 다음번에 한번 정리해보도록 하겠습니다. 🙂

Node.js 에서 가장 일반적인 디자인 패턴은 팩토리(Factory) 패턴이라고 합니다. 사실 저는 팩토리 패턴을 잘 사용하지 않았습니다. 팩토리 패턴에 대해서 알아보고 상황에 따라 잘 사용해보고 싶어 관련 내용을 정리하였습니다.

팩토리 패턴은 매우 다양하며 한가지 이상의 목적을 가지고 있습니다. 주요 장점은 특정 구현으로 부터 객체의 생성을 분리할 수 있고 실행시 생성되는 객체를 결정할 수 있습니다. 그리고 캡슐화 처리에 좀 더 좋습니다.

우선 이번 포스터에서는 객체 생성과 구현의 분리에 관한 내용을 다뤄보겠습니다.

JavaScript 에서 단순성, 유용성 및 작은 노출 면으로 인해 순수한 객체지향 디자인 보다 함수형 방식이 더 선호됩니다. 특히 새로운 객체의 인스턴스를 만들 때 그렇습니다. 실제로 new 연산자 혹은 Object.create() 를 사용하여 클래스로부터 새로운 객체를 만드는 대신에 팩토리 함수를 호출하는 것이 여러 측면에서 훨씬 더 편리하고 유연할 수 있습니다

무엇보다 팩토리 패턴을 사용하게 되면 객체 생성과 구현을 분리할 수 있고 특정 조건에 따라 다른 유형의 객체를 반환하도록 할 수도 있습니다.

Image 객체를 생성하는 간단한 코드를 한번 살펴 보겠습니다.

function createImage(name) {
  return new Image(name)
}
const image = createImage('sample.jpeg')

위 createImage() 함수는 전혀 불필요하게 보입니다. 왜 new 연산자를 사용해 직접 인스턴스를 생성하지 않았을까 라는 생각이 들정도로 그렇습니다. 그냥 아래와 같이 작성해도 되지 않았을까요?

const image = new Image('sample.jpeg')

하지만 new 를 사용하면 코드를 특정 유형의 객체에 바인딩 하게 됩니다.
이미지 형식마다 하나의 클래스를 지원하기 위해 Image 클래스를 더 작은 클래스로 분할한다고 생각해 볼 경우 팩토리 함수로 생성한 경우는 기존 사용된 코드들은 전혀 손댈 필요 없이 다음과 같이 함수에 구현된 코드만 수정하면 됩니다.

function createImage(name) {
  if (name.match(/\.jpe?g$/)) {
    return new ImageJpeg(name)
  } else if (name.match(/\.gif$/)) {
    return new ImageGif(name)
  } else if (name.match(/\.png$/)) {
    return new ImagePng(name)
  } else {
    throw new Error('Unsupported format')
  }
}

위와 같이 관련된 객체 생성을 묶어서 관리할 수 있고 또한 클래스를 숨겨, 멋대로 확장하거나 수정하는 것을 막아줍니다. 이것은 캡슐화의 이점이라고 할 수 있습니다.
JavaScript 에서는 팩토리만 사용하도록 함으로써 클래스를 비공개로 유지할 수 있다고 합니다.

팩토리에 관한 첫번째 포스터는 여기까지 작성하고 다음 포스터에서 내용 이어가겠습니다. 🙂

이번에 작성하는 포스트는 최근 현업에서 서비스를 개발하는데 알아보았던 Promise 재시도 디자인패턴에 관한 것입니다.

서비스를 개발할적에 우리는 빈번하게 서드파티 API 를 사용하게 됩니다. 제가 개발하고 있는 서비스는 AWS 와 토스 페이먼츠 등을 사용하고 있습니다. 서드파티 측에서 문제가 발생되어 잠시동안 API 호출이 안되는 경우가 존재할 수 있다면 우리는 이것에 어떻게 대처해야 할까요?

저는 이러한 경우 API 호출을 재시도 하는 방식으로 해결해야 겠다고는 생각했지만 .. 사용성과 관리가 용이한 방식을 잘 알지 못했습니다. 그러다 최근 괜찮다고 생각되는 방법을 알게 되어 글을 작성합니다.

사실 비동기 스트리밍은 선언적 프로그래밍 형태를 가진 Rxjs 라이브러리를 사용하는게 좋은 선택으로 보였지만 현재 프로젝트에서는 순수 Promise 를 기반으로 API 와 DB를 호출하고 있어 가능하다면 이를 유지하는 방향으로 통일성을 지키고 싶었습니다.

결국 API 호출 로직을 감싸는 방식을 사용하였는데요.

코드를 살펴보면..

// PromiseService.js

class PromiseService {
  static #instance
  
  static getInstance() {
    if (!this.#instance) {
      this.#instance = new PromiseService()
    }
    return this.#instance
  }
  
  /**
   * @param promise A promise to resolve
   * @param nthTry Number of tries before rejecting
   */
  retryPromise(promise = () => {}, nthTry = 1) {
    try {
      const data = promise()
      return data
    } catch (e) {
      if (nthTry === 1) { return Promise.reject(e) }
      return this.retryPromise(promise, nthTry - 1)
    }
  }
  
  /**
   * Util function to return a promise which is resolved in provided milliseconds
   */
  waitFor(milliSeconds = 1000) {
    return new Promise((resolve, reject) => {
      setTimeout(() => {
        resolve()
      }, milliSeconds)
    })
  }
  
  async retryPromiseWithDelay(promise = () => {}, nthTry = 1, delayTime = 1000) {
    try {
      const res = promise()
      return res
    } catch (e) {
      if (nthTry === 1) { return Promise.reject(e) }
      await this.waitFor(delayTime)
      return this.retryPromiseWithDelay(promise, nthTry - 1, delayTime)
    }
  }
}

module.exports = PromiseService

서비스 파일에서는 호출 재시도(retruPromise, retryPromiseWitHDelay) 메서드를 제공하고 재시도 횟수만큼 재귀하는 방식으로 구현하였습니다.

사용 코드를 살펴보면..

async function main() {
  try {
    const promiseService = PromiseService.getInstance()
    const resposne = await promiseService.retryPromiseWithDelay(
      () => axios.get('https://api.twitter.com/v1/user/1234'), // promise
      4, // retry
      2000 // delayTime
    )
    return response
  } catch (e) {
    throw e
  }
}

main()

단순하게 선언적으로 Promise 와 파라미터만 입력하면 되기때문에 사용법이 쉽고 관리가 용이한 방식 같습니다.

async / await 를 사용하여 일련의 작업들을 병렬로 실행하는 방법은 크게 2가지가 있습니다.
하나는 순수하게 await 표현식을 사용하는 것이고 다른 하나는 Promise.all()에 의존하는 것입니다.
2가지 모두 구현하기 간단합니다. 그러나 Promise.all() 을 사용하는 방법을 권장합니다. 🙂

우선 순수하게 await 표현식을 사용해서 무제한 병렬 비동기 실행 흐름을 구현하려면 다음과 같은 코드로 구현할 수 있습니다.

async function spiderLinks(currentUrl, content, nesting) {
  if (nesting === 0) { return } 
  
  const links = getPageLinks(currentUrl, content)
  const promises = links.map(link => spider(link, nesting - 1))
  for (const promise of promises) {
    await promise
  }
}

매우 간단합니다. 이게 전부입니다. 앞의 코드에서 모든 spider() 작업을 병렬로 시작하였고 map()을 사용하여 실행된 작업들의 Promise를 수집합니다. 그리고 나서 Loop 를 돌며 각각의 Promise 를 await 합니다.

처음엔 이것이 깔끔하고 기능적으로 보이지만 생각하지 않은 부작용이 있습니다. 바로 promises 배열에 어떤 Promise 가 문제가 발생하여 거부가되면 spiderLinks()에서 반환된 Promise도 거부되게 되는데 배열내의 모든 선행 Promise들이 해결될 때까지 기다려야 합니다.
일반적으로 작업의 실패를 최대한 빨리 알기 원하기 때문에 이것은 모든 상황에서 최선의 방법이 아니고 비효율적인 방법입니다.

다행히도 원하는 방식으로 정확하게 동작하는 Promise.all() 이라는 내장 함수로 문제를 해결 할 수 있습니다.
실제로 Promise.all() 은 입력 배열에 제공된 Promise 중 하나가 거부되는 즉시 거부합니다.
그리고 Promise.all() 은 또 다른 Promise만 반환하기 때문에 여러 비동기 작업에서 결과를 얻기 위해 await 을 사용할 수 있습니다.

const results = await Promise.all(promises)

결론적으로 병렬 실행 및 async / await 를 사용하는 spiderLinks() 함수의 구현은 다음과 같이 작성 할 수 있습니다.

async function spiderLinks(currentUrl, content, nesting) {
  if (nesting === 0) { return }
  
  const links = getPageLinks(currentUrl, content)
  const promises = links.map(link => spider(link, nesting - 1))
  return Promise.all(promises)
}

처음 로직과 다르게 Promise.all() 함수를 사용했으며 이는 promises 배열에 어떤 Promise 가 문제가 발생하여 거부가 발생되면 즉시 거부 되도록 처리되므로 효율적으로 동작됩니다.

오늘은 실무에서 자칫하면 실수 할 수 있는 비동기 이해에 관한 글을 작성합니다.
return Promise 에 대한 내용인데 이는 개발자들이 빈번하게 실수하는 흔한 안티패턴 중 하나입니다.

내용은 즉 async / await와 함께 에러를 다룰 적에 호출자에서 Promise 를 반환하게 하고 Promise 를 반환하는 함수의 로컬 try...carch 블록에서 에러가 잡히는 것을 기대하는 것입니다.

코드로 살펴보면

async function errorNotCaught() {
  try {
    return delayError(1000)
  } catch (err) {
    // 영원히 호출되지 않는다
    console.error('Error caught by the asycn function: ' + err.message)
  }
}

errorNotCaught()
	.catch(err => console.log('Error caught by the caller: ' + err.message))
    
// 실행결과: Error caught by the caller: Error after 1000ms

delayError() 에 의해 반환되는 Promise는 로컬에서 기다리지(await) 않습니다. 즉, 호출자에게 반환되고 결과적으로 로컬의 catch 블록은 영원히 호출되지 않습니다.

만약 호출자가 비동기 작업에 의해서 발생하는 값뿐만 아니라 에러까지 로컬에서 포착할 수 있도록 만들고 싶다면, 반환될 Promise 앞에 await 표현식을 사용해야 합니다.

async function errorNotCaught() {
  try {
    return await delayError(1000)
  } catch (err) {
    console.error('Error caught by the asycn function: ' + err.message)
  }
}

errorNotCaught()
	.catch(err => console.log('Error caught by the caller: ' + err.message))
    
// 실행결과: Error caught by the asycn function: Error after 1000ms

return 키워드 뒤에 await 을 추가하는 것 만으로 async 함수가 Promise를 로컬에서 처리하게 되므로 문제를 해결 할 수 있습니다. 🙂

일부 원칙과 디자인 패턴들에는 Node.js 플랫폼과 생태계에 대한 개발자의 경험이 제대로 녹아있다. 가장 특별하게 생각할 수 있는 것은 아마도 콜백과 프라미스와 같은 비동기적 구성이 많이 사용되었다는 점이다.  Node.js를  특별하게 만드는 중요한 측면들 중 하나는 그것의 철학이다. Node.js를 알아가는 것은 단순히 새로운 기술을 배우는 것이 아니라 Node.js 가 가진 문화와 커뮤니티를 받아들인다는 의미를 갖는다.

Node.js 철학

모든 프로그래밍 플랫폼은 자신들만의 철학, 커뮤니티에서 따르게 되는 일련의 원칙들과 지침, 플랫폼의 진화와 애플리케이션 개발 및 디자인에 영향을 주는 이데올로기를 가지고 있다. 이러한 규칙들은 강제적인 것이 아니며 항상 따를 필요도 없지만 우리들이 소프트웨어를 디자인하는 데에 있어 영감을 얻고자 할 때 많은 도움이 된다.

1. 경량 코어

Node.js 코어는 몇 가지 원칙들을 기반으로 자신의 기초를 구성하였다. 그 중 한 가지는 최소한의 기능 세트를 가지고 코어의 바깥 부분에 유저랜드(userland) 혹은 유저스페이스(userspace)라 불리는 사용자 전용 모듈 생태계를 두는 것이다. 이 원칙이 Node.js 문화에 엄청난 영향을 주었고 그 영향으로 엄격하게 관리되어 안정적이지만 느리게 진화하는 해결책을 갖는 대신 커뮤니티가 사용자 관점에서의 폭넓은 해결책을 실험해볼 수 있는 자유를 주었다. 코어를 최소한의 기능 세트로 관리하는 것은 관리의 관점에서 편리할 뿐 아니라 전체 생태계 진화에 있어 긍정적인 문화적 영향을 미칠 수 있다.

2. 경량 모듈

Node.js 는 프로그램 코드를 구성하는 기본적인 수단으로 모듈 개념을 사용한다. 모듈은 애플리케이션과 재사용 가능한 라이브러리를 만들기 위한 구성 요소이다. Node.js 에서 가장 널리 통용되는 원칙 중 하나는 코드의 양뿐 아니라 범위 측면에서도 작은 모듈을 디자인하는 것이다. 이 원칙은 Unix 철학에 근거하는데, 특히 다음의 두 가지 수칙이 있다.

• "작은 것이 아름답다."
• "각 프로그램은 한 가지 역할만 잘하도록 만들어라."

Node.js 는 패키지 관리자(npm, yarn)의 도움을 받아 각 패키지가 자신이 필요로 하는 버전의 종속성 패키지들을 갖도록 함으로써 종속성 지옥에서 벗어나게 해 준다. 이러한 측면은 패키지가 충돌의 위험 없이 잘 집중화되고 많은 수의 작은 종속성을 가질 수 있도록 해준다. Node.js 에서는 이러한 관행이 표준이고 재사용성 측면을 향상시켜 준다.

작은 모듈은 재사용성이라는 장점 외에도 다음의 장점이 있다.

• 이해하기 쉽고 사용하기 쉽다.
• 테스트 및 유지보수가 쉽다.
• 사이즈가 작아 브라우저에서 사용하기에 완벽하다.

더 작고 집중화된 모듈을 갖는 것은 모두에게 공유와 재사용을 가능하게 해준다. 이것은 완전히 다른 수준에 적용된 Don't Repeat Yourself(DRY) 원칙이다

3. 작은 외부 인터페이스

Node.js의 모듈들이 갖는 장점은 작은 사이즈와 작은 범위 그리고 최소한의 기능 노출이다. 이러한 것들이 명확하게 사용될 수 있고 잘못된 사용에 덜 노출되도록 하는 API 생산 효과를 갖는다. Node.js 에서 모듈을 정의하는 가장 일반적인 패턴은 명백한 단일 진입점을 제공하기 위해서 단 하나의 함수나 클래스를 노출시키는 것이다.

Node.js의 많은 모듈들의 특징 중 또 다른 하나는 그들이 확장보다는 사용되기 위해서 만들어졌다는 것이다. 확장의 가능성을 금지하기 위해 모듈 내부 접근을 제한한다는 것이 덜 유연하다고 생각되지만 사실은 유스케이스를 줄이고, 구현을 단순화하며, 유지관리를 용이하게 하고, 가용성을 높인다는 장점들을 가지고 있다.

4. 간결함과 실용주의

완벽하고 모든 기능을 갖춘 소프트웨어와는 반대로 단순하게 설계하는 것이 좋은 실천이다. 구현을 위해서 적은 노력이 들고, 가벼워서 빨리 보급 가능하며, 유지보수가 쉽고 빠른 이해가 가능하다. 이러한 요인들이 커뮤니티의 기여를 보다 용이하게 하고 소프트웨어 자체의 성장과 향상을 돕는다.  Node.js 에서 이 원칙이 채택되는 것에 가장 큰 영향을 준 것은 JavaScript이다. 사실 우리의 소프트웨어가 항상 현실의 근사치이며, 우리는 많은 노력과 유지보수가 필요한 엄청난 양의 코드로 완벽에 가까운 소프트웨어를 만들어 내려고 애쓰는 것보다 합리적인 복잡성을 가지고 빠르게 일할 때 더 많은 성공을 이뤄낼 것이다. 싱글톤이나 데코레이터와 같은 상당수의 전통적인 디자인 패턴을 완전하지는 않더라도 간단하게 구현할 수 있으며, 대부분의 경우 완전하고 완벽한 설계보다 복잡하지 않은 실용적인 접근 방식이 얼마나 선호되는지 보게 될 것이다.