2023-08-14 정기 백엔드 개발 회의

[nyj001012]

안건을 자유롭게 추가해주세요 :)

[nyj001012]

contract만 작성하고 pr 올리면 test pr의 type check에서 계속 오류를 뱉습니다.
test pr을 무시하고 merge는 못 하고, test pr 통과하겠다고 이것저것 작성해주려니 작업의 규모가 점점 커지네요.

• test pr을 일부 작업에만 적용하게 한다
• 내지는 merge 조건을 반드시 test pr 통과하는 것 대신 불가피한 경우에는 코드 리뷰로 대체한다

등등의 방법으로 pr을 유하게 진행할 수는 없을까요?

[scarf005]

넵 좋습니다.

[scarf005]

백엔드의 미래와 E2E 타입 안정성 (End-to-End type safety)을 달성하기 위한 멀고 힘든 길

아래 댓글을 참고해주세요

월요일 회의에서 V2를 V1에 종속받지 않는 별개의 프로젝트로 새로 진행하자는 아이디어를 냈었습니다.

동기

• typeorm

  • and와 or을 같이 쓰는 쿼리를 사용하기 매우 난해함
  • 타입 안전하지 않음
    • 백엔드 쿼리의 대부분이 queryBuilder 사용 (반환값: any)
    • select 사용시 반환 타입이 좁혀지지 않음

      const reviews = await this.findOrThrow({ select: { id: true } })
      // ^? typeof reviews = Reviews		
      reviews.userId // <- id만 select했음에도 존재하지 않는 필드가 접근 가능하다고 잘못 나옴

      오히려 타입이 없는 경우보다 위험

• 노드

  • tsc에서 paths 경로를 처리하지 않아 번들러를 사용해야함 https://github.com/topics/tsconfig-paths
  • 번들러와 typeorm이 매우 친하지 않음
  • ts-node가 느림 (재실행 4초)
  • ts-node-dev, tsx, swc-node 등의 대안은 모두 typeorm과 함께 쓰지 못하거나, esm에서만 동작하거나, 둘다 요구함
  • 대안으로 vite-node를 택했으나 버그가 많음:
    • vite-node --watch doesn't close process before restarting vitest-dev/vitest#2334
    • Watch mode unresponsive to monorepo dependency changes vitest-dev/vitest#2532
    • HMR in vite-node, callback is not working vitest-dev/vitest#2083
    • ReferenceError: __vite_ssr_import_1__ is not defined when a spec imports preact/compat vitest-dev/vitest#367

V2의 주 목표

• deno 사용

  • 현업에서 사용중인 안정된 자바스크립트 런타임
    • https://deno.com/blog/tea-simplifies-distributing-software
  • 타입스크립트 바로 실행
  • 포매터(prettier), 린터(eslint), 벤치마크, 테스팅(jest), watch 모드(nodemon) 내장
  • node 패키지 그대로 사용 가능
  • 의존성 관리가 매우 편리 (url에서 바로 패키지 import 가능, import map 사용하면 절대경로도 사용가능)
  • 배포(AWS/도커)가 편함

• 타입 안전한 파싱

  • zod

• 프론트엔드와 백엔드에서 타입 안전하게 통신

  • https://trpc.io
  • https://ts-rest.com

• 타입 안전한 sql 쿼리

• 테스트가 편리해야함

• 자동으로 swagger 문서 생성 - 기존에는 주석 형태로 손으로 써야 해 수고롭고 오류가 발생 가능

• 타입 안전한 미들웨어

• 웹 표준 호환 서버 표준 구현

  • 배포시 큰 도움이 됩니다
  • 환경에 구애받지 않고 사용 가능합니다
  • Request -> Response 명세를 따르므로 타 서버를 그대로 마운트해 사용 가능
    • https://hono.dev/api/hono#mount
    • https://elysiajs.com/patterns/mount.html

위 조건을 모두 만족하는 라이브러리가 두 가지 있는데, 모두 일장일단이 있어 고민이 되고 있습니다. 우선은 월요일~수요일간 hono와 elysia를 (직접 사용해보고)[#653] 정리한 내용입니다:

Hono

장점

• Deno에서 네이티브하게 동작
• 통합 테스트가 편리

단점

• 서버 구현 기반 swagger 생성 불가
  • ts-rest에서 생성한 openapi 객체를 사용해 swagger UI를 제공할 수는 있음
  • 미들웨어에서 추가한 메타데이터를 (예: jwt, 로그인 정보)를 핸들러에 타입 안전하게 전달하기 어려움
• ts-rest 어댑터 지원 미흡
  • PR을 3개 보내보기는 했으나 현업에서 사용하기에는 불안함
    • build: bump hono to 3.4.0, @ts-rest/core to 3.27.0 msutkowski/ts-rest-hono#10
    • build: deno support with denoify msutkowski/ts-rest-hono#11
    • feat: validate request headers msutkowski/ts-rest-hono#13

Elysia

장점

• 테스트가 편리
• 서버 구현 기반 swagger 자동 생성
• 서버 구현 기반 contracts 자동 생성
• 타입 안전한 미들웨어

단점

• Bun 사용을 상정한 라이브러리

  • deno에서 동작은 하나 패키지 호환 문제가 약간 있음
  • 추후 예상치 못한 문제가 발생할 가능성도 있습니다

• ts-rest 지원 없음

  • 스키마 타입 지정을 typebox을 사용하기 때문에 기존에 zod로 작성한 스키마를 변환해야 합니다
    • typebox가 json schema 표준을 따르기 때문에 swagger 자동 생성이 가능한 거여서, zod 지원은 한동안 힘들 것 같습니다

ts-rest

처음 ts-rest를 선택한 이유

장점

• express에 E2E 타입 안정성을 지원할 거의 유일한 방법 (+zodios)
• react-query 호환

단점

• @ts-rest/openapi에서 example 지원이 되지 않음
• 일이 2배로 증가 (contracts 작성 -> 백엔드 구현)
• 타입 오류 발생시 해결이 어려움, 부정적인 사용자 경험
  • 오류 메시지가 매우 복잡하기 때문입니다 (C++ 템플릿 메시지 오류와 비슷한 분량)
  • 2023-08-14 정기 백엔드 개발 회의 #655 (comment)
  • feat: 히스토리 api ts rest 적용 #599
• V2를 별개 프로젝트로 진행하게 된다면 hono와 elysia 모두 E2E를 지원하므로 ts-rest를 사용하는 장점이 퇴색됨

결론

개인적으로는, 다음 이유로 인해 elysia쪽으로 마음이 기울고 있습니다:
- 서버만 작성하면 swagger 자동 생성됨
- contracts만 작성하면 swagger 자동 생성됨
- 타입 안전한 미들웨어

물론 장점만 있는 것은 아닙니다. 자료가 많은 express나 typeorm과 달리 이러한 새 프레임워크들은 알려지지 않은 문제도 많을 수 있으며 (hono 단점의 ts-rest-hono 참고), 입문 난이도를 높일 가능성도 있습니다.

팀에서 장기적으로 써도 좋을지 검증하기 위해 주말까지 elysia를 사용해 백엔드 구현을 더 해보겠습니다.
ts-rest 스키마를 이전하는 작업은 비교적 간단할 것 같아, 제가 손으로 하도록 하겠습니다. (의견을 낸 사람이 책임을 져야)

월요일 회의때 완성 결과물을 같이 보면서, 도입 여부에 대해 논의해보면 어떨까요?

[scarf005]

2023-08-13 업데이트

둘 다 사용해본 결과 hono와 elysia 둘 다 사용하게 된다면 상술했듯

• 지나치게 새롭게 배워야 하는 것이 많고 (bun, deno, esm)
• 나온지 긴 시간이 흐르지 않아 생태계가 작고 버그가 많으며 (hono: 2년, elysia: 8개월)
• 기존 ts-rest와 호환 되지 않아 기존에 작성한 코드를 전부 다시 고쳐써야 하는 문제가 있었습니다.

지난주 회의에서 장문으로 문제점을 작성했음에도 한번에 지나치게 많은 것을 하려고 했네요. 반성합니다...

때문에, 기존 제안 (v2 분리, ts-rest 제거 및 hono/elysia 사용) 대신, 다음을 제안합니다:

• DI 패턴 철회: 2023-08-14 정기 백엔드 개발 회의 #655 (comment)
• kysely 사용: 2023-08-14 정기 백엔드 개발 회의 #655 (comment)

[nyj001012]

집현전 검색 기능 TF팀 작업

1. Work space

• V1에서 작업 예정
• 기존대로 develop PR 후 main에 PR 예정
• 서비스까지 하려는 게 목표

2. DB

• 테이블 및 컬럼의 삭제는 없을 것
• 테이블 추가나 컬럼의 추가는 있을 수도 있음
• 컬럼 추가의 경우 nullable 속성을 부여하여 기존 서비스와 충돌이 나지 않게 할 것

[scarf005]

DI 패턴을 사용하지 않고 기존 레이어드 패턴으로 원복

PR: #665

이유

• 사용 난이도와 코드 복잡성에 비해 이득이 미미했기 때문입니다.
• 집현전 백엔드 서버 구조상
  • 컨트롤러의 유닛 테스트는 이미 ts-rest를 사용함으로써 이루었으며
  • 서비스와 레포지토리의 경우 모킹이 복잡한 유닛 테스트보다는 테스트 DB를 사용한 통합 테스트가 더 정확하고 효율적이라고 생각했기 때문입니다.

[scarf005]

Kysely 를 사용해 raw query와 typeorm querybuilder를 마이그레이션

PR: #670

이유

• 기존 코드와 DB 구조에 큰 변화를 주지 않고 (v1, v2 코드에 그대로 적용 가능)
• 입문 및 마이그레이션 난이도가 높지 않으며 (sql 문법과 대응)
• 백엔드 타입 안정성에 즉각적으로 도움이 되고
• express가 아닌 다른 프레임워크를 사용하더라도 호환이 되기 때문입니다.

[jimin52]

typeorm 을 유지하면서 zod 로 repoisitory 단에서 런타임 타입검증을 하는 방법은 어떤가요?
zod 는 이미 설치되어있는 라이브러리이고 작성된 typeorm repository 를 변경할 필요도 없어 보입니다.

[scarf005]

혹시 조금 더 자세히 설명해주실수 있을까요?
ts-rest에서 해주는 런타임 반환값 타입 검증 외에 추가로 typeorm 쿼리 반환값도 zod로 런타임 타입검증을 하자는 아이디어일까요?

[jimin52]

kysely 를 사용하는 이유가 typeorm 의 타입 안정성이 부족하다는 이유인 것 같다고 이해했는데
zod 로 런타입에서 타입 검사를 하면 typeorm 의 타입도 검증이 되는게 아닐까하는 생각을 해 보았습니다

[scarf005]

물론 zod를 사용하면 typeorm에서도 런타임 타입 검증이 가능하지만, kysely의 큰 장점은 다음인것 같습니다.

• 컴파일 단계에서의 타입 안정성
• raw SQL 쿼리와 동일한 문법
• 데코레이터(reflect-metadata)를 사용하지 않음 -> 메모리 사용량 감소, 러닝 커브 단순화
• view 엔티티를 사용하지 않고 일반 select와 join을 사용해 타입 안전한 쿼리 작성 가능 -> synchronize 부담 감소

물론 ORM이 아닌 쿼리 빌더이기 때문에 조금 더 복잡해지는 부분도 있겠지만, SQL 문법을 따라간다는 점에서 장기적으로 도움이 될 수 있겠다는 생각이 듭니다.

[jimin52]

어제 배포와 contract 문서 정리, stock api 리팩토링을 했어야 했는데 트랜센던스 팀과제 후 하루종일 휴식해버리고 말았습니다.
팀원분들을 모집하고 모범을 보이지 못한것 같아 죄송합니다.

[JeongJiHwan]

stock이 간단한 api였는데도 ts-rest 구조를 파악하는 부분이랑, pr올렸던것처럼 zod 타입반환 문제랑 queryBuilder에서 처리가 안되던 부분이 조금 어려웠는데 계속해서 뭔가 바뀌니까 열심히 따라가야할것같습니다.

[scarf005]

ts-rest 구조 파악 부분이, 다음 두가지일까요?

• ts-rest contracts작성 및 이해에 대한 어려움
• 백엔드에서 contracts 구현에 대한 어려움

[JeongJiHwan]

제가 설명을 잘못한것 같은데 contracts 작성이나 구현의 어려움보다는 DI로 인한 구조에 대한 파악의 어려움이었습니다.

[scarf005]

맞아요 DI가 너무 복잡했었죠