개요 요새 typescript + express 백엔드를 짠다. 운영에 대해서는 조금도 생각하기 싫어서 AWS Lambda로 배포한다. serverless-http라는 좋은 물건을 쓰면 ex

개요 얼마전에 백엔드/프론트엔드로 구성된 운영툴을 짰다. 백엔드는 typescript + express로 굴러간다. 프론트엔드는 typescript + react로 굴러간다. 양쪽을 같은 언

HTTP 응답에 콘솔 로그 붙인 이유 간단한 express 서버가 있다고 치자. const express = require('express'); const delay = require('delay'); const app = express(); app.get('/', async (req, res) => { const data = await execute(req.query || {}); res.json(data); }); async function execute(input) { const id = input.id; console.info(`before delay: ${id}`); await delay(100); console.warn(`after delay: ${id}`); return {

repository.save() 의 함정 typeorm으로 아래와 같은 엔티티를 정의했다고 치자. @Entity() export class UserEntity { @PrimaryColumn() key1: string; @PrimaryColumn() key2: string; @Column() data: string; } 엔티티를 살짝 고쳐서 저장하자.repository.

로깅의 필요성 요새 작업하고 있는 프로젝트에서 typeorm과 ioredis를 쓰고 있다. 기능이 검증된 코드를 짜기 위해서 유닛 테스트를 도배하고 있다. 하지

타입스크립트에는 union type이 있다. 타입스크립트는 매우 좋은 언어라서 분기를 적절히 처리해주면 union type의 특정 타입으로 한정할 수 있다. 아래의 코드는 string |

배포 환경(Development environment)은 목적에 따라서 각각 다른 스테이지로 소프트웨어 배포하는걸 말한다. 예시로 설명하면 쉬운데 말로

개요 serverless framework은 aws lambda 같은 서버리스 플랫폼에 배포할때 유용한 도구이다. 하지만 serverless framework를 그대로 쓰는건 불편하다. 다행히도 serv

내 경력은 계산하기 매우 쉽다. 2010년 1월 2일에 처음 출근했다. 그리고 다음 주에는 2020년 1월 2일이 있다. 벌써 경력 10년차라니… 그

타입스크립트와 순환 의존성 circular dependency(순환 의존성, circular reference, 순환 참조)는 대부분의 언어에서 발생시킬 수 있는 문제이다. C 에서도 circular dependency 문제가 있다.