On this page
7. Component Deep Dive
지난주에는 코드당 Backend의 Client와 Admin, GraphQL의 기본 개념을 살펴보았습니다. 이번 주에는 Notice(공지사항) 도메인 하나에 집중해, 내부의 역할 분리와 공지 처리 규칙이 코드에 어떻게 구현되어 있는지 살펴봐 주시기 바랍니다!
Notice 코드 살펴보기 🔍
Admin Notice 코드 와 Client Notice 코드 를 살펴보세요. Prisma Schema 의 Notice 모델에서 isVisible, isFixed의 기본값과 작성자 관계도 확인해보세요.
아래 질문은 코드를 읽을 때 학습 방향을 잡기 위한 예시입니다. 질문에만 답하고 끝내기보다는, Notice의 다른 메서드나 조건도 궁금한 부분을 찾아보며 자유롭게 더 깊이 살펴보세요.
1. Admin: 공지 관리
Admin의 notice.resolver.ts, notice.service.ts, model/notice.input.ts를 읽어보세요.
- Resolver와 Service에는 각각 어떤 공지 관리 기능이 있나요? 두 파일은 역할을 어떻게 나누고 있나요?
CreateNoticeInput과UpdateNoticeInput은 어떤 필드를 받으며, 두 입력 타입은 어떻게 다른가요?- 공지를 생성할 때 작성자 정보는 어디에서 가져오나요? 생성·수정 입력값은 Prisma에 어떻게 전달하나요?
2. Client: 공지 조회 규칙
Client의 notice.controller.ts와 notice.service.ts를 읽어보세요.
- Admin에서 만든 공지 중 어떤 공지가 사용자에게 보이나요?
isVisible과isFixed는 조회 조건에서 각각 어떤 역할을 하나요? - 검색과 페이지네이션은 Prisma 조회 조건에 어떻게 반영되나요?
- 상세 조회에서 현재 공지와 이전·다음 공지를 찾는 조건은 어떻게 다른가요?
정리할 내용 📝
Admin과 Client에서 살펴본 파일의 경로나 링크, 주요 함수 이름을 남기고 각자의 역할을 정리해보세요. Notice에서 발견한 규칙 두 가지를 골라 어느 코드에서 구현되는지 설명해보세요. 같은 데이터를 다루는 Admin의 GraphQL과 Client의 REST API가 코드에서 어떻게 구분되는지도 살펴봅니다.