GET /v1/shared-carts API 부분의 구현을 보니 CartReader.getCartAccessList 부분이 있는데 cartAccessRepository.findByUserIdAndStatus 메서드를 사용하여 조회하더라구요. 이렇게 되면 내가 만든 내가 소유자인 카트만 조회될 것 같고, 공유 장바구니 참여자 수 만큼 같은 공유카트가 여러개 조회 될 것 같습니다. 결국 소유자 조차도 access 데이터에 추가된다면 cartAccessRepository.findByAccessUserIdAndStatus 를 사용하여 범용으로 사용하는 것은 불가능할까요? 그리고 CartHandler.createCharedCart 부분에는 도구 레이어임에도 불구하고 하나의 트랜잭션으로 두지 않으셨는데요, 카트 생성 이후 나의 접근 권한이 추가 되지 않는다면 카트 리스트에서 볼 수 없을 것 같은데 이 점에 대해서도 의도하신 바가 있는지 궁금합니다! 또한 access 부분에서 DB 유니크를 걸어두었지만 사전 존재 확인이나 멱등처리가 없는 것 같습니다. 개념적인 예외를 사용하지 않고 DB 무결성 예외를 노출시키신 이유가 궁금합니다.
안녕하세요 강의 잘 듣고 있습니다. 다른게 아니라, 14번 문제에서 D의 Direct Connect가 비용 효율적이라고 말씀하셨습니다. 근데 , 개념 강의에서는 Direct Connect는 직접 선을 연결하는 작업이기 때문에 비용이 많이 든다고 하셨습니다. 왜 해당 문제에서는 "Direct Connect"가 비용 효율적인 방법이 되는건가요??
강의 2강에 대한 노트에 대한 질문입니다. 💡 [CS 및 실무 적용 Point: MSA와 BFF 아키텍처] 현대의 마이크로서비스 아키텍처(MSA)에서 Node.js는 특히 BFF(Backend For Frontend) 패턴의 핵심 기술로 사용됩니다. 브라우저의 DOM을 다루던 언어적 특성을 살려 클라이언트(React, Vue 등)의 요청을 쉽게 파싱하고, 이식된 운영체제 제어 능력(http, fs)을 통해 백엔드의 여러 마이크로서비스(Java, Python 등)로 비동기 네트워크 요청을 뿌린 뒤, 그 결과를 모아 빠르게 클라이언트에게 반환하는 완벽한 미들웨어 역할을 수행합니다. 해당 설명에서 BFF로 NodeJs를 유용한 이유는 I/O 입출력 특출나기 때문에, BFF로 사용하면, API 요청을 받아서 마이크로 서비스에 통신 요청을 보내는 용도로 사용한다는 건가요? 한번 더 거쳐가면 더 성능이 안 좋은 거 아닌가요? 아니면 원래 SpringBoot로 개발되었던 웹 사이트를 NodeJs로 구현한다면 더 좋다는 의미일까요?
"AI 딸깍의 시대" 원리로 돌파하는 Node.js와 CS Part 2 - 스트림 아키텍처와 하드웨어 통제기
// 3. 작업 종료 알림: end 이벤트를 통해 댐 바닥 확인 streamRead.on("end", async () => { console.log("\\n✅ [종료] 댐 바닥 도착. 모든 데이터 복사 완료!"); // 메서드: 더 보낼 물이 없다고 선언하고 파이프 닫기 절차 진입 // finish 이벤트: 쓰기 파이프가 논리적으로 완벽히 닫혔음을 보장 streamWrite.on("finish", async () => { // 쓰기 파일 디스크립터(번호표) 운영체제에 반환 (메모리 누수 방지) await fileHandleWrite.close(); console.timeEnd("복사_소요_시간"); console.log( `📊 요약: 총 ${chunkCount}회 펌프질, ${pauseCount}회 비상 정지(메모리 방어 성공)`, ); // 메서드: 실험용 임시 파일 삭제 클린업 (unlink) await fs.unlink(SOURCE_FILE); await fs.unlink(DEST_FILE); }); streamWrite.end(); // 메서드: 사용이 끝난 읽기 파일 디스크립터(번호표) 운영체제에 반환 await fileHandleRead.close(); 읽기 스트림과 쓰기 스트림을 종료하는 3번 단계에서 쓰기 스트림을 end 하기 전에 .on finish를 등록을 해야 콘솔에서 요약을 볼 수 있었습니다. 클로드는 레이스 컨디션이 발생해서 그렇다고 하는데 어떤 부분에서 경합이 일어났는지 잘 모르겠습니다.
let previousContent = ""; const addToFile = async (path, content) => { if (previousContent === content) return; // 중복 실행 방지를 위한 거름망 if(!(await fileExist(path))) return; // file이 존재하는지 않하는 지 체크 try { await appendFile(path, content); previousContent = content; console.log(`✅ ${content} is successfully appended to ${path}`); } catch (error) { if (error.code === "ENOENT") { console.log(`⚠️ ${path} does not exist`); } console.error(`❌ 에러 발생: ${error.message}`); } }; catch error 부분에서 에러 코드로 ENOENT를 사용해서 path가 존재하지 않는 경우를 잡아내는 코드를 작성했지만, 실제로 실행했을 때 appendFile 자체가 이미 새로운 파일을 생성해내는데 성공하였기 때문에 error로 연결되지 않았습니다. 중복 콘텐츠 방지를 위한 if 밑에 또 다른 if로 fileExist를 사용해서 early return을 하는 이런 방식으로 처리를 하는 게 맞을까요? 아니면 제가 놓친 다른 catch error 가 있는 걸까요?
안녕하세요. 강의 잘 듣고 있습니다. libuv 발음이 '립유브이' '엘아이비유브이' '리버브' 등 발음법이 계속 바뀌네요. 다른 질문에서 답변으로 AI로 만든 강의 아니다라고 하셨고 직접 녹음한거라고 하셨는데 직접 하신거라면 조금 아쉬운 것 같습니다. 강의 내용도 흥미롭고 좋은 주제를 다루는 것 같아서 배울게 많아 정말 좋은데 이런 부분들이 조금 강의의 퀄리티를 떨어뜨리는 것 같아서 보완해주시면 좋을 것 같습니다. 강의는 정말 잘 듣고 있는 만큼 보완되었으면 하는 마음에 조심스레 글 남깁니다.
5. [실전 훈련] 사고 실험: 상태 누적 시각화 추적하기 예시에서 [Step 2] setTimeout과 Promise 등록 등을 보면 Call Stack이 비어있음 이라고 표현하셨는데, main 호출후 -> 동기코드 완료될때까지. Call Stack은 엄밀히 비어있는 상태가 아니지 않나요? 즉 console.log("D") 가 출력되기 전까지는 콜 스택이 비워지는 상태가 발생할수 없지 않나요? 혹시 제가 잘못 알고 있을수도 있으니 조심히 여쭙습니다.
다른 분도 질문달았는데, c가 안되는 이유가 선결제 없음이 조건이라 그렇다 하셨는데, 답지에는 다년계약 때문에 그렇다고 나와있는데요. 다년계약은 1년 약정에서 충족된 조건이고, 선결제 조건 이 부분은 그나마 따지자면 유연한 컴퓨팅 환경. 선결제를 안함으로써 가용가능한 비용이 늘어나서 유연한 컴퓨티환경이 된다라는것말고는 이해하기 힘든데, 선결제 부분은 어느 지문에서 없음으로 결정되는건지요
