개발자들이 남긴 기록..

1. Prisma로 Soft Delete 구현 시 조회 조건 처리

핵심: Prisma에서 소프트 딜리트를 구현하면, 삭제 상태를 반영하기 위해 조회 시 항상 조건을 추가해야 함.
설명:
- 소프트 딜리트는 실제로 데이터를 지우지 않고, 삭제 여부를 나타내는 필드(예: deletedAt, isDeleted)를 통해 데이터 보존과 복구가 가능한 방식임.
- 그래서 데이터를 조회할 때, 삭제된 데이터를 제외하거나 포함하기 위해 쿼리 조건에 where 절을 추가해야 함.
미들웨어 활용:
- Prisma 미들웨어를 이용해 find나 findMany 같은 조회 메소드 호출 시 자동으로 where 조건을 붙일 수 있음.
- 이 방법은 코드 중복을 줄이고, 실수로 삭제된 데이터가 노출되는 걸 방지할 수 있음.
개발자 의견 요약:
- 조회할 때마다 조건을 명시하기 귀찮다면 미들웨어에 로직을 추가하는 게 효과적임.

상황: 백엔드 개발자 GW가 처음 WebSocket 기반 소켓 API 문서 작성에 어려움을 겪음.
주요 질문: 소켓 API 문서는 어떻게, 어떤 형식으로 작성해야 하는지?
개발자 답변들:
- API 문서 작성은 주로 데이터를 주고받는 방식과 메시지 포맷에 따른다.
- Swagger는 HTTP REST API 문서화에 특화되어 있지만, WebSocket은 지원이 제한적임.
- Postman은 최근 WebSocket 테스트 및 문서 작성 기능도 지원해서 좋은 대체 툴임.
- 깃북(GitBook)으로 문서화하는 것도 직관적이고 깔끔한 결과물을 만들 수 있음. (https://www.gitbook.com/)
설명:
- WebSocket API 문서는 주로 이벤트 이름(event name), 전달하는 메시지 포맷(payload), 서버-클라이언트 양방향 통신 방식 등을 명확히 기술해야 함.
- REST API와 달리 HTTP 메서드 대신 이벤트 기반으로 구조화됨.
개발자 소감:
- 프론트엔드 동료들이 이해하기 쉽게 보기 좋게 작성하는 게 중요함.
- 표준 문서 포맷이 없기 때문에 팀 내 통일된 양식 설정도 필요함.

사례: NestJS 프레임워크에서 버그를 발견하고 GitHub에 이슈 등록함 (https://github.com/nestjs/nest/issues/14450).
문제점:
- GitHub 코드 레포는 최신 상태이나, npm 공식 배포본은 구버전이라 최신 버그 수정 코드가 반영되지 않았음.
- 따라서 최신 버그 수정 기능을 바로 사용할 수 없고, 직접 소스를 빌드하거나 기다려야 함.
개발자 의견:
- 보통 의존성 자동 관리 봇이 버그를 잡아주거나 업데이트를 알려주지만, 퍼블리싱(배포) 과정은 사람이 직접 하기 때문에 지연 이슈가 발생함.
해결 팁:
- 버그가 심각하다면 직접 GitHub 소스를 포크해 사용하거나, 임시 패치를 적용할 수도 있음.

Prisma 소프트 딜리트 전략 질문 대비:
- Soft delete의 개념과 이를 효과적으로 구현하는 방법(미들웨어 활용)을 설명할 수 있어야 함.
- 언제 실제 삭제(hard delete)를 써야 하는지도 간단히 언급하면 좋음.
WebSocket API 문서화 경험 관련 질문 대비:
- REST API와의 차이점, 이벤트 기반 통신의 특성을 이해하고 있어야 함.
- 팀 협업 시 명확한 문서화의 중요성 및 활용한 툴(Postman, GitBook 등)에 대해 답변 준비.
오픈소스 또는 라이브러리 버그 대응 경험 질문 대비:
- 버그 발견 후 이슈 등록, 배포본과 소스 레포 간 버전 차이 문제 이해도 표현.
- 직접 임시 수정이나 포크 가능한 유연함도 어필 가능.