GO SIWOO!

[리팩토링 일지] 팀 프로젝트, 나홀로 리팩토링 (6) - Redis를 통한 Open API 결과 캐싱(Caching) [리팩토링 일지] 팀 프로젝트, 나홀로 리팩토링 (5) - 응답 form & Global Exception [리팩토링 일지] 팀 프로젝트, 나홀로 리팩토링 (4) - 회원기능 구현을 위한 스프링 Security와 JWT발 📌 기존의 회원기능 gosiwoo.tistory.com 📌Redis에서 Ehcache로 이전 포스팅에서 Redis를 사용해 Open API의 부담을 줄이고 응답 속도를 향상했습니다. 하지만 이전에 사용한 방법은 Redis 저장소를 통해 API의 결괏값을 저장해 조회를 하는 방식으로 Redis의 In-memory 구조를 사용한 것일 뿐 캐싱을 사용했다고 확실히 말할 수 ..

[리팩토링 일지] 팀 프로젝트, 나홀로 리팩토링 (5) - 응답 form & Global Exception [리팩토링 일지] 팀 프로젝트, 나홀로 리팩토링 (4) - 회원기능 구현을 위한 스프링 Security와 JWT발 📌 기존의 회원기능 기존 프로젝트의 회원 기능은 kakao API를 통해서 진행했다. 그러나, 하드코딩 gosiwoo.tistory.com 📌그래서 Redis를 사용할 것인가? 결론부터 말하자면 해당 프로젝트에서 Redis를 통한 캐싱은 사용하지 않을 예정이다. 많은 고민을 해본 결과 단일 서버에서의 캐싱을 고려했을때 Global cache인 해당 방법을 사용하는 것은 다음과 같은 단점이 있었다. 배포를 했을 때 Redis 서버도 띄워줘야 한다는 비용적인 문제 단일 서버이기에 Cache..

Spring REST Docs를 위한 Test 코드 작성중 앞서 MockMvcRequestBuilders URL 요청에 관련한 IllegalArgumentException Exception을 해결한 후 다음과 같은 예외가 발생했다. org.springframework.restdocs.snippet.SnippetException: Path parameters with the following names were not found in the request: [myWordId] 해당 예외가 발생한 곳은 delete("/api/v1/myWord/1") 부분이다. 해당 요청은 아래와 같은 EndPoint 요청을 테스트 하는데 문제는 URL 변수를 가져오는 myWordId라는 PathVariable 부분에서 발생..

[리팩토링 일지] 팀 프로젝트, 나홀로 리팩토링 (4) - 회원기능 구현을 위한 스프링 Security와 JWT발 📌 기존의 회원기능 기존 프로젝트의 회원 기능은 kakao API를 통해서 진행했다. 그러나, 하드코딩 된 API 호출을 보고 적용하지 않고 프론트 팀에서 전달받은 인증 코드를 바탕으로 회원 정보를 Ha gosiwoo.tistory.com 📌3달만의 포스팅 약 3달 만에 리팩토링 관련 포스팅을 진행하게 되었다. 팀프로젝트를 2개 정도 진행하고 입사원서 작성과 그룹스터디... 많은 일이 있었지만 조금씩이라도 짬짬이 손 가는 대로 코드를 작성하였다. 오늘 작성할 포스팅 외에도 추가로 구현한 기능들도 꽤 있고 이 포스팅의 내용은 약 2 달반 전에 작성한 코드였다. 이미 완성하고도 남을 개인 프로젝..

📌 기존의 회원기능 기존 프로젝트의 회원 기능은 kakao API를 통해서 진행했다. 그러나, 하드코딩 된 API 호출을 보고 적용하지 않고 프론트 팀에서 전달받은 인증 코드를 바탕으로 회원 정보를 HashMap 형태로 (설정파일도 사용하지 않았다) 이를 Controller 단에서 Session으로 저장해 두는 방식을 사용하였는데... @Service public class KakaoAPI { public String getAccessToken(String authorize_code) { String access_Token = ""; String refresh_Token = ""; String reqURL = "https://kauth.kakao.com/oauth/token"; try { URL url ..

📌 리팩토링 이유 약 1년간 대학 동기들과 한국어 학습 웹 어플리케이션 웹 서비스 프로젝트를 진행한 적이 있다. 해당 프로젝트는 표준 국어 대사전 API와 Kakao 로그인 API, OpenAPI를 사용해 단어, 문장, 음성 한국어 검색, 사용자만의 단어장, 단어 퀴즈, 랭킹, 오픈사전등의 기능을 제공하는 프로젝트였다. 해당 프로젝트를 통해 공모전에서 은상 교내 대회에서 은상을 타기도 하는 등 많은 성과를 이루었지만 다음과 같은 곳에서 부족함을 느끼고 이 프로젝트를 내 힘으로 완벽히 리팩토링을 하고 싶었다. 1. Git/Github등 협업툴의 사용법과 관리 미숙 버전/이슈의 관리가 메신저로 이루어져 매우 힘들었다. 프로젝트의 결과물을 명확히 확인을 할 수 없었다. 2. 프로젝트 진행 중 mapper 사용..

📌에러 웹 프로젝트 팀에서 진행하고 있는 웹 프로그램 기능을 복기 하고자 들어갔는데 갑자기 스프링 프로젝트가 실행이 안되고 에러가 떴다... Exception in thread 'main' java.lang.NoClassFoundError ... 이번달 초까지만 해도 잘 실행되고 있었는데... 메인 메소드가 선언된 클래스도 SpringbootApplication어노테이션을 읽지 못한다, import도 안되는중... 'NoClassFoundError', 갑자기 클래스를 못찾겠단다. 찾아보니 컴파일 시점에 존재했던 클래스가 런타임에 찾을 수 없으면 발생한다고 한다. 이유를 생각해보니 얼마전에 윈도우 사용자 폴더가 한글이라 쿠버네티스 환경 구축하는데 어려움을 겪어 영어로 바꿔었는데 이로인해 빌드한 파일과 환경..

- Service를 사용하는 이유 기존 스프링 부트의 MVC 구조에서는 사용자의 DB에 대한 요청(Request)을 프론트 컨트롤러(Controller)에서 받고 이 요청을 컨트롤러(DAO)에서 직접 DB로 작업을 처리 후 결과값을 프론트 컨트롤러에 반환 하고 이를 뷰(JSP)에서 결과를 렌더링 하는 방식이다. 하지만 이런 기존의 MVC 방식은 DB의 여러 테이블을 다루게 된다면 프론트 컨트롤러에서 모든 테이블을 관리하게 되는데 이는 데이터 처리에 있어서 유연성이 떨어지게 된다. 이러한 유연성을 보완하기 위해서 서비스(Service)단을 만들게 되는데 Service단은 DAO를 호출하고 데이터 접근, 갱신을 하여 이로인한 비즈니스 로직을 수행한다. 이로인해 프론트 컨트롤러는 Request를 받고 Serv..