세상엔 배울 게 많다

PUT vs PATCH

djunnni — Fri, 13 Oct 2023 00:26:13 +0900

PUT vs PATCH

PUT과 PATCH 모두 리소스에 변화를 주고 있다. 따라서 resource 관점에서는 safe하지 않은 메서드다.

2가지 방식에 대해 다음 관점들로 이해해 볼 필요가 있다.

3가지 관점

1. update

리소스에 대해 직접적으로 접근할 수 있는 Key 값이 있다고 해야한다.
ex) products?id=2

PUT : resource에 대해 전체 내용을 바꾸며, 리소스에서 지원하는 필드가 비어있다면 nullable 하다.
PATCH : resource에서 일부분을 수정하며, 리소스에서 정의된 필드만 바꾼다.

ex) PUT
{ item: '아이폰 XS', price: 100000, color: 'spaceGray' } 가 있다.

put를 통해 API를 수정해보자.

{ item: '아이폰 XS', price: 4000, color: 'spaceGray' } -> { item: '아이폰 XS', price: 4000, color: 'spaceGray' }
{ item: '아이폰 XS' } -> { item: '아이폰 XS', price: null, color: null }

ex) PATCH
{ item: '아이폰 XS', price: 100000, color: 'spaceGray' } 가 있다.

patch를 통해 API를 수정하자.

{ item: '아이폰 X' } -> { item: '아이폰 X', price: 100000, color: 'spaceGray' }
{ item: '아이폰 XS', price: 100000, color: 'white' } -> { item: '아이폰 XS', price: 100000, color: 'white' }

2. resource가 없을 시,

리소스에 대해 직접적으로 접근할 수 있는 Key 값이 있다고 해야한다.
ex) products/iphone

PUT: 리소스가 없다고 판단해 새롭게 추가한다.
PATCH: 리소스가 없다고 판단하고 생성하지 않는다.

3. 멱등성

PUT -> resource에 대한 changed resource를 변경하는 것
PATCH -> resource에 대해 변경을 request하는 것

그렇기 때문에 patch는 resource를 다루지 않는다는 의미에서 idempotent(멱등)하지 않다라고 보는 것이지 resource 타입으로 보면 멱등하다고도 볼 수 있다. 즉 멱등하게 운영해도 된다.

참고

https://www.qu3vipon.com/idempotence-of-patch
https://datatracker.ietf.org/doc/html/rfc5789#section-2

S3에 올린 데이터를 기간이 지나고 난 뒤 자동삭제 하는 방법

djunnni — Mon, 9 Oct 2023 13:23:27 +0900

들어가며,

AWS S3에 올린 객체가 특정 날짜에 삭제되거나 몇일이 지나 삭제가 됐으면 좋겠다고 생각할 때가 있다.

이 경우 어떻게 해야 되는지 살펴보자

1. S3 Bucket LifeCycle Rule을 설정

S3 LifeCycle Rule은 객체 자체에 Rule을 설정할 수 없어 Bucket 단위로 설정이 가능하다.

batch 작업으로 유저가 등록한 파일을 자동 제거하는 규칙을 설정한 rule이 있다.

생명주기 이름을 기입한다.
규칙 범위를 선택한다.
- 하나 이상의 필터로 이 규칙을 범위 제한
- 버킷의 모든 객체에 적용
필터 유형 설정
- 객체 태그 추가
객체 크기 제한 가능
수명 주기 규칙 작업 설정
- 스토리지 간 현재/이전 버전 이동
- 객체에 현재 버전 만료
  - 설정하고 싶은 기간의 일 수를 기입합니다. ex) 7
- 객체의 이전버전 영구 삭제
  - 객체가 최신이 아닌 버전이 된 후 경과한 일수 필드에 "1"을 입력합니다.
  - 모든 버전을 삭제하고 싶다면 유지할 최신 버전 수 필드를 비우세요.
- 만료된 객체 삭제 마커 또는 완료되지 않은 멀티파트 업로드 삭제 현재 버전 만료와 함께 사용 불가

추가적인 내용은 여기서 볼 수 있습니다.

NestJS에서는 어떻게 사용할 수 있을까?

권한 여부 확인

s3PutObject
s3DeleteObject
s3PutObjectTagging
s3RequestObjectTag

2. c3api에 적용된 Upload 방법을 이용해서 설명함

tagging을 통해 추가가 가능하다. tagging은 key=value 형태로 여러개를 넣고 싶으면 &을 추가해야한다.
ex) expiration_day=7&delete=force

const upload = new Upload({
      client: this.s3Client,
      params: {
        Bucket: bucketName,
        Key: key,
        Body: Readable.from(file.buffer),
        ContentType: file.mimetype,
        ACL: acl ?? 'private',
        ...(expires && { Expires: expires }),
        ...(tagging && { Tagging: tagging }), // TAG 설정 'expiration_day=7'
      },
    });

참고

https://repost.aws/ko/knowledge-center/s3-empty-bucket-lifecycle-rule

https://medium.com/@dnorth98/using-s3-batch-to-tag-data-for-removal-a569fef7ac0

S3에서 Presigned URL 사용하기

djunnni — Mon, 9 Oct 2023 13:22:29 +0900

Presigned URL 적용 이전까지 일반적인 파일 업로드 상황

서비스에서 이전까지 S3와 관련된 SDK를 통해 stream이나 메모리에 올려둔 파일을 업로드 했다.

이 경우에는 다음과 같은 단점이 존재하게 된다.

서버에서 파일업로드 외에도 다양한 API 작업을 수행할텐데 파일업로드에 리소스(메모리, CPU)를 사용하게 된다.
Network Traffic 비용이 서버로 이동할 때, AWS로 전달할 때 2중으로 쓰인다. (AWS 등의 정책에 따라 무료일 수 있다.)

Presigned URL은 어떤 일을 하나?

미리 서버에서 파일이 업로드 될 것을 예상하고 params를 가지고 있는 URL을 하나 생성한다.
URL을 Client에게로 전달해 유저가 직접 AWS로 파일 업로드 or 다운로드를 가능하도록 조치한다.

얻을 수 있는 장점

서버의 리소스를 사용하지 않고 업로드가 가능하다. (제일 큰 장점이 아닐까 싶다)
Lambda나 별도의 서비스를 활용해 추가처리를 할 수 있다. (크게 와닿진 않음)

EUC-KR 인코딩을 사용하는 서버와 통신하기

djunnni — Mon, 9 Oct 2023 13:07:05 +0900

1. 문제 상황

NestJS로 서비스하고 있는 데 토스페이먼츠의 에스크로 등록 API는 EUC-KR 인코딩이 되어있다. 그로 인해 정상적으로 등록되지 못해 의도하지 않는 결과를 얻게 되었다.

이 문제를 파악하기 위해 공부했던 내용은 https://djunnni.tistory.com/10 에서 확인할 수 있습니다.

"정보 없음" 이 UTF-8에서 EUC-KR로 변환에 실패해 의도치 않는 결과가 나왔다

2. 기존 환경

NestJS 공식 문서에서 제공하고 있는 HttpModule을 이용해 외부 API를 호출하고 있다.

https://docs.nestjs.com/techniques/http-module

3. Axios의 application/x-www-form-urlencoded 처리 과정

httpModule은 내부적으로 axios를 사용하고 있다. Content-Type을 application/x-www-form-urlencoded로 설정하고 POST를 보내고 있다. 외부 라이브러리를 사용하고 있어 어떻게 요청을 처리하는 지 확인할 필요가 있다.

@nestjs/axios의 package.json을 확인하면 axios 1.5.0 버전을 사용하고 있다. axios의 github code로 dive 해보자.

README에서 제공하고 있는데 기본적으로 URLSearchParams를 활용하고 있으며 JavaScript Object를 JSON으로 직렬화해주고 있다.

axios application/x-www-form-urlencoded 설명

이제 코드로 확실하게 확인해보자. axios/lib/defaults/index.js 를 확인해보면 transformRequest 함수가 존재하는데 요청에 대해서 데이터를 변환해주는 함수다.

axios/lib/default/index.js 일부

여기서 우리가 볼만한 정보는 3가지였다. 첫번째는 URLSearchParams를 사용하는 지 검증하는 부분과 isObjectPayload 여부를 확인하는 부분 그리고 Buffer 또는 File, Blob이면 그대로를 반환한다.

isObjectPayload는 toURLEncodedForm을 호출하는데 아래와 같은 함수로 구성되어 있다.

toFormData는 data를 platform.classes.URLSearchParams으로 바꾸기 위해 visitor라는 option을 전달하여 생성하고 있다.
node환경에서 value가 버퍼면 base64로 추가하는 의도로 보인다.

axios url encoded form

3.1 URLSearchParams의 변환하는 방식

https://url.spec.whatwg.org/#interface-urlsearchparams 에서 class interface를 확인할 수 있다.

URLSearchParams는 URL의 query string을 만들어주는 utility method다. URLSearchParams은 Record 형태로 key-value 쌍으로 삽입이 가능하다. URL은 영어, 숫자, 기타 특수기호를 제외한 나머지는 %기호를 사용해 hex 코드로 변환된다.

따라서 URLSearchParams에 한글이 들어가면 hex코드로 변환된 형태로 output을 받는다고 이해하면 된다. 이 변환하는 과정에서 선행조건으로 배워둬야 할 것은 encodeURI와 encodeURIComponent 다.

3.1.1 encodeURI

아래 문자를 제외한 나머지를 전부 이스케이프 처리합니다.

A–Z a–z 0–9 - _ . ! ~ * ' ( )
; / ? : @ & = + $ , # -> URI 구문의 일부일 수 있음.

3.1.2 encodeURIComponent

아래 문자를 제외한 나머지를 전부 이스케이프 처리합니다. encodeURI와 달리 URI 구분자를 이스케이프하면서 value를 있는 그대로 서버로 보내줄 수 있습니다. 만약에 "lag&born"을 보내고 싶다면 encodeURIComponent를 사용해야 정확한 값을 보낼 수 있게 됩니다.

A–Z a–z 0–9 - _ . ! ~ * ' ( )

URLSearchParams에서는 key와 value 모두 encodeURIComponent로 인코딩되어 처리가 됩니다. 간단하게 코드를 테스트해보면 쉽게 알 수 있습니다.

const params = new URLSearchParams();
params.append("name&age", "daniel&25")

console.log(params.toString()) // name%26age=daniel%2625

정리해보면 axios는 application/x-www-form-urlencode에서 object 또는 urlSearchParams로 들어온 데이터를 urlSearchParams로 바꾼다. urlSearchParams는 encodeURIComponent를 사용해 key와 value를 인코딩한다. 인코딩은 UTF-8이 기본이다.

4. 어떻게 axios post를 호출해야 될까?

axios에서 urlSearchParams을 통해 UTF-8로 인코딩되는 건 좋지만 우리에게 필요한 건 EUC-KR입니다.

axios는 Buffer, Stream일 경우에는 그대로 data를 반환하도록 되어있습니다. 그 말은 body로 넣을 부분에 처음부터 EUC-KR로 들어간 Buffer를 전달하면 그대로 전달이 됩니다.

private async escrowAxios(url: string, obj: Data): Promise<string> {
    const { data } = await firstValueFrom(
      this.httpService
        .post<string>(url, converToBuffer(obj), { // convertToBuffer 목표: obj를 받아 euc-kr이 적용된 버퍼를 반환한다.
          headers: {
            'Content-Type': 'application/x-www-form-urlencoded',
          },
          responseType: 'arraybuffer',
        })
        .pipe(
          catchError((error: any) => {
            return of({ data: error.message });
          }),
        ),
    );
    return iconv.decode(data, EUC_KR);
  }

이제 convertToBuffer를 구현하는 함수를 작성하면 완료가 됩니다.

5. convertToBuffer 목표

1. 일단 목표는 Buffer로 변하는 과정에서 Buffer에 들어있는 데이터는 EUC-KR을 통해 변환이 되어야 합니다.

2. body에 들어가는 데이터는 URLSearchParams의 결과 형태처럼 도출해야합니다.

key=value&key2=value2

3. 제공하는 API에서는 key에 들어가는 경우는 모두 영어이며 외부로부터 직접적인 위해를 가하지 못하기 때문에 value에 대해서만 검증을 하고 변환작업을 수행하면 됩니다.

5.1 코드 구현하기

/**
 * data를 받아 EUC-KR 문자열로 변환합니다.
 */
function convertToEucKrBuffer(obj: Data): string {
	let buffer = '';
	Object.entries(data).forEach(([key, value]) => {
      // iconv로 EUC-KR로 변환한 데이터를 HEX(16진수) String을 받아 2칸씩 자릅니다.
  	buffer += 
		`${key}=${appendPercentPer2Byte(
			iconv.encode(value, EUC_KR).toString('hex')
			)
		}&`;
	});

	return buffer.slice(0, -1);
}

/**
 *  HEX(16진수) String을 받아 2칸마다 % 기호를 추가합니다.
 */
function appendPercentPer2Byte(str: string): string {
	return [...value].reduce((acc, cur, idx) => {
		if (idx % 2 === 0) {
			return `${acc}%${cur}`;
        }
		return `${acc}${cur}`;
	}, '');
}

5.2 처리하면서

1. iconv-lite에서 encoding을 통해 출력을 해보면 Buffer에 잘 들어간다. 하지만 toString을 해보면 '%' 기호가 빠진다. 별도로 추가해줘야 한다.

2. JS에서 console.log 할 때, ? 표시가 뜨는 이유는 해당 인코딩을 지원하지 않아 발생하는 문제일 수 있다. 그럴 땐, decode 사이트를 이용해서 변환확인을 해봐야 한다.

6. 결론

서비스간에 사용하는 encoding을 확인하고 개발하는 습관을 항상 가지기

Node.js 12에서 16로 한번에 업데이트 적용후기 - 배포편

djunnni — Mon, 9 Oct 2023 00:00:18 +0900

도입

Node.js 12에서 16로 한번에 업데이트 적용후기 - 환경 세팅편에 이어 2번째 편이다.

배포 프로세스(무중단 배포 등)에 대해 자세히 다루긴 어렵지만 간단하게 어떻게 환경들을 맞춰나가고 진행을 해나갔는지만 적어보자.

_무중단 배포와 관련해서는 앞으로 구름 블로그 또는 팀원으로 들어오시면 더 자세하게 알 수 있습니다!!
_

진행전 공유

앞서 우리 환경은 다음과 같았다.

제목	개발서버	배포서버	운영서버
ubuntu	18.04	16.04	18.04
python	3.7.2	3.5	3.5
gcc	7.4.0	4.8	4.8
node.js	12.xx	12.0x	12.xx
npm	6.xx	6.xx	6.xx

1. python과 gcc 버전 올리기

올리게 된 이유는 관련된 dependency가 있는 node-gyp에서 python3.6버전, gcc 5.2.0 이상을 요구했다.

python3 업데이트

python3 --version
# Python 3.5.2
sudo add-apt-repository ppa:deadsnakes/ppa # 해당 PPA가 python 공식인듯? 최근 3.9까지 릴리즈함.
sudo apt-get update
sudo apt-get install python3.6 -y

# python3 버전 수동 변경
sudo update-alternatives --install /usr/bin/python3 python3 /usr/bin/python3.6 1
sudo update-alternatives --install /usr/bin/python3 python3 /usr/bin/python3.5 2

# 해당 버전 선택
sudo update-alternatives --config python3
There are 2 choices for the alternative python3 (providing /usr/bin/python3).

  Selection    Path                Priority   Status
------------------------------------------------------------
* 0            /usr/bin/python3.5   2         auto mode
  1            /usr/bin/python3.5   2         manual mode
  2            /usr/bin/python3.6   1         manual mode
Press <enter> to keep the current choice[*], or type selection number: 2

python3 --version
# Python 3.6.2

gcc 업데이트

#ppa 추가
add-apt-repository ppa:ubuntu-toolchain-r/test
apt-get update
apt-get install gcc-5 g++-5

버전확인

gcc --version
g++ --versionn

패키지 관리 목록

sudo update-alternatives --display gcc

sudo update-alternatives --install

priority가 낮으면 높은 우선순위

sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-5 10
sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-4.8 20
sudo update-alternatives --config gcc
There are 2 choices for the alternative gcc (providing /usr/bin/gcc).

Selection Path Priority Status

0 /usr/bin/gcc-4.8 20 auto mode
1 /usr/bin/gcc-4.8 20 manual mode
2 /usr/bin/gcc-5 10 manual mode
Press enter to keep the current choice[*], or type selection number: 2

2. git version 올리기

husky에서 요구하는 최소 버전이 2.13.0 이상이다.
2.7.4을 사용하고 있었기에 올릴 필요가 있었다.

sudo add-apt-repository ppa:git-core/ppa -y
sudo apt-get update
sudo apt-get install git -y

3. npm cache clean -f

npm cache clean -f

를 실행해줬다. 앞서 npm6에 깔린 cache들을 전부 날려주고 다시 설치하기 위함.

4. npm isntall

git pull을 받아 앞서 적용된 node16에서의 package-lock.json이 존재한 상황이다.
npm install을 운영서버나 배포서버에서 자유롭게 설치가 가능해졌다.

5. forever app restartall

forever를 통해 restart 하면서 새롭게 적용된 node16이 완료됨.

6. 일부러 hotfix를 열어 자동배포가 가능한지 확인

특정서버로 자동배포가 되게 테스트를 진행함. 문제가 보이지 않아 일단은 완료.
혹시나 싶어 2-3일은 수동배포도 병행하도록 체크.

7. 개발팀에 node16설치방법 문서공유

node16으로 환경을 바꿔서 개발할 수 있도록 팀원에게 문서를 공유했고 미리 세팅을 할 수 있도록 조치를 취했다.

또한 먼저 올라온 PR의 경우에는 node16으로 적용하고 다시 테스트를 해본 뒤 적용하도록 요청을 드렸다.

8. node16

앞으로 해당 서비스는 node16으로 동작하면서 FE에서만 적용했던 javascript 새로운 문법을 BE에서도 사용할 수 있게 되었다.
팀원들이 코딩하는데에 불편사항을 해소시켜 줄 수 있어서 다행이다.

TODO

1. 앞으로 해야할 부분은 lagacy에 대한 peer dependency를 마저 조사하고 하나씩 버전업을 진행해야 한다.
2. code내에 우리가 따로 package.json에 명시하지 않은채 import해서 사용하고 있는 라이브러리는 없는지 추가 체크

참고사이트

GCC, G++ 다른 버전 추가하고 패키지 관리하기

2023년 9월 10일 - 너디너리 데모데이

djunnni — Sun, 8 Oct 2023 15:48:30 +0900

오늘 너디너리 데모데이에 다녀오면서 여러 세션을 들어봤다.

들어본 이야기중 괜찮아 남겨보고 싶었다.

1. 근간이 되는 능력을 기르면 새로운 지식을 빠르게 받아드릴 수 있다.

2. 지속적으로 작은 성공을 해보기

3. 실패하길 두려워하지 말기

4. one way door, two way door에 대해 전략을 펼쳐보기

- 실패를 빨리하면 할수록 리스크는 줄어든다.

5. 문서작성능력은 꾸준히 하자

2023년 5월 30일 - SSAFY 마지막 일

djunnni — Sun, 8 Oct 2023 15:47:16 +0900

삼성청년 SW 아카데미 마지막일입니다.

마지막까지 프로젝트를 진행하고 퇴소하게 되었는데 회고로 남기고 싶어서 글을 써봤습니다.

SSAFY(삼성 청년 SW 아카데미)는 1년의 교육과정으로 상반기에는 자바를 활용한 알고리즘, Spring, MySQL에 대해서 사용하는 방법을 배울 수 있으며 하반기에는 공통, 특화, 자율 3가지 프로젝트를 진행할 수 있습니다.

SSAFY에 입과했던 이유로는 2가지가 있습니다.

Java 계열로 백엔드 역량을 쌓고 싶었던 점
개발자 커뮤니티에 참여해보고 싶었던 점

이 두가지를 이루는데, SSAFY는 많은 도움이 되었던 것 같네요. 뛰어난 친구들과 함께 프로젝트를 진행하면서 이뤄보고 싶었던 목표를 달성해볼 수 있었습니다.

그 밖에 SSAFY에서 AWS 서비스를 직접 신청해보면서 금액안에서 해결해볼 수 있는 방안들을 모색하고 적용해볼 수 있어 즐거웠습니다.

2023년 취업시장은 어려운 상황인 것 같습니다. 뛰어난 친구들이 모두 상반기 코테, 면접에서 떨어지고 있으며 컨설턴트님들도 말씀하시는 것 만큼 상황이 좋지 못합니다. 저 역시도 면접에서 좋은 성과를 얻지 못한 적이 많습니다. 그래도 꾸준히 노력해보며 블로그나 글로 계속 표현해보려고 합니다 :)

싸피를 통해 얻은 건

동료
알고리즘 자신감
개발자로서 동기부여 (앞으로 열심히 살기)
스프링을 활용한 서비스 개발 능력

PS) 싸피 마지막들어 BEST MEMBER가 한 번 됐네요. 받아보기 어려운 거 같아요 ㅎ

그 밖에 프로젝트하면서 동료들로부터 좋은 평가를 받아볼 기회가 있어서 공유하려고 합니다. 사회에서 많은 분들과 프로젝트 할 때에도 기록으로 항상남겨보고 반성해봐야겠어요.

2023년 4월 7일 - SSAFY 2번째 프로젝트 종료

djunnni — Sun, 8 Oct 2023 15:45:07 +0900

들어가며

SSAFY 8기 두번째 프로젝트(특화)가 종료됐습니다.

프로젝트를 진행하면서 스스로 회고를 해보면 좋겠다는 생각이 들었어요.

잘한 점

1. MSA(Micro Service Architecture)

이번 프로젝트에서 처음으로 MSA를 활용하면서 Eureka, Spring Cloud Gateway, 각 어플리케이션 서비스 서버와 데이터베이스를 따로 두는 경험을 했습니다.

다같이 학습을 위해 기간 중 일주일을 공부하는데 시간을 쏟았습니다. 확실히 그 주에 끝내겠다는 생각으로 강의를 접하니까 어떻게 구현해야할 지 보이고 설계도 편했습니다.

다만 실제로 여러 서비스가 함께 구동되며 동작하다보니 타 어플리케이션에서 Transaction 중 Request를 받으면 검증 차 방문해도 데이터를 읽어올 수 없어 동기화 문제도 발생했었습니다.

| 카프카를 통해서 데이터베이스의 Sync를 맞춘다던지, Read, Write를 나누어 하나의 데이터베이스에서 필요한 내용을 읽게 한다는 등 다른 방법들을 알아보는 시간이 필요할 것 같아서 마지막 프로젝트에서 적용해볼 예정입니다.

그 밖에 필요한 API 호출에 대해서 문서정리를 잘 했다는 게 뿌듯했습니다.

필요한 서비스에 따라 Tag로 구분지어 필요한 API를 상세보기 구현해 두었습니다.

서비스간 시퀀스 다이어그램을 통해 전달되는 과정을 간략히 설명, Request, Response 그 밖에 DTO에 대해 작성해두어 FE, 다른 어플리케이션에서 수월히 사용하는데 지장이 없었고 질문도 적었습니다.

이 부분은 다음번에도 잘 챙겨가야겠습니다.

2. JPA

이번에는 queryDSL을 사용하지 않고 JPA, JPQL만으로 개발을 해봤습니다. 이번에 새롭게 배운 건 hibernate에서 CRUD에 대한 쿼리가 한 트랜잭션에서 발생할 때, 순서가 정해진다는 걸 알았습니다.

어떻게 확인했었냐면 바로 delete 후, insert를 새롭게 하는데 중복 ID에 걸렸던 상황이 있었기 때문입니다. 검색읉 통해 좀 새로운 부분을 알았습니다.

집계 함수(group by) 사용 시, JPQL에서 리턴은 Object[]로 받는 다는 점입니다. 그렇기 때문에 해결하는 방법으로는

2-1. interface dto를 만들어서 받는 방법(이번)
2-2. queryDSL

앞으로도 queryDSL을 사용할 기회가 많다고 생각해 직접 JPQL + interfaceDTO를 만들어서 진행해봤습니다.

JPA에서 deleteAll에 대해서 여러번 요청이 발생하는 것을 방지하기 위해서 deleteAllInBatch를 통해서 지운 방법이 신선했습니다. 다만 놀란 건 아래와 같은 쿼리 처리..?

Hibernate: delete from deposit_transaction_history where 
transaction_history_id=? or 
transaction_history_id=? or 
transaction_history_id=? or 
transaction_history_id=? or 
transaction_history_id=? or 
transaction_history_id=?

이럴거면 직접 JPQL로 작성하는 게 더 이득이라고 판단하기까지 했었죠.

순환참조 무한루프

양방향관계에 대해서는 여전히 어렵다고 느껴지긴 하는데 무조건 좋다고는 생각이 안들더군요. 어짜피 Lazy로딩을 하는 경우도 있을 것이고 또한 어딘가로 PK를 넘겨서 바로 전체조회를 하는 경우도 있었기에 적절한 JOIN을 고려하는 생각도 해봐야겠습니다.

이번에 무한루프는 ToString을 양방향관계의 1부분에서 막아서 해결했습니다. 운영상 알 필요가 없는 부분이었죠.

delete에 대한 flush를 할 필요성

레코드를 삭제하다보면 특정경우에 select문만 수행하고 제거를 안합니다. 제가 파악했을 땐, 연관관계에 속해있거나 어딘가에 참조가 되어있어 스스로 삭제가 못하게 된 것으로 보여 flush를 통해 entityManager를 DB와 적절한 동기화를 수행해야 한다고 생각합니다.

Sonarqube

소나큐브를 통해 codesmell을 많이 줄여나갈 수 있었습니다. 덕분에 스스로도 정적인 부분의 코드를 수정하고 필요한 annotation을 재정비할 수 있었습니다.
기회가 되면 테스트 코드까지 검증을 받아야겠습니다.

부족한 점

엔티티 설계 대한 고민을 많이 하지 못한 점

항상 모든걸 다 만들고 할 수는 없지만 적어도 entity에 대한 모델 검증은 확실히 진행해야겠다고 생각했습니다. 안그러면 시간이 지나 모델이 무너져 애매하게 쿼리와 코드를 작성하기 때문입니다. 사전에 방지할 수 있도록 모델은 신중해야 겠습니다.

TEST code의 부족함

테스트 코드를 이번에 많이 작성하지 못했는데 그 이유로 꼽은 건 OCP, LSP, DIP를 많이 지키지 못했던 것 같습니다. MVC 패턴에서도 각 모델 간에 운영할 코드가 있을 텐데 service레이어에서만 다루는게 맞을 까 고민하다보니 구분을 잘 짓지 못했던게 아닐까 싶습니다.

WebClient

WebFlux에서 WebClient는 RestTemplate를 대체할 중요한 요소라고 생각합니다. 이번에 사용은 했지만 적절한 API 핸들링이 부족했다고 판단되어 시간되면 공부가 필요할 것 같습니다.

앞으로

앞으로 위에 나온 부족한 점을 채우고 팀원과 프로젝트에 대한 충분한 소통과 함께 격려할 수 있는 프로젝트를 진행해야겠습니다.

PL이 늘 고민해야 될 것

djunnni — Sun, 8 Oct 2023 15:42:15 +0900

구름시절 함께 일하던 동료가 준 포스트잇이 생각나서 적어봤어요.

프로덕트 리더가 조직의 프로덕트 방향을 이끄는 건 맞지만

늘 고민해야 하는 건

"사용자에게 합리적인 가치를 전하는가?"

"사용자의 이용을 유지(Retiention)하기에 충분한가?"

"경험이 충분히 매끄러운가?"

하는 부분이다. 제품에서도, 브랜딩에서도.

Node.js 12에서 16로 한번에 업데이트 적용후기 - 환경 세팅편

djunnni — Sun, 8 Oct 2023 15:31:51 +0900

1. Node.js 버전을 올리게 된 이유

사내에서 사용하는 Node.js 12를 쓰는 곳이 있었다.

이 때문에 최신 javascript에 적용된 여러 기능(Nullish coalescing operator(??) 등)들을 사용하지 못하고 있어 팀원들의 요청사항이 생기고 있었다.

마침 12버전은 2022년 4월 30일을 끝으로 유지보수 기간이 만료가 되기 때문에 최신 LTS로 한 번에 올려보기로 했다.

작업에 도움을 준 tyler, grey에게 고맙다.

https://nodejs.org/ko/about/releases/ 에서 릴리즈를 확인할 수 있다.

2. 올리기 전, 고려해야할 사항

개발, 배포, 운영서버의 환경을 점검해야 할 필요가 있었다.

ubuntu version
python, gcc, git version
node package version
package version up에 따른 바뀔 code 확인

2번에 대해서는 배포를 진행하면서 중요하다는 걸 알게됐다.
특정 packages에서 gcc와 python에 대해 최소버전을 명시했기 때문!

3. 현재 상황

제목	개발서버	배포서버	운영서버
ubuntu	18.04	16.04	18.04
python	3.7.2	3.5	3.5
gcc	7.4.0	4.8	4.8
node.js	12.xx	12.0x	12.xx
npm	6.xx	6.xx	6.xx

4. 전체 버전 업을 진행하기 전 내가 취한 작업은?

컨테이너 이미지를 node16에 맞춰 새롭게 만들었다.

사전 지식)
구름의 모든 서비스는 goormIDE를 통해 개발환경을 구축하고 서비스를 배포 및 운영한다.

기존 node12의 환경에서 package.json에 명시된 패키지들을 살펴보면서 git documentation을 읽으면서 node16을 지원하는 버전을 찾아서 올렸다.(하면서 bug-fix가 필요한 패키지도 함께 업데이트를 진행했고 모든 걸 한꺼번에 올릴 시 어디서 문제가 터지는 지 찾기 힘들어 2개씩 올려진행했다.)

React

redux, javascript-serialize 등

webpack

babel, babel plugin, @loadable, style-loader, sass-loader, node-sass, webpack-dev-middleware, webpack-hot-middleware 등

환경 세팅

husky, prettier, jest 등

버전이 올라가면서 모듈별 deprecated된 함수들을 찾고 올바른 사용법에 맞게 변경작업 시작
[node12] 올바르게 변경된 부분은 git commit을 진행해서 publish 함.
[node16] git pull로 바뀐 package.json을 설치해보고 구동시켜보기
(당연히 다른 부분에서 에러가 터지므로 계속 반복)

5. 나는 어떻게 node16에 맞는 패키지를 찾았고 적용했지?

ex) webpack과 webpack-dev-middleware!

webpack4, webpack-dev-middleware 3.7.2를 사용하고 있었다. 내 목표는 webpack-dev-middleware를 최신중에 4버전을 지원하는 구간을 찾아야했다.

npm에 webpack-dev-middleware의 최신이 5.3.1임을 확인
해당 패키지가 webpack4를 지원하는지 확인이 필요했다.

webpack-dev-middleware의 패키지를 확인하고자 github으로 들어와 package.json을 열어봤다.

아래로 내려보면 peerDependency로 webpack4를 지원하는 걸 확인 그러면 이제 할 작업은 3에서 5로 major버전이 2번 바뀌었다.

그 사이에 바뀐 패치사항을 확인해야 한다.

릴리즈 노트를 통해 major버전이 변경될 때, features, breaking changes를 확인했다.

바뀐 부분이 있다면 code에도 적용을 시켜줘야해서 중요하다.

아래에 보면 watchOptions가 지워졌다. 앞으로 webpack.config.js에서 가져다 써야 함으로 코드에 반영해주기로 했다.

webpack-dev-middleware는 3에서 5버전으로 올렸다.

그리고 실행해보면서 확인 완료.

이 작업을 다른 패키지들에도 동일하게 진행했다. 생각보다 평소에 버전관리를 안하다보니 시간이 오래걸렸던 거 같다.

6. node12 -> node16으로 올리기

node버전을 올리는 방법은 nvm, n도 있지만 해당 방법으로 올리는 걸 비추천한다!

n을 통해 올렸을 경우, 아래와 같은 문제가 발생할 수 있다.

n, nvm으로 올리면 node로 명령어를 실행했을 경우와 /usr/local/bin/node간의 명령어가 꼬이는 경우가 발생할 수 있다. 이 경우, EACCES가 발생할 수 있다.

그러면 어떻게 올려야 할까?

기존에 있던 node와 관련해 전부 지우고 curl로 node를 직접 받는 편이 좋다.

# node가 어디에 설치되어있는지 확인
whereis node

# node 관련 모든 경로 삭제
rm -rf /usr/bin/node
rm -rf /usr/include/node
rm -rf /usr/local/bin/node
rm -rf /usr/local/include/node # legacy-node 인듯
rm -rf /usr/share/man/man1/node*
rm -rf /usr/local/lib/node_modules/
rm -rf /usr/local/bin/npm
rm -rf ~/.npm
rm -rf ~/.node-gyp
apt remove nodejs -y

curl -fsSL https://deb.nodesource.com/setup_16.x | sudo -E bash -
sudo apt-get install -y nodejs
# 혹시 아래와 같이 뜬다면 node 6버전 부터 받고 다시 16버전 받는거 반복
# node -v
# The program 'node' is currently not installed. You can install it by typing:
# curl -sL https://deb.nodesource.com/setup_6.x | sudo -E bash -
# apt install nodejs

7. npm install

node12에서 16으로 넘어오면서 npm 버전또한 6에서 8로 바뀌게 되었다.
이 경우에는 설치를 하기 위해서

1. npm cache clean -f 
2. rm -rf node_modules, package-lock.json
3. npm install --legacy-peer-deps // peer-dependency가 맞지 않아도 일단 설치.

3번을 한 이유는, npm8로 넘어오면서 7일 때, 나온 peer dependency에서 막히면 설치를 멈추는 경우를 방지하기 위해서 진행했다.

8. 실행해보기

기존에 실행하던 방법으로 서버를 켜보고 package.json에 바뀐 리스트 중 몇가지 주요기능들에 대해 확인해봤다.

다음이야기

여기까지 적어보면서 알게 된 점은

"무조건 버전 업이 정답은 아니지만 LTS는 파악할 수 있는 hook이나 기타 설정할 수 있는게 있을지 확인해보자"
"개발과 운영환경의 설정은 최대한 같게 유지하자"

배포와 관련해서는 다음 편에 적어보도록 할 예정이다.