시작이 반

https://github.com/tmdrl5779/login-boilerplate Spring Boot Spring Security JWT : Token Redis : For RefreshToken sava Kotlin : Language JPA : ORM H2 : DataBase

Tool : Jmeter 환경 : CPU 4Core 8Thread 1000명의 유저가 30초가 걸리는 api를 동시 호출 TEST1 구성 : netty + coroutine ( context : Dispatchers.IO ) @PostMapping("/api/test") suspend fun testApi():MutableMap = withContext(Dispatchers.IO){ log.info(">>>>>>>>>>>> start suspend") performService.measureTestPerform() } suspend fun measureTestPerform(): MutableMap = withContext(Dispatchers.IO) { val map = mutableMapOf() val..

코드를 개발하다 보면 같은 로직이 필요한 부분이 여러군데 있을 것이고 이러한 부분을 함수로 분리해서 처리한다. 이와 비슷하게 Spirng에서 흐름상 공통으로 처리해야 하는 부분이 있을 것이고 이를 위한 것이 필터, 인터셉터, AOP이다. 필터, 인터셉터, AOP의 공통점은 공통된부분을 따로 빼내어 처리하는 것이다. 필터(Filter) 필터는 스프링 컨테이너 외부에서 실행되는 공통 로직이다. 웹 컨테이너에 의해서 관리가 된다. 요청, 응답을 정제할 수 있으며 Dispatcherservlet 이전에 실행이 된다. (Spring과 분리되어야 하는 기능, 공통된 인증/인가 기능 등) 필터 메소드 - init() : 필터 객체 초기화 - doFilter() : 필터 전/후 처리 - destory(): 필터 객체 ..

싱글톤 패턴일때 스프링 빈의 이벤트 사이클 "스프링 컨테이너 생성" -> "스프링 빈 생성" -> "의존관계 주입" -> "초기화 콜백" -> "사용" -> "소멸전 콜백" -> "스프링 종료" 프로토 타입 스프링의 3가지 생명주기 콜백 인터페이스(InitalizingBean, DisposableBean) : 옛날 방식 해당 클래스에 InitalizingBean, DisposableBean인터페이스 implements afterPropertiesSet() : 의존관계 주입이 끝나면 호출되는것 destroy() : 빈이 소멸전 호출 설정 정보에 초기화 메소드, 종료 메소드 지정 : 외부 라이브러리에 적용할때 사용 @Configuration이 붙은 설정 정보에 빈등록시 메소드 지정하여 초기화 콜백, 소멸전 ..

업무 로직 빈 : 컨트롤러, 비지니스 로직이 있는 서비스, 레포지토리 등 비지니스 요구사항을 개발할 때 기술 로직 빈 : 기술적인 문제나 공통 관심사(AOP)를 처리할 때 점점 자동 빈 등록으로 가는 추세이다. 빈이 많아지고 설정 정보를 관리하는 것 자체가 부담이 된다. 자동빈을 사용해도 OCP, DIP를 모두 지킬 수 있기 떄문에 업무 로직에 관해서는 자동을 사용하는 것이 좋다. 기술 로직같은 경우 업무 로직에 비해 수가 적고 광범위하게 영향을 미치고 기술 로직같은 경우 잘 되고 있는지 아닌지 파악하기 어려운 경우가 많기 때문에 수동빈을 사용해서 명확하게 나타내는 것이 좋다. 또한 비지니스 로직에서 다형성을 적극 활용할 때 수동 등록을 사용해서 한번에 보기 쉽게 하는 것이 좋지만 그래도 자동 빈을 쓰고..

프로젝트 생성시 자꾸 찾아보는 것들.. dependencies { implementation 'org.springframework.boot:spring-boot-starter-thymeleaf' //타임리프 implementation 'org.springframework.boot:spring-boot-starter-web' //웹 //롬복 compileOnly 'org.projectlombok:lombok' annotationProcessor 'org.projectlombok:lombok' //mysql compile 'mysql:mysql-connector-java' //data-jpa implementation 'org.springframework.boot:spring-boot-starter-data..

삭제 let index = { replyDelete: function (boardId, replyId) { $.ajax({ type: "DELETE", url: `/api/board/${boardId}/reply/${replyId}`, dataType: "json" }).done(function (response) { location.reload(); alert("댓글삭제 완료"); }).fail(function (error) { alert(JSON.stringify(error)); }); } }

유튜브 강의를 듣다가 Entity를 Client, Controller, Service단을 모두 사용하는 것을 보고 Entity는 Client, Controller단에서 쓰이면 안된다는 것을 본적이 있어서 DTO, Entity의 관계에 대해 찾아봤다. (이미 강의를 들으면서 작성한 코드는 모두 Entity로 접근을 하였기 때문에 나중에 DTO로 바꾸는 리팩토링 작업을 한꺼번에 행봐야겠다.) Entity는 Controller, Client단에서 쓰이면 직접 쓰이면 좋은 설계가 아니다. Entity를 DTO로 바꿔 사용해야한다. Entity DB에 저장하기 위해 유저가 정의한 클래스 - Domain 실제 DB테이블과 매칭 RDBMS에서 Table을 객체화 시킨것 이라고 생각... setter금지 @Getter..