현재 '토이프로젝트 저장소'라는 주제로 개인 프로젝트를 진행하고 있다. 게시글에 달린 태그를 기준으로 게시글을 검색할 수 있도록 했는데 이때 자동완성 기능이 있으면 사용자 편의성이 높아질 것이라 생각해서 자동완성 기능을 구현하기로 결정했다. 기존상황 기존의 검색창으 Tagify 라이브러리를 사용하여 아래와 같이 검색할 수 있도록 구성했었다. 위 사진도 언뜻보면 자동완성이 되는 것 같지만 반은 맞고 반은 틀리다. Tagify 라이브러리를 사용하면서 고정된 리스트에서 검색어와 태그의 prefix를 비교하여 동일한 데이터를 보여주도록 한 것이다. 따라서 사용자가 고정된 리스트에 없는 태그를 등록한다면 자동완성 데이터에 업데이트가 되지 않아 제대로된 자동완성이 동작할 수 없다. 그래서 이 문제를 해결하고자, 백..
문제상황 토이 프로젝트를 진행하고 있었다. 나는 스프링 시큐리티를 활용해서 인증/인가 작업을 처리했고 JWT를 활용하여 로그인을 구현하고 있기에 커스텀한 인증 필터를 하나 더 만들어서 스프링 시큐리티 필터에 추가시켰다. 스프링 시큐리티 같은 경우 필터기반으로 인증/인가 작업을 한다. 그래서 별다른 설정을 하지 않으면 모든 경로에 대해 필터를 지나가게하여 보안 작업을 처리한다. 이 때 이미지 또는 .css, .js, favicon 등은 필터를 거치지 않아도 접근이 가능토록 해야했기에 아래 코드를 사용하여 필터무시 설정을 해줬다. @Bean public WebSecurityCustomizer configure() { return (web -> web.ignoring().requestMatchers("/ima..
블로그프로젝트를 할 때 나는 프론트엔드와 백엔드가 분리된 방식으로 진행했다. 이 때 레이아웃에 대한 정보 중 자주 바뀌지 않는 자료들이 있다. 카테고리 정보 카테고리 정보는 블로그 주인이 변경하지 않는다면 자주 바뀌지 않는 정보이다. 가져오는 모든 카테고리 정보에 대해 애플리케이션 단에서 계층형 카테고리 작업까지 진행하기에 매번 조회한다면 성능상 문제가 될 수도 있다. 글의 개수 페이징을 위한 총 글의 개수 정보 또한 블로그 주인이 글을 추가하거나 삭제하지 않는이상 거의 변하지 않는 정보이다 이러한 정보들을 캐시에 담아두고 요청을 할 때 DB까지가지않고 캐시에서 가져오는 전략을 사용하면 애플리케이션의 성능을 높일 수 있을 것이다. 스프링 내장 캐시? 스프링 프레임워크는 자체 내장 캐시를 제공하는데 이 내..
티스토리 또는 velog를 보면 기본적으로 임시저장 기능이 있습니다. 그래서 이번에는 임시저장 기능을 구현해볼까 합니다. 요구사항 1분마다 임시저장 요청이 들어간다. 작성하고 있는 글의 제목이 없다면 임시저장불가 메시지를 띄운다. 생각해봐야 할 것 # 저장소를 DB를 사용할까? 저장소 클래스를 생성하여 사용할까? 임시저장은 말 그대로 중간에 저장하는 것입니다. 굳이 DB까지 갈 필요가 있을까란 생각을 했습니다. 하지만 저장소 클래스는 서버가 내려가는 순간 데이터가 삭제되기 때문에 임시저장기능의 의미가 없어집니다. 따라서 DB를 사용하기로 했습니다. # 임시저장 테이블을 따로 만들어야할까? 게시글 임시저장 테이블을 만든다면 그냥 게시글 테이블과 속성이 거의 똑같습니다.(제목, 게시글, 썸네일, 카테고리 등..
현재 블로그 만들기를 개인 프로젝트로 진행하고 있습니다. 어느정도 기능은 거의 완성되어서 서버를 돌려 확인해보고 글 목록을 조회하는 부분에서 쿼리가 어마어마하게 나가는 것을 확인했습니다. 원인 Board 엔티티를 조회했는데 Board 엔티티를 응답 DTO로 변환하는 과정에서 발생하는 BoardTag와 Tag 엔티티에 대한 지연로딩 때문에 발생하는 쿼리들이 위의 어마어마한 쿼리들의 원인이였습니다. 아래의 수행시간을 보면 115.2036ms 정도가 측정되었습니다. 확인해 보니 제가 작성한 JPQL에 fetch join을 적용하지 않고 단순히 Board 엔티티만을 가져왔었습니다. 해결 그래서 저는 fetch join을 적용해 보았습니다. 위 사진은 BoardTag 엔티티에 대해 fetch join을 적용한 뒤..
나는 이전에도 게시판을 두번정도 만들어 보았는데 그 때는 별다른 설계나 생각도 없이 바로 코딩에 들어갔다. 그래서 그런가 다른 기능을 추가하고 싶어도 내가 어디에 어떤 코드를 수정하고 추가해야할지 바로 찾기가 어려웠다. 이것이 개발자분들이 말하던 유지보수가 어려운 코드인것 같다. 그래서 이전 글에서 나는 어느정도 Entity에 대한 스펙을 만들었고 이를 토대로 개발에 들어갔다. 한명의 회원은 여러개의 댓글을 등록할 수 있으므로 1:N의 관계를 가진다. => 댓글 엔티티에서 회원 엔티티에대한 외래키를 가진다. 한개의 글은 여러개의 댓글을 가질 수 있으므로 1:N의 관계를 가진다. => 댓글 엔티티에서 게시글 엔티티에대한 외래키를 가진다. 한명의 회원은 여러개의 글을 가질 수 있다. 1:N의 관계를 가진다...
- Total
- Today
- Yesterday
- querydsl
- list
- 7568
- 스프링
- 덧칠하기
- springboot
- this()
- 백준#잃어버린 괄호#1541
- HTTP#HTTP특징
- 자바
- 4673번
- 오류
- controller
- 게시판#자바#JPA#Entity
- 프로그래머스
- Spring
- 회고
- 서블릿#Servlet
- 대충 만든 자판
- 파이썬
- 백준#서강근육맨#20300
- 11659
- 사탕 게임#백준#3085
- 백준
- MVC
- arraylist
- 백엔드#게시판
- java
- 1978
- 1316번
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |