$ kill-9.. 킬구형 추석 연휴는 잘 보냈는가.. 처음에 텍스트로만 구성된 강의인 걸 결제한 후 알게되어 당황했지만.. 걱정 마라.. 금방 킬며들었다.. 눈으로 읽고 생각하는 즐거움을 알게되었다.. 무엇보다 그동안 피로했을 내 귀를 지켜줘서 고맙다.. 아직 강의 초반이지만 궁금한 부분이 있어서 질문 올린다.. 대용량 트래픽을 다루는 회사에서는 배치 메타데이터의 양도 어마어마할 것 같은데 실무에서는 배치 메타데이터를 어떻게 관리하는 지가 궁금하다.. 혹시 배치 메타데이터를 활용할 일이 없을 것 같으면 안쌓는 것도 권장하는 방법인가..
검색을 해보니 강의 내용 중 나오는 sql인젝션 xss, HttpOnly csrf, SameSite https 이 부분들은 보통 기본적으로 많이 선택해서 꼭 알아야 하고 연습해야 하는 것으로 생각됩니다 그 외에도 알려주신 것들에 대해 자세히 알아야 할까요? 아니면 이런 방법들이 있구나 하고 굳이 직접 사용해볼 필요는 없는 걸까요
킬구형 텍스트 강의임에도 몰입감 있는 구성에 연휴에 재밌게 공부하고 있어. 고마워 FlatFileItemWriter에 대한 흐름을 정리하고 질문 해볼게 1. sourceType() 메서드 내 객체 타입에 따라 FieldExtractor 구현체가 결정된다. 2. (Bug가 fix되기 전까지) sourceType() 메서드 내 객체 타입이 Record일 경우 names() 메서드 호출은 무시되고, Record 타입의 모든 property가 쓰일 수밖에 없다. 3. 그렇기에 Record 타입에서 필드 하나를 제외하고 파일을 쓰고싶다면, fieldExtractor() 를 사용한 커스텀 구성을 통하여 필드 하나를 제외해야 한다. 내가 강의를 보면서 정리한 흐름이고, 아래는 그 정리 중 나온 질문이야 Q1. BeanWrapperFieldExtractor 일 경우 필드 하나를 제외하고 싶다면, names() 에서 해당 필드만 제외해도 되나? Q2. 만약 위와 같은 방법이 된다면, RecordFieldExtractor 관련 Bug가 fix 된 후에 FieldExtractor를 직접 커스텀하는 경우가 별로 없지 않을까 싶은데.. 혹시 내가 생각하지 못한 부분이 있을까? 고마워 킬구형아
안녕하세요! 덕분에 아키텍처에 대한 큰 그림을 그려보며 강의를 듣고 있습니다. MSA 전환 시점 관련해서 질문 드립니다. 모놀리식 아키텍처에서 MSA로 전환하는 적절한 시점은 어떤 기준으로 잡는게 좋을까요? 물론 상황마다 다르겠지만, 강사님은 어떤 기준을 가장 중요하게 생각하시는지 궁금합니다. 예를 들어, Scale-out 한계, 빌드&배포 시간 증가, 혹은 서비스 크기와 복잡성 같은 요소들.. 이 있을 것 같은데 제가 미처 생각 못한 부분이 있다면 덧붙여 답변 부탁드립니다. 감사합니다!
[코드팩토리] [초급] NestJS REST API 백엔드 완전 정복 마스터 클래스 - NestJS Core
Spring(Java)을 약 1~2년 정도 공부하다가, 최근 입사 후 NestJS를 새롭게 배우고 있습니다. 공부하기 위한 강의를 듣던 중 문득 궁금증이 생겨 이렇게 질문을 남깁니다. NestJS를 사용하는 이유가 무엇일까요? 제가 지금까지 배워온 관점에서 보면, Spring은 생태계가 훨씬 풍부하고 레퍼런스도 많으며, 엔터프라이즈 환경에서 안정성이 매우 높다고 느껴졌습니다. 반면 NestJS는 비동기 I/O 처리에 강점이 있어 성능적으로 빠르다는 인상을 받았지만, 단순히 그 이유만으로 NestJS를 선택해야 할까 하는 의문이 들었습니다. 물론 기술 선택에는 여러 요소가 있겠지만, 실무적으로나 기술적으로 Spring 대신 NestJS를 선택하는 명확한 이유가 무엇인지 궁금합니다. 단순 궁금증이었습니다...!
안녕하세요 강사님! 강의 잘 듣고 있습니다. 실제 서비스 환경에서 로드 밸런서를 두는 시점(예: 트래픽 기준이나 서버 수 기준)을 어떻게 판단하시는지 궁금합니다. 단순히 서버 부하율이 높아졌을 때 적용하는 건지, 아니면 아키텍처 설계 초기에 미리 구성하는 경우가 더 일반적인지도 궁금합니다.
[코드팩토리] [초급] NestJS REST API 백엔드 완전 정복 마스터 클래스 - NestJS Core
CRUD 중 DELETE 요청의 경우 어떤 기준으로 반환 타입을 정하는 게 좋을지 궁금합니다. 제가 생각하기에는 아래 두 가지 방식이 있을 것 같습니다. 강사님께서는 이러한 상황에서 어떤 기준을 표준으로 사용하시는지 궁금합니다. 1. 일관된 응답 return { success: true, data: null }; CREATE , READ , UPDATE 와 동일하게 성공 여부를 명시 하고 data 는 null 로 처리하여 응답 구조를 통일하는 방식입니다. 이렇게 하면 프론트엔드에서 일관된 형태로 응답을 처리 할 수 있을 것 같습니다. 2. HTTP 표준 준수 (204 No Content) @HttpCode(204) 응답 본문을 따로 내려주지 않고 상태 코드만 반환 하는 방식입니다. 이 경우 RESTful 표준에 부합 하고 불필요한 네트워크 비용을 줄일 수 있을 것 같습니다. 다만 프론트엔드에서는 응답 본문이 없어 분기 처리가 필요 할 수도 있을 것 같습니다. 이 두 가지 방식 중에서 실무에서는 어떤 기준으로 선택하시는지 또는 프로젝트 성격에 따라 구분하는 기준이 있을지 궁금합니다.
안녕 킬구형 형 때문에 이번 추석 연휴 재밌게 보내고 있어. 고마워 형. 강의를 보면서 예제 소스에 대한 궁금증이 생겨서 질문을 남겨. 6장. 작전4: 원격 청킹 (Remote Chunking) - 전방위적 타격이 시작되다. ☠ ' 데이터 변화 모듈(SerDes Classes)' 예제에서 예외 객체로 MessageConversionException을 사용하는데 클로드에서는 통상 Kafka를 사용할때는 org.apache.kafka.common.errors.SerializationException 을 사용해야 kafka와 호환이 된다고 하더라구. 이거에 대해 설명 부탁해도 될까?
킬구형 Spring Data JPA 사용하면 JpaRepository 인터페이스를 사용해서 PlatformTransactionManager , DataSource 를 자동으로 주입받아 사용할 수 있는데, 강의에서는 스프링배치의 세밀한 조정을 위해 일부러 JpaRepository 를 사용하지 않는 거야? 아래 두 강의에 둘 다 데이터소스와 트랜잭션매니저를 직접 활용하고 있어서 궁금해서 물어봐 3장. 작전1: 관계형 데이터베이스 읽고 쓰기 (테이블의 심장에 처형장을 세우다 ☠ ) OPERATION DOUBLE TAP - Spring Batch Test (추가) 생각해보니 예전에 아주 간단한 로직의 스프링배치 앱을 JpaRepository , JPQL을 이용해서 만들었던 만들었던 기억이 있는데,, 혹시 JpaRepository 을 일부러 사용하지 않는 이유가 있는지 궁금해
실제로 실행을 못해보는환경이라서 질문하는건데, JobLauncher를 활용한 REST API 구현 의 예제같은경우 컨트롤러 하나를 생략없이 다 표현한거같은데 jobRegistry 는 di받지않았는데 어떻게 실행하는거임? 빼먹은건가? job = jobRegistry.getJob(jobName);
TransactionManager 분리 에 대해서 이해가 잘 가지 않는게 있어. 실제 운영 환경에서는 배치와 비즈니스 데이터 DB를 분리하는게 필수라고 했잖아? 근데 이 분리의 단위가 배치용 메타데이터 저장만 분리를 하는게 맞는거야? 현재 사이드 프로젝트에서 멀티모듈 구조에 (MSA는 아님) API 모듈과 배치 모듈을 따로 분리한 상태야. 유저 데이터에서 생일을 뽑아서 내일 생일인 유저에게 FCM 을 발송하는 배치를 만드는데, 이때 만들어준 예제처럼 @BatchDataSource와 비즈니스 로직용 @Primary DataSource를 분리하게 되면, API 모듈용 DB Connnection을 배치에서도 똑같이 갖다 쓰는거 아니야 ?? 즉, 배치에서 API 쪽 커넥션을 가져다 써서 배치가 돌 때 커넥션이 고갈날 수 있지 않을까? 라는 생각이 들었어 지금 이해한 바로는 @BatchDataSource, @BatchTransactionManager를 분리하고 주입해줘도 Reader -> Processor -> Writer 에는 @Primary 걸 쓰는것 같은데 맞아 ? 나는 DB 분리와 함께, 비즈니스 로직에 대한 커넥션, 트랜잭션도 배치용으로 분리하고 싶은데 이럴땐 어떻게 해야해? 특히나 배치에서도 JpaTransactionManager를 쓰고 싶은 경우에는 어떻게 해야해 ? 원하는 바는, API 처리용 DB 커넥션은 커넥션대로 있고, 배치 메타데이터용 커넥션 따로, 배치에서 라이브 DB에서 유저 데이터를 가져오는 커넥션 따로 구성하고 싶어 (배치가 API 모듈 에 영향을 주지 않았으면 해서,,,) 혹시 내가 강의를 제대로 이해를 못한거라면 알려줘
킬구형 강의 자료 중간에 이상한 문구 발견해서 제보해 강의 회차: 5장. 작전4: Flow - 배치의 흐름을 지배하라 (분기점에서 생사를 쥐락펴락하라 ☠ 🏴☠ ) 이상한 문장: 즉, Spring Batch의 암시적 전환 규칙 대상에서 제외된다는 뜻이다. 재시도 Claude는 실수를 할 수 있습니다. 응답을 반드시 다시 확인해 주세요. 강의 자료 중간에 LLM에서 가져온 내용을 잘못 편집한 것 같아.
가령 다음과 같이 g etExecutionContextSerializer() 메서드를 오버라이드하면 g에 볼드처리안됨 -- 원시적 침투 예제의 BatchConfig에서 DefaultBatchConfiguration 상속을 제거하고@EnableBatchProcessing을 추가하자. 다음과 같이 말이다. 예제 밑의 예제가 그냥 기존 DefaultBatchConfiguration 방식만 나와있음 아마 기존과 수정을 두개 다 표시하는식으로 하고싶었을거같음 -- JobContext/StepContext: Late-Binding의 최종 무기고 키룩형 JobContext/StepContext가 존재하면 배치 스코프가 활성화된 상태라는 것은 알겠어. 근데 이 JobContext/StepSontext 대체 어디에 써먹는거지? 단순히 활성화를 의미하는게전부인가? 키룩형 -> 갈매기가 되고싶은 내면의 소리일수있음 괜찮음 주변에 돌멩이 지망생도 있고 독수리 지망생,딸기우유 지망생도 있어서 이해할수있음