일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
- 트랜잭션
- yaml-resource-bundle
- 토이프로젝트
- 프로그래머스
- 백준
- 도커
- 리프레시토큰
- AWS
- 데이터베이스
- 국제화
- docker
- 티스토리챌린지
- JIRA
- java
- oauth2
- 스프링부트
- 액세스토큰
- 스프링
- 소셜로그인
- CI/CD
- 파이썬
- 오블완
- 메시지
- 스프링시큐리티
- springdataredis
- githubactions
- springsecurity
- Spring
- springsecurityoauth2client
- 재갱신
- Today
- Total
목록토이프로젝트 (8)
땃쥐네
이번에 다룰 주제는 메시지/국제화 기능 및 API 응답 규격입니다. (자바코드로 예외 메시지 내려주게 하는 방법 이미지) 사용자에게 응답을 내려줄 때 내려줄 메시지를 java 코드 상에 직접 작성하는 방법도 있긴 하지만, 이 방법은 다국어에 대해 열려있지 못 한 방식입니다. 그래서, java 코드 상에서는 메시지를 식별할 수 있는 code 를 관리하고 이 code를 기반으로 사용자 환경에 따라 제각각 다른 메시지를 내려줄 수 있게 하려고 합니다. 또 저는, API 응답 규격을 일관된 방식으로 내려주고자 하기 위해 API 응답 규격을 정해두려고 합니다. 1. 메시지/국제화1.1 MessageResolver 인터페이스 정의package com.ttasjwi.board.system.core.messagein..
1. Slf4j1.1 Slf4j 란?Slf4j 는 다양한 로깅 프레임워크(예: java.util.logging, logback, Log4j )의 퍼사드 역할을 합니다.실제 로깅 도구들에 대한 일반 API를 제공하고 로깅을 실제 구현과 독립적으로 만듭니다. 그래서 보통 스프링 개발자분들은 Slf4j 인터페이스를 의존하여 개발하고 구현체로는 logback 을 많이 사용합니다.실제로 스프링부트의 웬만한 starter 의존성을 추가하면 slf4j 의존성이 추가되고 기본 구현체로는 logback 이 사용됩니다. 1.2 파라미터화 로깅 (Parameterized Logging)/String variable = "Hello ttasjwi";logger.debug("Printing variable value: " + ..
이번 글에서는 자바/코틀린에서의 예외 개념을 한 번 짚고, 왜 제가 프로젝트에서 커스텀 예외를 정의했는 지, 어떤 식으로 사용했는지 설명해보도록 하겠습니다. 1. 예외 계층 커스텀 예외를 설명하기 전에 Java의 예외 계층을 설명해보겠습니다.제가 지금 사용하는 언어는 Kotlin 이지만 기본기는 Java 쪽에 있기 때문에 Java 기준으로 설명하겠습니다. Throwable은 모든 예외와 오류의 최상위 조상 클래스입니다.이 아래에는 Exception과 Error가 있습니다.Error는 주로 JVM 관련 오류나 시스템적인 문제로, 개발자가 예측하거나 처리하기 어려운 심각한 문제들입니다.예: OutOfMemoryError, StackOverflowError 등Exception 은 주로 개발자가 처리할 수 있는..
보통 프로젝트를 진행하다보면 A -> B -> C -> D -> E 와 같은 의존방향의 코드는 자주 작성됩니다. 이렇게 의존성의 방향을 알 수 있으면 뭐를 고쳐야할지 잘 보일거에요. 근데 의존성의 방향을 잘 못 관리한다거나, 계층을 넘어 의존하는 코드를 작성하면서 관리하다보면 위 그림처럼 B에서 E를 강하게 의존한 코드를 작성하게 되는 일이 생기고(특히 테스트 코드), E가 변경되면 D 뿐만 아니라 B의 코드를 변경하게 되는 일이 빈번하게 발생합니다. 무엇이 무엇을 의존하는지, 의존성의 방향은 어떤지 통제하기 힘들어지면 향후 코드 관리가 점점 힘들어집니다. 외부 모듈들을 테스트를 해보고 싶은데 모두 끌어와서 실행해야한다는 점도 저를 귀찮게 하는게 많았습니다.이메일 발송 라이브러리가 잘 작동되는 지 확인..
이번 글에서는브랜치가 푸시될 때마다 프로젝트 작업물이 EC2에 무중단으로 배포될 수 있도록 해보겠습니다.1. GitHub Actions 에 DockerHub / EC2 접근 자격증명 부여이전 글에서 지속적 통합을 GitHub Actions 를 통해 했듯, 지속적 배포 역시 GitHub Actions 를 통해 수행할 것입니다. 그런데 이전 글에서는 DockerHub, EC2 에 접근하는 작업을 하지 않았지만 이번에는 접근하는 작업을 해야합니다.제 DockerHub 에 도커 이미지를 push 한다거나, EC2 에 SSH 에 접속한다거나 하는 작업에 있어서는 몇 가지 자격증명이 필요합니다. 이것들을 우선적으로 준비해보겠습니다. 1.1 [GitHub Actions] DockerHub 액세스 토큰 준비 Git..
이전 글에서 AWS 전반적인 인프라 환경을 구성했습니다. 이번에는 프로젝트를 생성하고,풀리퀘스트에 커밋이 올라올 때마다 빌드테스트가 자동화되도록 하겠습니다.1. 스프링부트 프로젝트 생성, Git - GitHub - Jira 연동 프로젝트를 생성해보겠습니다. 일단은 간단하게 프로젝트를 생성하고, 구조를 바꿀 일이 있다면 이후 글에서 바꾸도록 하겠습니다. 이번 글에서는 배포 자동화에 초점을 맞추고 있기 때문에 복잡한 설정은 하지 않을겁니다. 1.1 스프링부트 프로젝트 생성 Intellij Ultimate 를 쓴다면 Spring Boot Initializr 지원 기능이 있으므로 그걸 써도 됩니다.근데 그렇지 않은 분들이 더 많은 것 같고 웹의 Spring Initializr 로 프로젝트를 생성했습니다.저는 자..
일단 프로젝트는 대충 어떤 기능을 구현할 지 정했는데, 이것을 어디에 배포할 지가 문제입니다.취준생 입장에서 비싼 돈을 지불해가면서 서비스를 배포하는 것은 감당이 안 되는 지라 AWS 프리티어 기능을 사용하기로 했습니다. AWS 프리티어는 1년동안 일정 사용량 내에서 기능을 무료로 사용할 수 있기 때문에 취준생 입장에서 사용하는데 큰 부담이 안 되더라구요. 일단 배포 기본 아이디어는 VPC 를 준비하고, 퍼블릭 서브넷에 EC2 를 한 대 둔 뒤EC2 내에 Nginx(도커 컨테이너)를 통해 들어오는 요청을 뒤의 스프링 서버(도커 컨테이너)로 포워딩 시키는 방식을 사용할 생각입니다. 첫번째로 구현할 스토리, 백엔드 인프라 구성(AWS EC2) 입니다. 대강 이 작업이 어떤 가치가 있는 지, 이 작업이 만..
백엔드의 기본기가 되는 게시판을 구현해보기로 했습니다. 화면 구현도 생각해봤는데, 백엔드 시스템 하나 구현하기도 생각보다 할게 많아서 백엔드 API 에 집중하기로 했어요.정말 여유가 생기면 프론트엔드 구현도 고려해볼 생각입니다. 게시판을 막상 구현하라고 하면 뭘 구현해야할지 감이 안 서서, 현재 시중에 유명한 커뮤니티 사이트 몇 군데를 찾아봤습니다. 네이버 카페, FM 코리아, 아카라이브, 디시인사이드, ...그 외에도 SNS 서비스인 인스타그램, 페이스북, 트위터 등등도 유명합니다.각각의 사이트의 구조를 겉에서 확인해보고 공통적인 것을 약간씩 추려내면서 기능을 간단하게 나마 기획해봤습니다. 어떤 기능이 있으면 좋겠다, 라는 간단한 생각에서 시작하여 이 기능은 어떤 흐름으로 구현될 것인지,어떤 방식..