Q1. 처음 설계한 API와 ERD에 변경사항이 있었나요? 변경되었다면 어떤 점 때문일까요? 첫 설계의 중요성에 대해 생각해보세요.
빠뜨린 요구 사항에 대한 요소가 추가되었고, 유저와 글에 관한 연관 관계가 추가되었으며, 출력할 형태를 데이터 만으로 하다가 요청 Status와 메시지에 대한 처리를 추가하면서 많은 부분이 바뀌었다.
설계에 대한 큰 깨달음을 얻은 것이 ResponseEntity를 사용해보면서와 예외처리에 대한 부분을 추가하면서 였는데 이부분에 대한 설계를 진행하지 않고, 다 구현한 후 추가하려니 대대적으로 바꿔야 하는 부분이 많았다. 이미 ResponseEntity아니나 역할을 하는 비슷한 Dto를 만들어버려서 이를 다시 대체 하는데에 혼란을 겪어야 했다.
처음 설계할 때 충분히 생각하고 설계했다면 후에 대대적으로 수정하는 일을 줄였을 걸로 생각된다.
완성된 API문서 : https://documenter.getpostman.com/view/24654654/2s8YzMX4uu
Memo API
The Postman Documenter generates and maintains beautiful, live documentation for your collections. Never worry about maintaining API documentation again.
documenter.getpostman.com
완성된 ERD : https://www.erdcloud.com/d/gnWBcoa9Hu339urMd
스프링 숙련 주차 ERD
Draw ERD with your team members. All states are shared in real time. And it's FREE. Database modeling tool.
www.erdcloud.com
Q2. ERD를 먼저 설계한 후 Entity를 개발했을 때 어떤 점이 도움이 되셨나요?
참조에 대한 구상을 먼저 ERD를 통해 서로의 관계를 이미 명확하게 하고 설계했기 때문에 Entity로 구현하는 것이 훨씬 쉬워진다.
참조키는 어떤 것으로 할 것인지, 일대일, 일대다, 다대일의 관계 역시 ERD의 그림을 통해 관계로 정리해 머리나 글로 이해하는 것보다 명확하게 다가 오기 때문에 구현에 큰 도움이 된다.
Q3. JWT를 사용하여 인증/인가를 구현 했을 때의 장점은 무엇일까요?
- 쿠키-세션 방식과 달리 JWT는 서버 쪽에 따로 저장하지 않기 때문에 저장소가 필요없다. 따라서 서버의 부담을 줄일 수 있다.
- 저장소를 오갈 일이 없기에 불필요한 인증 과정 감소해 트래픽의 위험을 줄일 수 있다.
- 세션 방식 경우 자원이 공유되지 않아 같은 서비스여도 서버가 달라지면 새롭게 인증을 해야했는데 Secret Key만 공유된다면 각 서버에서 토큰 검증이 가능하고 사용이 가능하기 때문에 별도의 인증을 새롭게 할 불편함이 사라져 서버를 유지 보수, 확장하기 편해진다.
Q4. 반대로 JWT를 사용한 인증/인가의 한계점은 무엇일까요?
- JWT는 토큰이 만료될 때까지는 중간에 만료시키는 것이 불가능하다. 또한 Client에 토큰을 저장하고 있기 때문에 Client와 Server간에 토큰이 오갈때 Hijacking 하여 토큰을 탈취하게 되면 만료될 때 까지 해커에 의한 공격을 당할 수도 있다.
- Token에 정보를 많이 담게되면 그만큼 길어지게 되고 길어긴 Token이 오가면 서버에 부담이 될 수 잇다.
- Secret Key만 있으면 모두 해독이 가능하기 때문에 보관에 신경써야한다
- payload 자체는 암호화 된것이 아니라 BASE64로 인코딩 되어 있는 것이다. payload에는 민감한 내용을 담을 수 없거나 암호화를 별도로 해야하는 등 담을 수 있는 내용에 한계가 있다.
Q5. 만약 댓글 기능이 있는 블로그에서 댓글이 달려있는 게시글을 삭제하려고 한다면 무슨 문제가 발생할까요? Database 테이블 관점에서 해결방법이 무엇일까요?
연관되어 있는 댓글들 때문에 삭제가 되지 않는 문제가 생긴다. 댓글과 연결이 되어있는데 글만 삭제가 되어버린다면 댓글들은 연관 관계에서 공중에 뜨게 되고 이는 참조 무결성에 위배가 되게 된다. 참조 무결성이란 데이터베이스 상의 참조가 "모두" 유효함을 말한다.
따라서 무결성을 지키기 위해 CASCADE라는 옵션을 사용하게 되는데, 이는 참조 관계에 있어 신뢰성 있는 상태로 유지하기 위한 것이다. CASCADE옵션을 사용하면 값을 수정 또는 삭제 시 이 값을 참조하고 있는 레코드 역시 종속적으로 수정/삭제할 수 있다.
그런데 만약 값이 하나 삭제될 때 참조하는 값은 지우지 않다면? ON DELETE SET NULL 라는 옵션이 외래키를 NULL로 바꾸어 유지할 수 있게 한다.
Q6. IoC / DI 에 대해 간략하게 설명해 주세요!
* IoC / Invention Of Control / 제어의 역전
스프링의 가장 큰 특징 중 하나로 간단히 말해서 객체의 생성 및 제어권을 사용자가 아닌 스프링에게 맡기는 것이다. 객체에 IoC가 적용된 경우에는 이러한 객체의 생성과 사용자의 제어권을 스프링에게 넘기게 되며 스프링의 DI(Dependency Injection) Container에 의하여 관리당하는 자바 객체를 사용자는 사용하게 된다.
* DI / Dependency Injection / 의존성 주입
외부에서 두 객체 간의 의존 관계를 결정하고 주입해 주는 것으로, 스프링은 두 객체 사이에 인터페이스를 두어 클래스 레벨에서는 의존 관계가 고정되지 않도록 하고 런타임 시에 관계를 동적으로 주입하여 유연성을 확보하고 결합도를 낮출 수 있게 해준다.
'Experience > 항해99' 카테고리의 다른 글
본수업 23일차 / 스프링 심화 주차 : S.A. (2) | 2022.12.09 |
---|---|
본수업 22일차 / 스프링 숙련 주차 시험 (0) | 2022.12.08 |
022 - 본수업 3주차 / 스프링 입문 주차 : 개인 과제 구현편 정리 (2) | 2022.12.01 |
021 - 본수업 15일차 / 스프링 입문 주차 : 개인 과제 질문편 (2) | 2022.11.30 |
018 - 본수업 12일차 / Spring JPA (Java Persistence API) (1) | 2022.11.26 |