Go Gradually - Repository

감사가 무너지면 꾸준함이 무너진다.조급해지기 전에, 대안을 찾기전에, 충분히 감사했나?이번 주의 감사: 원 없이 MQ + 알림 시스템 개발 + gRPC 써봤다.항상 무언가를 수행하기.체계적인 상태를 유지하기.큰그림 그리고 핵심 짚기.처음부터 끝까지 차근차근 전개하기.현 시스템에 대한 감사를 유지하기.보상 체계를 깨끗히 유지하기.입장 중심이 아닌 이익 중심으로 사고하기.윈-윈 전략 생각하기.다음에 무엇을 해야 할 지 상상하기.이번주에 한 것RabbitMQ + AsyncAPI 설계 및 구현마이크로서비스 간 이벤트 기반 통신 시스템 구축 gRPC 사용법 습득푸쉬알림 기능 밑바탕 & 로직 작성이번주에 하지 못한 것DB Delete 작동 방식 깔끔하게 정리하기데이터 지역성 정리푸쉬알림 기능 버그 수정AI 모델 설..

백엔드 서버 관점에서 일반적인 이벤트 발행의 Best Practice를 생각해보자.새로운 방법의 발견이 아닌, 일반적인 방법을 정리 후 적용하는 게시글이다. 트랜잭셔널 아웃박스 패턴 (Transactional Outbox Pattern)프로듀서 -> MQ 사이의 1회 이상 전송을 보장하는 매커니즘(패턴)이다.DB의 트랜잭션은 사용자의 요청과 DB 상태 변경을 원자적으로 묶어준다. 하지만, DB 상태 변경과 이벤트 기록, 그리고 이벤트 발행까지는 원자적으로 묶이지 않는다.트랜잭셔널 아웃박스 패턴은 DB 상태 변경과 이벤트 기록을 트랜잭션으로 묶는다.하지만, 트랜잭션 아웃박스 패턴은 1회 이상 발행 보장이지, 1회 발행 보장은 아니다.즉, 중복 발행 가능성이 있다.발행 후 해당 메시지를 발행함을 표기하지 못..

우리가 특정 데이터를 JVM에 올리고 싶을 때, 이를 안정적으로 업로드할 "마법"이 필요해진다.이 예로는 공개 키 파일과 같은 것들이 있다.만약 키를 평범한 상대경로/절대경로로 가져오고 있다면, 이는 현재 환경에 종속적인 빌드 결과가 된다.(참고로 비밀 키와 같은 secret값들은 엄격한 운영 상황에서는 배포의 범위가 빌드 수준까지 넓어져 클래스패스에 올리지 않는다.)이때, 클래스패스라는 용어를 곧잘 접하게 된다. 클래스패스는 자바의 JVM 이 클래스를 로드할 때 사용하는 클래스로더와도 곧잘 얽히는데, 지금부터 이 클래스패스에 대해 빠르게 알아보자.1. 클래스패스란 무엇인가간단히 말하면JVM이나 컴파일러가 .class 파일과 리소스(예: .properties, .json, .xml)를 찾기 위해 검색하는..

나는 보통 내 이야기를 다른사람에게 하는 것보단, 다른 사람의 이야기를 듣는 것을 좋아한다. 사실 이런 글을 적는 것도 오만해지는 것 같아 그리 좋아하진 않는다. 단지 기록을 위해 남겨둔다. 브레인 스토밍이나 친목을 위한 대화 과정에서는 이것들이 유의미할 수 있지만, 내가 집중하고 있는 순간에는 그런 것들이 거슬리는 순간이 있다. 그럴 때 상대방에게 매몰차게 대하게 되고, "기분파"가 되는 듯한 감각, 상대방에 대한 미안함도 조금 생기게 된다. 어줍잖은 진심이 아닌 “진짜 진심”이 담기면, 나도 묘르게 말에 독기가 서리게 된다.항상 "직설적인 내용"에 "완곡한 톤"으로 말하려고 하는데, 쉽지 않은 것 같다. 이에 대한 정말 좋은 기준이 있다. "이 행동을 함을 통해, 듣는 상대방을 강제적으로 움직이..

웹 푸쉬 알림은 표준 Web Push 프로토콜을 따르며, VAPID 인증 방식을 사용하여 브라우저에 푸쉬 알림을 전송한다.이때 VAPID(Voluntary Application Server Identification)는 애플리케이션 서버가 푸쉬 서비스에 자신을 식별할 수 있도록 도와주는 메커니즘이다.VAPID는 그 자체로 푸쉬 서버에게 자신을 알리는 ID가 됨과 동시에, VAPID는 공개 키 암호화 방식을 사용하여 서버가 푸쉬 요청을 보낼 때 자신을 증명할 수 있게 한다.Web Push 구현 목표브라우저에서Notification 권한 요청pushManager.subscribe() 로 endpoint, keys.p256dh, keys.auth 획득서버에서VAPID 키 쌍 생성 및 관리payload 암호화,..

추천 이전 글: Rabbit MQ의 이름 짓기 [RabbitMQ] Rabbit MQ의 이름 짓기개발자에게 가장 중요한 역량은 "이름 짓기"이다. 이름을 잘 지어둬야 나중에 읽을 때 빠르고 헷갈리지 않게 읽을 수 있기 때문인데, RabbitMQ 사용 시에는 이름을 지어야 할 부분이 세 군데나 있다dev.go-gradually.me Rabbit MQ를 이용한 이벤트 송/수신 방식을 설계하려면, 이 또한 계약을 설계해야 한다.프로토콜, API, 메시지 포맷 등을 설계하는 것은 성능 최적화 이상 중요한 백엔드 개발자의 매우 중요한 역할 중 하나이다.MSA 에서 이벤트 기반 메시징을 설계할 때, 다음과 같은 사항들을 고려해야 한다.프로듀서 주체Exchange nameRouting key컨슈머 주체Queue nam..

개발자에게 가장 중요한 역량은 "이름 짓기"이다. 이름을 잘 지어둬야 나중에 읽을 때 빠르고 헷갈리지 않게 읽을 수 있기 때문인데, RabbitMQ 사용 시에는 이름을 지어야 할 부분이 세 군데나 있다. 생산자 선언ExchangeRouting Key소비자 선언QueueBinding key (routing key에 의존적)나는 딱히 이름 짓기에 재능이 없어서 매번 AI에게 도움을 많이 받는데, 적어도 이름을 짓는데 어느정도 규칙이 있어야 나중에 읽을 때 무리가 없기 때문에, 각각의 수행하는 역할과 책임에 집중해서 이름을 짓는 규칙을 정해본다.과거 scheduleMemberNestedDtoMap 이라는 해괴한 이름을 짓고 팀원에게 쓴소리를 들은적도 있었다... 기본적으로 위 세 요소는 각각 다음과 같은 역할..

항상 무언가를 수행하기.체계적인 상태를 유지하기.큰그림 그리고 핵심 짚기.처음부터 끝까지 차근차근 전개하기.현 시스템에 대한 감사를 유지하기.보상 체계를 깨끗히 유지하기.입장 중심이 아닌 이익 중심으로 사고하기.윈-윈 전략 생각하기.다음에 무엇을 해야 할 지 상상하기.이번주에 한 것핀잇 프론트 구현핀잇 Auth 구현핀잇 OIDC 연결카페 알바배포 방식 정리이번주에 하지 못한 것DB Delete 작동 방식 깔끔하게 정리하기데이터 지역성 정리푸쉬알림 기능다음주에 할 수 있는 것AI 모델 설계DB Delete 작동 방식 깔끔하게 정리하기코틀린 코루틴 학습다음주에 할 수 없는 것Double DQN 논문 리뷰주니어 백엔드 개발자가 반드시 알아야 할 실무 지식 글 작성API 사용 로깅 - 백엔드 성능 테스트용다음주..

이번 글은 이전 글의 다음 단계인 2, 3단계에 대해 다룹니다.코드는 다음 링크를 통해 확인 가능합니다. GitHub - GoGradually/pinit-authContribute to GoGradually/pinit-auth development by creating an account on GitHub.github.com 첫 MSA 도입, 한번에 다 만들려고 하면 복잡하다.각각 독립적인 기술인 만큼, JWT + OIDC 조합 두 단계로 나눠서 접근하자.목차내 JWT 인증 흐름 먼저 만들기그다음 OIDC 로그인 붙여서 “로그인 수단”만 확장하기회원가입 이벤트 발행 + be 서버에 공개 키 공유해서 인증 연동하기2. OIDC (외부 로그인) 붙이기(0) OIDC의 이해User-Browser사용자가 브라우..

코드는 다음 링크를 통해 확인 가능합니다. GitHub - GoGradually/pinit-authContribute to GoGradually/pinit-auth development by creating an account on GitHub.github.com 첫 MSA 도입, 한번에 다 만들려고 하면 복잡하다.각각 독립적인 기술인 만큼, JWT + OIDC 조합 두 단계로 나눠서 접근하자.목차내 JWT 인증 흐름 먼저 만들기그다음 OIDC 로그인 붙여서 “로그인 수단”만 확장하기회원가입 이벤트 발행 + be 서버에 공개 키 공유해서 인증 연동하기 이번 글에서는 0~1번 내용에 대해 다룬다. 0. 큰 그림 결정하기아키텍처 결정pinit-auth = 인증/토큰 발급 서버pinit-be = 일정/통계..