COMMIT.chat
View Bookmarks
nestjs 썸네일nestjs

2025-01-23

목차

  1. Rust 언어 현황과 전망
  2. NestJS 공부 및 추천 서적
  3. Typia + SWC 사용 경험과 제한 사항
  4. NestJS 기반 모바일 & 웹 API 분리 설계
  5. Prisma 스키마 멀티 파일 지원
  6. BFF (Backend For Frontend) 개념과 관리 주체
  7. API 설계 시 모바일과 웹 대응 방안
  8. Code Push 및 앱 API Deprecated 관리
  9. 정책 관련 인터페이스 네이밍 고민
  10. 국내 개인정보 이슈 간략 언급

1. Rust 언어 현황과 전망 🚀

  • 러스트(Rust)는 메모리 안전성과 성능을 겸비한 언어로 각광받아 왔음.
  • 최근 대형 프로젝트에서 거부되는 사례도 있어 "Rust가 답인가?"에 대한 회의적 시각 존재.
  • 장점: 안전한 메모리 관리, 고성능, 현대적 문법.
  • 단점: 진입장벽, 컴파일 속도, 학습 곡선.
  • 참고글: Rust’s downfall - Medium

2. NestJS 공부 및 추천 서적 📚

  • Rust 관련 고민 중 네스트JS(NestJS) 서적 추천 요청이 있었음.
  • 최신 버전 업데이트가 많으므로, 공식 문서 정독이 가장 효율적이라는 의견 다수.
  • "NestJS"는 Node.js 기반 프레임워크로 타입스크립트와 함께 사용하기 좋음.
  • 참고 블로그: NestJS 실전 가이드

3. Typia + SWC 사용 경험과 제한 사항 ⚙️

  • Typia: 타입스크립트 타입 정보를 기반으로 런타임 검증을 자동화하는 라이브러리.
  • SWC: 빠른 자바스크립트/타입스크립트 컴파일러.
  • Typia는 공식 문서에 SWC 지원하지 않는다고 명시되어 있음.
    • 이유: SWC는 정적 타입 정보를 충분히 보존하지 못해 Typia가 정상 작동 불가.
  • Vite 지원 및 unplugin-typia 활용 가능.
  • 테스트 코드 환경 전환시, Vitest는 Jest보다 빠르지만 호환성 문제로 에러가 많음.
  • ESM 환경에서 정적 모듈 분석 관련 이슈 존재.

4. NestJS 기반 모바일 & 웹 API 분리 설계 📱💻

  • 웹과 모바일 API 단일 서버 활용 시:
    • 컨트롤러만 분리하는 경우가 많음.
    • 서비스 및 레포지토리 구성은 거의 동일하게 유지.
  • 이유: 요구사항 유사한 경우가 많아 코드 중복 최소화가 효율적.
  • 단, 엔드포인트 분리하여 요청을 구분하고 일부 API는 별도 처리.
  • API 문서 스트리밍 파일 응답 시 StreamableFile 사용가능.
  • 관리 복잡도 증가 시 점진적으로 패턴화하며 설계 권장.
  • 프론트에서 클라이언트 종류(웹/앱)를 헤더 등으로 구분하여 처리하는 방법도 활용됨.

5. Prisma 스키마 멀티 파일 지원 🗂

  • 기존 TypeORM은 엔티티마다 별도 파일 사용.
  • Prisma는 기본적으로 schema.prisma 하나에 모든 엔티티 정의.
  • 그러나 프리뷰 기능으로 멀티 파일 모듈화를 지원.
    • 대형 프로젝트에서 스키마 분리하여 관리 가능.
  • 참고자료: Prisma 멀티 파일 지원 공식 안내

6. BFF (Backend For Frontend) 개념과 관리 주체 🖥️📲

  • BFF는 프론트엔드별 맞춤형 API를 제공하는 중간 서버 계층.
  • MSA 구조에서 여러 리소스 서버 API를 통합하고 최적화함.
  • 관리 주체:
    • 일반적으로 프론트엔드가 관리하지만, 회사마다 다름.
    • 프론트 입장에선 관리 부담이 늘어날 수 있음.
  • API Gateway와 BFF가 타협점 역할을 하며 복합 서비스에서 적극 활용.

7. API 설계 시 모바일과 웹 대응 방안 🔄

  • 모바일과 웹에서 요구사항 차이가 존재할 때 대응법:
    • 동일 API 엔드포인트 유지하고 클라이언트 구분을 통해 분기 처리.
    • 조건별 데이터 추가 및 서비스/쿼리 레벨에서 변화 주기.
    • 페이지네이션 등 공통 QueryParam은 통일(page, perPage 등).
  • 점진적으로 UseCase를 수집해 패턴화 설계하는 방식을 권장.
  • 앱은 API 변경에 더 민감하여 Deprecated 관리가 중요함.

8. Code Push 및 앱 API Deprecated 관리 📦

  • 앱에서 API를 Deprecated 하기는 어렵고 신중해야 함.
  • Code Push 기술로 앱을 강제로 업데이트할 수 있는 방법 존재.
  • 대표 오픈소스:
  • 2025년 3월 공식 Code Push 서비스 중단 예정이라 직접 오픈소스 활용 필요.

9. 정책 관련 인터페이스 네이밍 고민 🤔

  • 정책에 따른 서비스 분기 시 네이밍 고민 많음.
  • 'Policy' 와 'Strategy' 두 단어 비교:
    • Policy: 규칙, 정책 의미로 적합, 네이밍으로 더 자주 사용됨.
    • Strategy: 디자인 패턴에서 전략 의미, 중복 사용 우려.
  • 대체로 'Policy' 네이밍 추천.
  • 예) payment/policy, payment/strategy 중 추천은 payment/policy.

10. 국내 개인정보 이슈 간략 언급 🔒

  • 한국의 엄청난 개인정보 유출 사건 이슈 공유.
  • 온국민 4000만 명의 개인정보 542억 건이 59억 원에 거래됨.
  • 카카오, 네이버 모기업이 중국 관련 기업이라 불합리하다는 시각 존재.
  • 관련 뉴스: 네이버 기사

면접팁⚡

  • Rust에 대한 질문 시, 장단점을 균형 있게 설명하고 최근 현황 언급하기.
  • NestJS 기반 API 설계 경험은 모바일/웹 분리 전략, BFF 활용 경험으로 어필.
  • Prisma 스키마 관리 방식 질문에는 멀티 파일 지원과 대형 프로젝트 관리 방안 언급하기.
  • 정책 네이밍은 'Policy'를 선택하는 이유를 논리적으로 설명하면 좋음.
  • Code Push 및 앱 업데이트 전략 경험이 있다면 API Deprecated 문제 해결 사례로 활용.

링크🔗

#Rust#NestJS#Prisma#Typia#SWC#BFF#API설계#CodePush#정책패턴#개인정보
이전 포스트

2025-01-22

2025년 1월 22일
다음 포스트

2025-01-24

2025년 1월 24일