HAN STORY

💡 Build 작업Next.js 로 만든 서버를 다른 곳에 배포하기 위해 터미널에 npm run build 위 코드로 build 를 하면 리액트 문법으로 작성한 코드들을 친화적인 html, css, js 파일로 바꿔주는 작업을 한다.그 다음에npm run start 명령어를 통해서 실제로 유저 요청을 처리할 수 있는 Next.js 서버가 완성된다.실제로 운영하는 사이트라면 클라우드에 올려서 npm run start 를 실행시킨다. 💡 Dynamic rendering / Static rendering- Dynamic rendering기본적으로 Next.js 는 페이지를 하나 만들면 기본적으로 static rendering 식으로 페이지를 보여준다.npm run build 시 생성한 html 을 보여주는..

💡 글작성 페이지 만들기export default function Write() { return ( 글작성 버튼 );} 우선 /write 경로로 페이지를 만들어줬다.form 태그를 사용해 위처럼 api uri 와 method 를 설정해준 후에 input 태그의 name 을 설정해주고 button 에 submit type 을 설정해주면 버튼 클릭 시 해당 데이터들이 서버로 전달된다.💡 글작성 서버 만들기최상단 경로에 pages 라는 폴더명과 함께 위처럼 파일을 만들면 /api/post/new 이렇게 api 요청을 보낼 ..

💡 Dynamic route 를 활용한 게시글 조회https://hanstory33.tistory.com/293 위 링크처럼 게시글 당 id 가 있고 게시글 목록에서 제목 클릭 시에 해당 id 게시글의 상세 페이지로 이동시키고자 했다.import {connectDB} from "@/util/database";import Link from "next/link";export default async function List() { const db = (await connectDB).db("forum") let result = await db.collection('post').find().toArray() return ( {result.map((item, i..

💡 개요이전 글: [싹틔움] 에러로 인한 Kafka Message 전송 실패 시나리오 대비 안전 장치 고민💡 개요 아웃박스 패턴 구현 고민1 : 아웃박스 패턴을 적용하면 Kafka 메세지 전송 전에 무조건 DB 로 부터 조회를 해서 불러오다보니 리소스가 낭비되지 않을까?고민1 해결: 아웃박스 패턴 변형hanstory33.tistory.com 메인서버에서 Kafka 를 전송 시에 생기는 에러는 Redis 와 Outbox 패턴을 변형해 대비를 해놓았다.추가로 Kafka Message 는 전송이 되었지만 Consumer 인 알림서버에서 이 Message 를 소비하지 못 했을 때의 시나리오를 대비해 안전 장치가 필요하다고 판단했고, 이를 DLQ 와 수동 재처리 API 를 통해 해결하고자 했다. 💡 DLQ ..

💡 개요 아웃박스 패턴 구현 고민1 : 아웃박스 패턴을 적용하면 Kafka 메세지 전송 전에 무조건 DB 로 부터 조회를 해서 불러오다보니 리소스가 낭비되지 않을까?고민1 해결: 아웃박스 패턴 변형 구조 구현 고민2 : 재전송을 시도해도 계속해서 Sent 값이 False 인 경우는 어떻게 처리하면 좋을까?고민2 해결: Redis 도입을 통해 각 데이터별 Count 및 Webhook 연결을 통한 운영 처리 고민3 : DLQ Topic 도입을 하는 것이 좋을까?이전 글: [싹틔움] API Gateway 도입을 통한 인증 역할 분담💡 개요이전 글https://hanstory33.tistory.com/318 [싹틔움] 04/07 개발일지 FeignClient 도입으로 분산 서버에서의 인증 문제 해결💡 개요..

💡 개요이전 글 [싹틔움] 04/07 개발일지 FeignClient 도입으로 분산 서버에서의 인증 문제 해결💡 개요메인서버와 알림서버가 분리된 현 구조의 알림서버는 누구나 다른 사람의 알림을 확인할 수 있다는 치명적인 오류가 있었다. 이를 해결하기 위한 고민을 담았다. 💡 문제 분석 @GetMappinhanstory33.tistory.com 기존 클라이언트에서 알림서버에 구독을 요청하고, Feign Client 를 이용해서 메인서버로 회원 정보를 가져올 때 매 번 요청마다 인증을 하기 위해서 메인서버에 요청을 하는 방식이 오버헤드가 발생하는 부분이라고 판단했다.메인서버와 알림서버 상단에 API Gateway 를 두어서 인증을 담당하는 서버를 따로 분리하도록 설정하고자 했다. 💡 아키텍처 수정🌱 ..

💡 개요메인서버와 알림서버가 분리된 현 구조의 알림서버는 누구나 다른 사람의 알림을 확인할 수 있다는 치명적인 오류가 있었다. 이를 해결하기 위한 고민을 담았다. 💡 문제 분석 @GetMapping(value = "/v1/notifications/{userId}/subscribe", produces = MediaType.TEXT_EVENT_STREAM_VALUE) public SseEmitter subscribe(@PathVariable Long userId) { SseEmitter emitter = notificationService.subscribe(userId); 기존 방식에서는 단순히 userId 값을 param 으로 받아서 구독하고 해당 userId 로 들어오는 알림 ..

✔️ Feign Client 란?Feign Client 는 HTTP 요청을 인터페이스만으로 처리를 할 수 있게 도와주는 클라이언트이다.Spring Cloud 에서 제공하는 @FeignClient 어노테이션을 이용해서 메서드 호출처럼 외부 API 나 다른 마이크로서비스를 쉽게 호출할 수 있게 한다. ✔️ 넷플릭스는 왜 Feign Client 를 만들었을까?넷플릭스는 전 세계 수억 명에게 서비스를 제공하면서, 초대형 마이크로서비스 아키텍처로 전환했다.서비스 간의 수많은 HTTP 통신을 안정적이고 효율적으로 처리해야 했고, 이 과정에서 문제들을 겪는다.  HTTP 요청 코드가 너무 많고 반복적이다.실패 처리(fallback)나 로드밸런싱을 일일이 다 구현해야 한다.코드가 복잡해서 유지보수가 힘들다.그래서 간결..

💡 목표싹틔움 서버에 Kafka 를 도입해 메인서버와 알림서버 사이에서 데이터들이 성공적으로 주고 받을 수 있고자 했다.📚 메인서버 Kafka 설정KafkaConfig더보기@Configuration@EnableKafkapublic class KafkaConfig { @Value("${app.kafka-brokers}") private String kafkaBrokers; @Bean public KafkaTemplate kafkaTemplate() { return new KafkaTemplate(producerFactory()); } @Bean public ProducerFactory producerFactory() { Map produce..

📚 RabbitMQ특징프로토콜: AMQP (표준 메시징 프로토콜 지원)메시지 전달: Push 모델 기반. 브로커가 소비자에게 메시지를 적극적으로 전달.큐 중심 설계: 메시지가 큐에 저장되고, 소비자가 이를 처리하는 전통적인 방식. 메시지 삭제는 소비자가 처리 후 ACK(확인 응답)를 보내면 이루어짐.라우팅: Exchange를 통해 Direct, Topic, Fanout, Headers 방식으로 유연하게 메시지 라우팅 가능.구성: 단일 노드에서 동작 가능하며, 클러스터링 지원은 있지만 Kafka만큼 분산 시스템에 특화되지 않음. 메시지 보장: 메시지 확인 및 재전송 메커니즘으로 높은 신뢰성 제공한다.사용 사례작업 큐 관리: 예를 들어, 사용자 등록 후 환영 이메일 전송, 이미지 변환 작업 등 비동기 작업..