HTML 삽입 미리보기할 수 없는 소스 #1. Redis 설정 기록 1. 라이브러리 추가 https://velog.io/@qotndus43/Cache 1) 그래들 추가 dependencies { // Spring Boot Starters implementation 'org.springframework.boot:spring-boot-starter-data-redis' implementation 'org.springframework.boot:spring-boot-starter-cache' // Other dependencies } 2) redis 설정 spring: data: redis: host: localhost port: 6379 각 yaml 파일마다 별도의 host를 갖게 해도 괜찮음 그러면 각 서버..

HTML 삽입 미리보기할 수 없는 소스 #1. 캐싱 툴 조사 Ehcache vs. Redis vs. Memcached 1. Spring boot Starter cache 💡 스프링 부트에서 캐시를 사용할 수 있게끔 해줌 스프링 부트에서 제공하는 캐싱 추상화를 활성화하기 위한 스터터 의존성. 앱 단에서 어떤 캐시 구현체를 사용할 지 명시하지 않으면, 스프링 부트는 기본적으로 간단한 로컬 메모리 캐시를 사용함. 즉 해당 스타터를 사용하여 캐싱을 활성화하고, ehcache 등 캐시 구현체를 지정할 수 있음. 사용 방법 그래들 추가 컨피그 추가 서비스에 어노테이션 추가 ehcache 와 동일 2. Ehcache 💡 스프링에서 캐시를 어떻게 사용할 지 정해주는 어노테이션을 제공하는 라이브러리 https://vel..

HTML 삽입 미리보기할 수 없는 소스 #0. 개요 💡 java spring 으로 프로그래밍 하면서 마주친 몇 가지 간단한 지양하면 좋은 개발 코드 패턴. 심심치 않게 개발을 하다 보면 아 이런거는 사용하지 않는 게 좋다라고 다들 한 번쯤은 들어봤을 거다. 그래서 이런 포인트들을 간추려 정리하였다. #1. 쿼리 조회 시 * 사용 지양 쿼리 조회 시 필요한 컬럼만 뽑는 것이 좋다. * 로 모든 컬럼값을 불러와서 subquery 등을 구성할 경우 DB는 당연히 더 많은 cost 가 발생한다. SELECT * FROM users; SELECT id, name FROM users; #2. println() 사용 자제 참조: https://velog.io/@destiny1616/System.out.println-..

HTML 삽입 미리보기할 수 없는 소스 #1. 설명 💡 아래 글은 전부 intellij 환경에서 실행됨 참조: https://naver.github.io/hackday-conventions-java/ https://bestinu.tistory.com/64 네이버에서 코딩 컨벤션 formatter와 checkstyle을 제공해주신다. 협업 시 이를 각각 적용 후, 검사하여, 통일된 코딩 환경을 만들면 좋을 것 같다. naver-intelij-formatter 포맷팅해주는 역할 naver-checkstyles-rules checkstyle 시 따르는 룰들 local checkstyle 에서 naver-checkstyles-rules를 등록하여 룰을 지정해줄 수 있음 naver-checkstyle-suppre..

HTML 삽입 미리보기할 수 없는 소스 #1. 개요 각 API 에 대해 prod / dev / local 어디에서 호출할 수 있는 지에 대한 설정 추가를 위해 어노테이션 생성 기존 어노테이션으로는 각 API 가 아닌 Bean 단위로 Controller 속 API 전체에 대해 어느 서버에서 호출 할 수 있는 지 나타낼 수 있음 @Profile({"local"}) string[] 값 속에 어느 서버에서 해당 controller 속 API 들을 허용할 지 정하면 됨 @ConditionalOnExpression("'${spring.profiles.active}'.equals('dev')") 위 같은 방법도 가능 그러나 이 방법으로는 controller 내부 특정 API에 대해서 접근 제어를 할 수 없음. 그래서..

HTML 삽입 미리보기할 수 없는 소스 #1. 리팩토링 전 1. SW구조적 문제점 💡 Monorepo / 모듈 단위 개발 초기엔 특정 프론트엔드 개발자와 백엔드 개발자가 같이 협업하여 단일 모듈을 맡아 개발하였다. monorepo 구조가 이런 특징에 있어서 빠른 속도로 개발하기에 적합하였지만, 신규 인원이 많아지고, 코드의 양이 많아지며, 고도화가 필요한 시점에서 더 이상 monorepo 구조가 적합한 구조가 아니게 되었다. 단일 repository 에 api, db, 백엔드, 프론트엔드 코드가 전부 포함되어있고, 또한 각자 자신만의 모듈을 맡아 개발을 하다보니, 코드의 방대함, 코드의 통일성 부재 등으로 인한 가독성 저하 문제가 유발되었다. 또한 인과관계가 반대로지만, 백엔드 개발에 있어서 node.j..