[내일배움캠프] 최종 프로젝트 Day 38 | Node.js 4기 | Day 119

Coding/내일배움캠프

_Woo_ 2024. 5. 2. 22:19

질문들 많이 올 수 있다 ..

질문에 대해서 답변 잘 하실 수 있어야 하고 ..

고도화 작업 - 1 : 알림 통합
메시지 큐, 배치 처리 등 여러 기술을 고려한 뒤 여러 개의 알림을 통합하여 하나의 알림으로 제공
고도화 작업 - 2 : 미션 가입 시 많은 접속 고려
메시지 큐 등을 고려해서 대기열 구현
고도화 작업 - 3 : 이미지 데이터셋을 활용하여 인증 기능 고도화
현재 각 카테고리별 25개의 이미지로부터 라벨 추출 후 가중치 부여하는 과정을 거쳤으나, 추후 이미지 데이터셋을 활용하여 더 많은 양의 이미지로부터 라벨 추출 후 가중치를 부여하도록 고도화 예정
기능 - 채팅방
웹 소켓, Pub/Sub 메시지 브로커 등 고려하여 채팅방 구현
기획 및 기능 개발 - 리워드
포인트가 많은 순으로 리워드 제공 기능

—

소켓 사용하신 이유?

채팅까지 했을 때 Socket IO를 하는 게 좋을 것 같다고 ..

보통 알림 .. SSE 사용하는 경우도 많아서 ..

——

설명만으로 봤을 때 .. 신뢰할 수 없다 .. 위 아래 사진 .. 예시 사진 ..

피드백 감사드립니다 ..

nestJS .. Layered Architecture ..

Repository가 .. TypeORM Repository를 사용하신 것 같다…

Q. Custom Repository를 만들어보실 생각은 하셨었나요?

Typeprom .. 다른 orm으로 넘어갈 수 있는 상황.. 서비스 단을 다 고쳐야 한다 ..

로직이 아예 변경될 수도 있고, 이런 식으로 되기 때문에 ., Repository 따로 둬서 .. ORM..

DB가 바뀌어도 .. Repostiory 따로 두는 걸 추천해드린다 ..

message queue .. 한 명 한 명 순서가 중요한가? 그거 아니면 .. 대기열 구현도 해볼 게 많아서 …

Jest 오히려 지우는 게 더 좋을 수도 있겠다 ..

단위 테스트가 최우선 .. 작은 범위로부터 큰 범위로 ..

단위 테스트, 통합 테스트, .. 이런 순서로 하는 게 좋아보입니다 ..

실행됐으니 1차적으로 성공 -> 리팩토링하면서 잘 짜지게 되는 것 ..

테스트코드 입출력만 같으면 뭐가 바뀔 일은 없다 …

테코 .. 이 사람이 얼마나 로직을 잘 알고 했냐

테코 생각하면서 비즈니스 로직 짜야 한다 ..

단위 테스트 .. 서비스에서 레포지토리를 .. 모킹 .. 레파지토리 ..

레파지토리에서 이런 데이터가 나올 거야 .. 이런 서비스 .. 비즈니스 로직 제대로 나올 수 있을 것 같고 …

기본적인 것 로직 .. 무조건 우선순위이다 ..

핵심을 한 군데에 뭉쳐두세요. Layered Architecture ..는 서비스에..

DDD는 도메인에

실제 데이터가 .. 아니라 Mocking을 사용했을 때 장단점 .. ?

환경변수 .. secret manager ..

만약에 배포를 했는데 테스트나 배포에서 실패 .. 지금은 .. 어느 정도 예상하고 .. 깃허브 배포 됐는지 안 됐는지 확인해야 하는데 .. 배포가 실패하자마자 나에게 알려주고 싶다.. 그럼 혹시 어떻게 해야 할 수 있을까요? 어떻게 구현할 수 있을까요?

슬랙이나 텔레그램으로 알림 받기 ..

PATCH와 PUT의 차이점

PUT은 전체적으로 수정될 때 사용이 되고 PATCH는 일부 수정 ..

정확하게 구별해서 쓰는 회사들 잘 없다 ..

정확하게 구분할 수 있는 게 아니라면 오히려 하나로 통일하는 게 더 나을 수 있어요.

개인적으로 조금 더 공부를 하는 게 좋았겠구나 ..