분류 전체보기 (19) 썸네일형 리스트형 [Independe] Main Post 첫 번째 성능개선 자취생 커뮤니티를 약 90% 완성하면서 성능에 대한 고민을 하기 시작했다. 특히 메인 화면 조회 성능이 가장 큰 고민거리였다. 메인 화면은 사용자들이 보통 처음 들어오는 페이지이기 때문에 빠르게 응답을 하지 않으면 사용자가 떠날 것이라 생각했고 요청에 대한 응답이 1초를 넘어가지 않는 것을 목표했다. 그러나 메인 화면은 다양한 게시글들을 보여줘야 하기 때문에 발생하는 쿼리도 많아 개선하기 어려워보였다. 우선 메인 화면에 필요한 데이터는 다음과 같다. - 인기 게시글 10개 - 추천 수 자취 게시글 10개 - 전체 카테고리 지역 게시글 5개 - 전체 카테고리가 아닌 지역 게시글 5개 - 인기 검색어 10개 - 자취 관련 영상 이중 게시글과 관련된 데이터는 게시글을 10개 조회하면서 게시글당 추천 수, 댓글.. [Independe] 전체 테스트 수행시간 단축 / Embedded Redis 도입 프로젝트의 테스트 코드를 작성하다 전체 테스트 수행 시 다소 시간이 많이 걸리는 문제를 해결했던 경험에 대한 글이다. 테스트 구조 / 테스트 환경 통합 @AutoConfigureMockMvc @SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT) public class FilesApiControllerTest { /* 생략 */ } @ExtendWith(MockitoExtension.class) public class PostServiceTest { @InjectMocks private PostServiceImpl postService; /* 생략 */ } @DataJpaTest public class RecommendPos.. [TickerBell] 백엔드 협업 구조 TickerBell 프로젝트를 진행하며 처음 백엔드 개발자와 협업을 진행했다. 프로젝트를 진행하다 보니 몇 가지 오류가 지속적으로 발생했고 원활하게 진행하기 위해 백엔드 개발 규칙이 필요했다. 가장 처음 정한건 깃 협업 규칙이었다. 한명의 개인 리포지토리를 포크해서 PR하는 방법도 있었지만 우린 Github의 organization을 이용해 협업을 했다. organization에 공용 프로젝트를 만든 뒤 서로 포크하여 작업을 한 뒤 PR을 진행하는 방식이었다. 그 다음 어떻게 해야 PR 또는 merge 시 코드간의 충돌을 방지할 수 있을지였다. 구글에 Git 브랜치 전략 등으로 검색하면 다양한 협업 방식이 나온다. 하지만 검색을 통해 살펴보면 master, feature, develop, release,.. [Independe] 소셜 로그인 도입 시 동일 호스트 문제 해결 해당 글은 프로젝트에 소셜 로그인을 도입하며 발생한 문제를 해결했던 방법에 대해 적은 글이다. 하지만 블로그를 운영하기 한참전에 해결했던 문제라 기억에 의존하며 쓴 글이며 자세한 디버깅 과정을 담아내지 못 해서 아쉽다. 자취생 커뮤니티 프로젝트를 진행하며 사용자가 편하게 로그인할 수 있도록 소셜 로그인을 도입했다. 도입 과정에서 많은 인가 서버를 모두 도입할 필요는 없다고 생각하여 설문을 이용해 가장 많이 사용하는 인가 서버만 도입하도록 했다. 해당 사진은 실제 설문의 결과로 카카오와 네이버 로그인 사용량이 제일 많아 카카오, 네이버 로그인을 도입하기로 했다. 하지만.. 도입과정에서 수 많은 오류가 있었다. 소셜 로그인 도입 당시 개인적으로 테스트해보기 위해 Thymeleaf를 이용해 SSR으로 소셜 로.. Redis / RedisTemplate 실험 프로젝트의 RefreshToken과 1:1채팅의 읽음 처리를 구현하기 위해 사용자가 소켓에 접속했는지 저장하기 위해 Redis를 사용하기로 했다. 사용자가 소켓에 접속했는지 관리하려면 소켓에 접속하고 나갈 때 마다 계속 데이터를 저장하고 삭제해줘야 하는데 RDBMS 보다 Redis에 저장하는 것이 더 효율적이라고 판단했으며 이전부터 Redis 라는 기술을 사용해보고 싶었다. 기존엔 구현하기 쉽다는 이유로 CrudRepository를 이용해 간단하게 구현했다. 하지만 CrudRepository를 사용하니 실제 Redis에 저장된 값들이 직관적이지 못 했으며 Transaction을 지원하지 않았다. @Getter @RedisHash(value = "refreshToken", timeToLive = 60480.. 불편해서 직접만든 CapsLock 표시 기존에 사용하던 키보드에 command 키가 망가져 새로운 키보드가 필요했다. 키보드를 가방에 넣고 집, 학교, 카페 등으로 이동한게 문제인거 같았다.. 친구의 추천으로 쿠팡에서 3만원대 가성비 좋은 블루투스 키보드를 구입했다. 작고 디자인도 마음에 들었지만 capslock 표시가 없는게 나에게 큰 단점이었다. 그게 뭐가 불편하냐고 할 수 있겠지만 난 사이트 로그인시에 capslock 표시가 안되면 비밀번호를 정말 많이 틀린다.. 그러던중 대학교 수업시간에 배운 AWT 강의가 떠올랐다. 강의를 듣던 당시에는 이걸 대체 어디에 써먹을 수 있을지 의문이었는데 잘만 활용하면 capslock을 화면에 표시할 수 있을거 같았다. 곧바로 난 자바 프로젝트를 하나 만들었고 강의 내용을 떠올리며 개발을 시작했고 결과물.. [Tickerbell] 테스트 시 S3, Redis 목킹하기 TickerBell 프로젝트를 진행하며 공연의 사진을 등록할 때 AWS의 S3를 이용해 사진을 저장해왔다. 나는 이벤트 등록 api를 개발했기에 해당 api에 대한 테스트 코드역시 MockMvc를 이용해 작성했다. 하지만 테스트에 사용된 이미지 파일을 그대로 S3에 올리는 것은 적절하지 않다고 판단했다. 만약 테스트 코드를 실행할 때 이미지 파일을 모두 S3에 올린다면 이는 엄청난 S3 자원에 낭비가 될 것이라고 생각했다. 또한 테스트시에 S3와 같은 외부환경을 의존하는것도 좋지 않은 것 같았다. 실제 AWS의 S3를 의존하지 않기 위해 구글 검색을 통해 방법을 찾아보았다. 처음 적용한 방법으로 build.gradle에 S3를 목킹하기 위한 라이브러리 의존성을 추가했다. // S3 Mock testImp.. [Independe] 채팅 DB 설계에 대한 고민 자취생 커뮤니티 개발을 진행하며 1:1 채팅을 지원해야 하는 요구사항이 있었다. 채팅과 같은 실시간 데이터 송/수신이 필요한 기능은 데이터베이스를 어떻게 구축해야할지 몰라 고민도 많이 하고 검색도 많이 해봤다. 검색결과 많은 사람들이 채팅과 같은 기능은 채팅방 정보 채팅방 이름, 참여자들 정도만 RDBMS에 저장하고 메시지와 같은 데이터는 모두 redis나 mongodb와 같은 nosql을 사용하라 했다. 이유는 RDBMS에 경우 실시간 데이터 저장에 있어 성능이 좀 떨어진다는 말이 많았다. 하지만 RDBMS 설계도 완벽하지 않은 내가 Nosql 설계를 하려니 데이터를 어떻게 저장해야될지 감이 잘 잡히지 않았다. 많은 고민끝에 아직 RDBMS로 채팅을 구현했을 때 성능의 저하를 경험해보지 못 했기 때문에.. 이전 1 2 3 다음
