[코드팩토리] [초급] NestJS REST API 백엔드 완전 정복 마스터 클래스 - NestJS Core
Spring(Java)을 약 1~2년 정도 공부하다가, 최근 입사 후 NestJS를 새롭게 배우고 있습니다. 공부하기 위한 강의를 듣던 중 문득 궁금증이 생겨 이렇게 질문을 남깁니다. NestJS를 사용하는 이유가 무엇일까요? 제가 지금까지 배워온 관점에서 보면, Spring은 생태계가 훨씬 풍부하고 레퍼런스도 많으며, 엔터프라이즈 환경에서 안정성이 매우 높다고 느껴졌습니다. 반면 NestJS는 비동기 I/O 처리에 강점이 있어 성능적으로 빠르다는 인상을 받았지만, 단순히 그 이유만으로 NestJS를 선택해야 할까 하는 의문이 들었습니다. 물론 기술 선택에는 여러 요소가 있겠지만, 실무적으로나 기술적으로 Spring 대신 NestJS를 선택하는 명확한 이유가 무엇인지 궁금합니다. 단순 궁금증이었습니다...!
강사님, 안녕하세요! DAG 파일을 추가하거나 수정할 때, Airflow UI에 변경 사항이 자동으로 반영되기까지 보통 1~5분 정도 소요되고 있습니다. 너무 오래 걸리는 경우에는 컨테이너를 재시작해 반영하고 있는데요. 혹시 Dags의 auto-refresh 주기를 단축시킬 수 있는 설정이나, UI 상에서 수동으로 바로 새로고침할 수 있는 방법이 있을까요? 현재 'apache/airflow:3.1.0' 이미지를 사용 중입니다.
안녕하세요. 게임 개발을 공부하고 있는데 KD트리는 처음 접하는 이론이어서 무척 감탄하면서 강의를 들었습니다 ! 아래 질의를 보고 저도 궁금해져서 질문을 달아봅니다. 혹시 동적 충돌을 구현하기 위해서 선행으로 알아야 될 지식이나 게임 개발에 필요한 다른 알고리즘도 존재 할까요? 또한 게임을 만들 때 따로 충돌 로직을 구현하나요 아니면 유니티나 언리얼에 존재하는 로직을 사용하면 될까요?
학습하는 분들께 도움이 되고, 더 좋은 답변을 드릴 수 있도록 질문 전에 다음을 꼭 확인해주세요. 1. 강의 내용과 관련된 질문을 남겨주세요. 2. 인프런의 질문 게시판과 자주 하는 질문(링크)을 먼저 확인해주세요. (자주 하는 질문 링크: https://bit.ly/3fX6ygx) 3. 질문 잘하기 메뉴얼(링크)을 먼저 읽어주세요. (질문 잘하기 메뉴얼 링크: https://bit.ly/2UfeqCG) 질문 시에는 위 내용은 삭제하고 다음 내용을 남겨주세요. ========================================= [질문 템플릿] 1. 강의 내용과 관련된 질문인가요? (예) 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예) 3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예) [질문 내용] 강의 수강하면서, 문득 궁금한거 질문드립니다. 실무에서는 어떤 제약 조건들을 주로 쓰고, 어떤 건 잘 안 쓰는지 궁금합니다.
제 1,2,3 정규형 강의를 들었을 때, 정규형은 종속 분리의 연속이다라는 생각이 들어서 질문 남깁니다. 앞에서부터 '제1 정규형 만족 -> 제2 정규형 만족 -> 제3 정규형 만족' 이라는 과정이 종속 분리가 차근차근 진행되는거죠? 제가 생각한 것처럼 이해하면 될까요?
안녕하세요, 강의 잘 들었습니다. 아직 실무에 flink를 사용해 본 적이 없어 조금 더 구체적인 장점등을 알고 싶어 질문 드리게 되었습니다. 사실 기존에는 kafka만을 사용해서 실시간 데이터 처리를 하는 사례도 많았던 것 같은데 이 때 추가로 flink를 사용할 때 kafka만을 사용할 때 보다 어떤 부분이 더 나은지 등에 대해 조금 궁금해져서 질문 드립니다.
안녕하세요 좋은 강의 잘 듣고 있습니다 undo 기능을 따라 구현하던 중 이슈가 있어 질문 드립니다 pen mode로 그린 뒤 eraser mode에서 일부 지움 -> undo 실행 -> 화면이 모두 지워집니다 원인은 eraser mode에서 mousedown 시 ctx.globalCompositeOperation = 'destination-out' 로 바뀐 상태가 유지된 채 restore() 내부에서 drawImage() 가 실행되기 때문인 것 같은데요, 제로초님이라면 eraser mode 종료 시점 ( mouseup )에서 source-over 로 되돌리는 방식이랑 restore 에서 source-over 로 바꾼 뒤 drawImage() 하는 것 또는 제 3의 장소?? 어떤 곳에 작업하실지 여쭙고 싶습니다
강의 내용 중에 Post요청을 받아 doPost안에서 doGet으로 요청을 넘겨주는 방식을 자주 사용한다고 언급하시면서, 요청을 하나의 메서드로 관리하기 위함이라고 하셨던 것으로 기억합니다. 근데 저는 메서드를 분리하는 게 더 좋은 방법이지 않나 싶습니다. 메서드 별 명확한 역할 분리도 중요하고, 만약 RESTful하게 설계하려면 이 방식은 권장되지 않을 거 같은데, 저런 식으로 샘플 코드가 자동으로 생성되는 걸 보니 갑자기 궁금해졌습니다..
[질문 템플릿] 1. 강의 내용과 관련된 질문인가요? (예) 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예) 3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예) [질문 내용] 여기에 질문 내용을 남겨주세요. 안녕하세요! 강의 잘 듣고 있는와중에 Future 관련 내용을 보다가 궁금한 점이 생겨서 질문 남깁니다. cancel() 기능이 필요한 실제 사례가 어떤 것이 있을까요? Future.cancel() 을 통해 실행을 취소시킬 수도 있다는 것은 이해가 됐습니다. 그런데 cancel() 기능이 필요한 실제 사례가 뭐가 있을지가 연상이 잘 안됩니다. 실제로 작업을 수행하다가 취소 처리를 해야하는 경우가 일단 뭐가 있을지 궁금합니다. 그냥 생각이 드는 건 특정 시간 제한이 지나서인데, 이건 get에 시간제한을 둬서 TimeoutException 하는 걸로 충분할 것 같아서요. cancel(false) 로 취소는 하되 과정은 수행하도록 내버려두는 케이스는 어떤 경우를 위해 있는건가요? 아예 interrupt로 취소를 시키는 경우는 막상 예시가 떠오르진 않지만 논리적으로 이해가 갑니다. 어떤 작업을 수행하다가 특정 케이스에서는 필요가 없어져서 취소시킬 수 있겠다 싶습니다. 그런데 cancel(false) 로 취소는 하되 그 과정을 수행하도록 내버려둘 필요가 있나 싶어서요. 어차피 cancel을 하면 true/false 어떤걸 넘겨줘도 get 하면 exception이 발생하면서 결과값을 못 얻는데 수행을 하게 내버려 둘 필요가 없을 것 같은데 어떤 경우를 위해 이렇게 구현이 되어 있는 건지 궁금합니다.
물론 회사마다 다르고 각 회사의 기존 스타일을 따라야 하는게 맞지만 독학하는 입장에서는 clang-format이 제공해주는 힌트들, 구글 스타일 가이드 혹은 인터넷에서 나오는 여러 c++ 스타일 가이드를 보면서 어떠한 스타일을 채택해 사용할지 고민이 됩니다 미리 손에 익혀두며 학습하고 싶어 질문드려 봅니다
안녕하세요. 현재 공식 Querydsl이 활발히 관리되는 것 같지 않아 OpenFeign에서 포크한 6.x 버전을 사용해 진도를 따라가고 있습니다. 당장은 Jakarta/Hibernate 최신 버전과 지원 문제도 있는 것 같고, orderBy 관련 SQL/HQL 인젝션 계열 취약점이 있는것 같아서 5.x 버전을 쓰고 있는데요.(물론 order by 관련해서 사용자에게 입력 받는 상황은 정말 드문 케이스 같긴 하네요) 장기적으로는 포크 버전의 유지·보수나 향후 호환성 측면이 조금 걱정됩니다. 이 상태로 6.x 포크 버전을 계속 따라가도 괜찮을지, 아니면 안정적인 5.10 계열(공식 안정 버전)로 머무르거나 돌아가는 게 나을지 의견 부탁드립니다!
안녕하세요. 잘 수강하고 있습니다. 수치화 하는 부분에 있어 궁금한 점이 있습니다! 개선점을 수치화 하기 전에, 개선에 앞서서 미리 문제 상황을 예상하고 고려 할 수 있는 방법도 궁금합니다. 미리 고려 했어야 하는 점과, 실제로 실무에서도 문제상황으로 마주하는 부분을 구분하기가 어려운 것 같습니다. 현업에서는 어디까지 미리 고민을 해보고, 어느 정도부터는 실제 문제로 마주하게 되는지 궁금합니다. 질문의 배경은 아래와 같습니다. 면접에서 개선 및 수치화 사례에 대해서 "해당 이슈는 매우 known이슈인데, 충분히 미리 고려 할 수 있는 부분이 아니었는지? 고민을 안했었는지?" 질문을 받았었습니다. 예를 들어 7초 -> 2초 줄이는 것보다 2초 -> 0.7초 개선하는것이 더 어려울텐데 설계나 개발전에 미리 고민해보고 2초로 시작 할 수 있었던 문제 아니냐 라는 질문 같았습니다! 수치화를 위한 수치화로 보인다거나, 사전에 고려하지 않는 태도로 보였을까봐 우려되는 지점이었습니다. 이러한 우려를 피하고 싶은데 고견 부탁드립니다 감사합니다!
