형 나 지금 너무 재밌어서 잘 따라하던중 별거 아닌거에서 막혀서 좀 힘들어 형이 알려준 json 파라미터 넘기는 방법으로 해도 안되고 gpt 찾아서 진행 한거도 다 안돼는데 윈도우 환경에서 좀 힘든걸까 ?? 다른 수강생분이 올려준거도 봤는데 답변에 달아준 방법도 동작하지 않아 @Bean public JsonJobParametersConverter jobParametersConverter() { return new JsonJobParametersConverter(); } @Bean @StepScope public Tasklet terminatorTasklet( @Value("#{jobParameters['infiltrationTargets']}") String infiltrationTargets ) { return (contribution, chunkContext) -> { String[] targets = infiltrationTargets.split(","); log.info("⚡ 침투 작전 개시"); log.info("첫 번째 타겟: {} 침투 시작", targets[0]); log.info("마지막 타겟: {} 에서 집결", targets[1]); log.info("🎯 임무 전달 완료"); return RepeatStatus.FINISHED; }; }
카카오, 토스 개발자가 알려주는 수백개의 MSA 환경에서의 성능 보장을 위한 RPC 처리 기법
이제 앞으로 3개만 더 들으면 완강이네요! 빠르게 gRPC를 공부할수 있어서 좋았습니다. 강의를 마무리해가니 궁금한 점이있어 질문 남깁니다. 마이크로서비스가 1000개 이상되는 회사에서 데이터팀 백엔드 인턴으로 근무를 할 예정인데 데이터팀이다 보니 서비스들 전체를 아우르는 일을 해야한다고 들었습니다. 그래서 gRPC에 대해서 공부해오면 좋다고 해서 강의를 수강하게 되었습니다. 처음에 회사에 들어가면 어떤식으로 서비스들의 gRPC를 분석해야할까요? 혹시 추천해주시는 순서가 있으실까요? 예를 들어서 .proto파일을 먼저 확인한다 -> 등등 성공적인 백엔드 인턴을 위해서 추가적인 조언이 있으시다면 감사하겠습니다.
안녕하세요. 제미니님 유튜브 부터 인프런까지 참여하며 굉장히 많은 인사이트를 얻고있어 무한한 감사 인사를 올립니다. 질문 강의를 수강하며 제미니님이 던져준 키워드를 어떻게 곱씹어야하지? 라는 생각을 하며 두 가지 정도 질문을 드리게 되었습니다. Q1. "저같은 경우는 뭐 컴포넌트 같은 걸 좀 쪼개서 만들고 싶은데, 일단은 여러분들이 좀 혼합된 걸 느끼게 하려고 제가 풀어 놨어요" - 결제 코드 느끼기 13:17 이렇게 제미니님이 생각했던 코드를 보고 싶은데, 이 코드는 신규 강의였던 " 레거시 다루기 " 에서 개선 작업을 하나요? 아니면 저희에게 열린 사고를 던져주고 넘어가는걸까요? Q2. "success 메서드에 트랜잭셔널을 사용하는 것도 할 말이 많은데 기본적인 로직에서는 문제는 없다." - 결제 코드 느끼기 13:58 이 내용에서도 혹시 개선하는 부분도 질문 1번과 같이 레거시 다루기 강의에서 개선 하시나요? 개인적으로 success 에서 트랜잭션 어노테이션을 빼고, 저장하는 로직을 한 군데 모아서 거기 사용할 것 같은데 제미니님은 어떻게 하시는지 궁금하네요!
형 ... @Bean public Step threatAnalysisStep( JpaPagingItemReader<Human> humanThreatDataReader, ItemProcessor<Human, TargetPriorityResult> threatAnalysisProcessor, FlatFileItemWriter<TargetPriorityResult> targetListWriter ) { return new StepBuilder("threatAnalysisStep") .<Human, TargetPriorityResult>chunk(10, transactionManager) .reader(humanThreatDataReader) .processor(threatAnalysisProcessor) .writer(targetListWriter) .taskExecutor(taskExecutor()) // deprecated 되어서 안씀 // .throttleLimit() .build(); } ... 에서 .throttleLimit() 부분이 5 이후로 deprecated 된다고 명시되어 있어. 관심사 분리로 인해서 taskExecutor 정의 부분에서 설정하라고 권장하는 것을 확인했거든. 현재 강의가 사실상 Spring Batch 5.x 까지의 기본 내용과 원리를 살펴봤잖아 ? 그렇다 하더라도 혼란을 줄 수 있기 때문에 해당 부분은 삭제하던지 아니면 추가 내용을 기재해야 할 것으로 보여.
ProductOption을 fetch해 올때 DB레벨에서 where이랑 orderby를 하지 않고 애플리케이션 레벨에서 코틀린 filter와 sort를 하신 이유가 따로 있을까요? 성능상 DB에서 전체적으로 데이터를 가져오고 인메모리 작업으로 filter와 sort를 하는게 불리하지 않나 싶어서 질문을 남깁니다.
요구 사항이 자주 변경되는 것을 가정하는 프로젝트인 만큼 isUnique에 관련된 상수나 Recent day에 관한 상수를 properties로 빼서 yml에 관리하는 방식으로 구현해보았는데. 실무에서는 어떤 경우에 yml에서 관리하는 방식을 고려하고 어느 상황에 그냥 상수를 코드에 남기는지 궁금합니다.
"과도한 읽기 및 쓰기 트래픽이 몰려"라고 써있는데, 왜 답이 C가 되는지 잘 이해가 되지 않아 질문드립니다. 읽기 전용 복제본을 추가하면 쓰기 트래픽의 부하를 막을 수 있는건 아니라고 생각되는데 왜 답이 C가되나요? 혹시, 다른 답들이 애매해서 그런건가요? 아니면 읽기 트래픽을 줄일 수 있으니 쓰기트래픽이 많아도 읽기 트래픽의 부하를 줄임으로써 전체적인 트래픽의 부하가 줄어들기 때문인가요?
안녕하세요. histories() 응답에 PointHistory.id가 포함되어 있던데, 이 값을 내려주신 의도가 궁금합니다. FE에서 이 id를 직접 활용해야 하는 지점이 있는지 궁금해서요. 예를 들어 포인트 이력 상세 조회나 특정 이력을 식별해야 하는 기능을 염두에 두신 걸까요? 현재로서는 다른 필드들만으로도 충분하지 않나 생각되어, id를 포함하신 이유가 궁금합니다!
@Query( """ SELECT new io.dodn.commerce.storage.db.core.SettlementTargetSummary( settlement.merchantId, settlement.settlementDate, SUM(settlement.targetAmount), COUNT(settlement.id), COUNT(DISTINCT settlement.orderId) ) FROM SettlementTargetEntity settlement WHERE settlement.settlementDate = :settlementDate GROUP BY settlement.merchantId, settlement.settlementDate """, ) fun findSummary(settlementDate: LocalDate): List<SettlementTargetSummary> 이부분에서 where절에서 이미 settlementDate를 필터링하고 있는데 group by에서 settlementDate가 필요한 이유가 따로 있을까요? 어차피 parameter로 넘어온 settlementDate만 조회가 되는 로직이라 Group By에서는 필요가 없어보여 질문 남깁니다.
안녕하세요 강의 복습하면서 열심히 학습중입니다. 33강 문제 3번에서 퍼블릭 IP를 사용해서는 안된다는것은 인터넷 연결을 피해야한다고 생각하는데 D 번은 결국 NAT 게이트웨이를 통해 인터넷을 거쳐 S3와 통신하는거라 생각하고 있습니다. 결국 S3의 입장에서는 인터넷을 통한 통신이 들어오는거라고 생각해서요. 제가 잘못 이해한건지 알려주시면 감사합니다!
addReview()를 보면 리뷰 저장 이후에 포인트를 지급하는 로직이 함께 들어가 있는데, 제 기준에서는 포인트 지급이 리뷰 작성의 핵심 기능이라기보다 부가 기능처럼 느껴졌습니다. 그래서 이런 부분은 서비스 내부에서 직접 호출하기보다 이벤트를 발행하고, 별도의 핸들러에서 처리하는 방식으로 분리해도 괜찮지 않을까 궁금했습니다. (다만 제가 이걸 정말 "부가적인 책임"으로 봐도 되는지 조금 헷갈리기도 합니다.) 만약 실무에서는 이런 부가적인 로직을 서비스 메서드 안에 함께 둘지, 아니면 이벤트/이벤트 핸들러 형태로 분리할지를 어떤 기준으로 판단하시는지 궁금합니다. 또는 이런 경우 이벤트 외에 다른 방식으로 설계하시는 경우도 있는지 궁금합니다.
[코드팩토리] [초급] NestJS REST API 백엔드 완전 정복 마스터 클래스 - NestJS Core
cascade: true 후 createUserAndProfile의 user 안에 직접 profile을 넣고 postman에서 post (/user/profile)요청시 profile이 생성된 것처럼 보이지만 get(/users) 요청 시 해당 유저는 profile이 null로 떠야하는데 실습으로 post (/user/profile) 이후 get (/users) 요청하면 해당 유저가 profile 값을 가지고 있습니다. 코드를 똑같이 입력했는데 뭐가 문제일까요?
안녕하세요~ 강의 중 강사님께서 null을 되도록 허용하지 않는 것으로 보였습니다. 공감이 되었는데, CancelEntity.orderItemId 와 같은 곳에 -1 을 설정한 다거나 QnA.answer 에 Answer.EMPTY 를 설정하는 것은 어떤 장점이 있을지 궁금합니다. 저는 위와 같은 경우는 해당 필드를 nullable 로 하는 것이 이 필드는 없을 수 있다는 것을 더 명확하게 나타낼 수 있다고 생각했습니다. 좋은 강의 감사합니다!
