본문 바로가기

spring

 (27)
접근 제어 부분 리팩토링 시작하기에 앞서 프로젝트를 진행하는데 있어 접근 제어에 대한 부분을 Spring Security를 이용해 구현했다. 어떤 부분에 대해 제어가 필요했는지에 관해 먼저 알아보자. 먼저, 기본적인 처리부터 알아보자. 정규 회원의 정보 수정은 웹 관리자 혹은 자기 자신만 가능하다. 정규 회원의 회원 탈퇴는 웹 관리자 혹은 자기 자신만 가능하다. 이 부분에 대한 처리는 어느 웹 서비스에서도 동일하게 적용될 것이다. 우리 서비스에서는 스터디에 대한 서비스를 추가적으로 제공한다. 이 부분에 대해서 추가적인 요구사항이 발생하게 된다. (C - 생성, R - 조회, U - 수정, D - 삭제) 스터디 내부를 들어가는 것은 오직 스터디 회원만 가능하다. 스터디 내부에 추가적인 게시판을 만드는 것은 웹 관리자 혹은 스터디 ..
[WebRTC] Janus를 활용해 화상회의 만들기(Spring편) - (1) 요구사항 실제로 화상회의를 구현하기 전에 요구사항을 명확히 하려고 했다. 화상회의에서 요구되는 사항은 다음과 같다. 스터디 회원은 누구든지 화상회의 방을 생성할 수 있다. 생성된 화상회의는 스터디에 종속적이고 스터디에 속해있지 않은 회원이 조회할 수 없다. 생성된 화상회의는 웹 관리자, 스터디 관리자, 회원만이 수정 및 삭제할 수 있다. 이를 간단하게 그림으로 표현하면 다음과 같다. 현재 우리 서비스에는 백엔드 스터디와 프론트엔드 스터디가 존재한다. 백엔드 스터디에는 A라는 사람이 참여 중이고 프론트엔드 스터디에는 B라는 사람이 참여하고 있다. 이 상황에서 백엔드 스터디에 가입한 A라는 사람은 백엔드 스터디에 존재하는 모든 방에 모두 들어갈 수 있다. (비밀번호가 없는 방이라고 가정) 마찬가지로 프론트엔..
JPA에서의 일급 컬렉션 적용 엔티티를 다시 값 타입 컬렉션으로 전환 바로 이전 포스트에서 값 타입 컬렉션을 엔티티로 승격시킨바 있다. 그 이유는 이전 포스트에도 설명했지만 추후 수정이나 추적의 여지가 있기에 해당 부분에 대한 변경을 진행해보았다. 물론, 태그라는 특성 자체가 수정이나 추적의 여지가 큰 건 아니지만 한 번 진행해본 부분이였다. 해당 부분을 수정한 뒤, 협업하는 팀원과 함께 논의를 거쳐 요구사항을 더 명확히 하기로 하였다. 그 결과, 태그 자체를 수정하는 로직은 존재하지 않으며 수정을 거치기 위해서는 단순 삭제 후 새로운 것을 추가하는 방향이며 태그를 추후 업데이트하고 싶다면 업데이트된 태그들을 담은 리스트로 기존 리스트를 대체하는 것이였다. 이 요구사항을 정리해보자. 수정은 불필요하다. 태그 요소들의 변경은 리스트 자..
값 타입 컬렉션 ➡ 엔티티 값 타입 컬렉션을 엔티티로 그전에 이를 적용하게 된 계기부터 살펴보자. 이전 포스트에서 태그에 대한 부분에 대해 @ElementCollection 어노테이션을 통해 태그들을 값 타입 컬렉션으로 관리해주었다. 나는 태그에 관한 부분에 대해 값 타입 컬렉션에서 엔티티로 승격하기로 한 두 가지 이유가 존재했다. ​ 첫 번째는 태그에 대한 요구사항의 변화에 유연하게 대처하고 싶었다. 태그 자체를 값 타입인 String 타입으로 저장하다보니 실제로 변경되거나 삭제되면 더이상 추적할 수 없고 그대로 다른 String으로 변하거나 삭제되어버린다. 추후 태그 자체의 수정을 가능하게하고 추적이 가능하게 할 수 있기 때문에 이에 대한 부분이 생긴다면 더 이상 값 타입으로 유지할 수 없고 엔티티로 승격해야하기에 미리 이 부..
@ElementCollections 사용기 값 타입 컬렉션 사용기 (feat. @ElementColletion) 이번에 값 타입 컬렉션을 사용하게 되었다. 값 타입 컬렉션이란 컬렉션에 값 타입을 담는 것을 의미하는데 값 타입이라는 것이 정확히 무슨 뜻인지에 대해서 알아보자. 값 타입은 흔히 엔티티와 많이 비교된다. 먼저, 우리에게 익숙한 엔티티에 대해서 먼저 알아보자. 엔티티는 우리가 흔히 @Entity로 정의하는 객체이며 @Id라는 어노테이션으로 정의한 PK(식별자)를 통해 계속적으로 추적이 가능하다. 하지만, 값 타입은 식별자라는 개념이 존재하지 않아 추적이 어렵다. 값 타입은 흔히 우리가 사용하는 Integer, String과 같은 자바의 원시 타입과 같은 존재로 우리가 흔히 사용하는 객체와 달리 공유에 안전하고 사이드 이펙트가 발생하지 않..
Page, Slice에 대해 Page, Slice 오늘 다룰 포스트는 Page와 Slice이다. 우리는 흔히 어떤 웹을 돌아다녀도 페이징을 처리한 부분을 자주 찾아볼 수 있다. 우리가 개발을 하면서 구글링을 진행할 때 하단 부분을 바라보면 역시 페이징 처리되어 검색 페이지들이 나열되어 있는 모습을 확인할 수 있다. 이렇게 페이징을 처리하는 이유에 대해서 먼저 알아보자. 우리가 수 많은 데이터가 존재한다고 했을 때, 페이징을 처리하지 않고 모든 데이터들을 한 번에 뿌려준다면 어떻게 될까? 해당 데이터를 DB로부터 가져오는데 엄청난 시간이 소요될 것이다. 그 뿐 아니라, 해당 데이터 자체를 들고 있어야 하기에 엄청난 메모리의 소비가 존재할 것이다. 또한, 사용자들이 해당 게시물들을 모두 보게 하게끔 만들기에 용이하지 못하다. 그래서 우..
Cascade vs @Delete Cascade vs @OnDelete 이번 포스트는 이전에 다루었던 Cascade의 연장선이다. 이전에 언급했던 것처럼 생명주기를 공유하는, 어느 한 엔티티의 생명주기에 의존하는 엔티티들이 존재할 경우 Cascade를 사용하면 좋다고 언급했다. 그 이유는 프로젝트 - Cascade의 오해 (tistory.com)에 설명해놓았지만 간단히 다시 살펴보겠다. 어떠한 게시판이 존재한다고 가정하자. 우리가 흔히 잘 알고있듯이 게시판에는 여러개의 게시글, 그 안에 여러개의 댓글이 존재한다. (추천 또한 존재할 수 있다.) 만약, 게시판이 존재한다면 어떻게 될까? 일반적인 경우에는 게시판이 제거됨과 동시에 그 안에 존재하는 게시글, 댓글 (혹은 추천)이 모두 제거될 것이다. 왜냐하면 그들은 게시판의 생명주기에 의존하..
[Spring] JWT, OAuth2.0, Email - Redis로 구현 시작하기에 앞서 우리는 이전에 JWT와 이메일 인증을 구현하는데 있어 각각의 토큰들을 DB에 저장하였다. JWT는 Member 엔티티에 RefreshToken이라는 속성을 만들고, 이메일 인증은 EmailAuth라는 엔티티를 만들었다. 물론 이러한 구현이 틀렸다는 부분은 아니지만 이러한 인증 토큰과 관련된 부분은 Redis를 많이 사용한다. Redis란 무엇이고 왜 Redis를 사용하는지 간단하게 살펴보자. Redis는 Remote Dictionary Server의 약자로서 Key-Value 구조의 비정형 데이터를 저장하고 관리하기 위한 오픈 소스 기반의 비관계형 데이터베이스 관리 시스템이다. (NoSql이다.) In-Memory 기반의 데이터 처리 및 저장을 제공하여 속도가 빠르지만 서버가 꺼지면 모든..

티스토리툴바