JPA 영속성 컨텍스트 - 엔티티를 영구 저장하는 환경 엔티티 매니저를 통해서 영속성 컨텍스트에 접근하고 관리할 수 있다. 영속성 컨텍스트의 특징 영속성 컨텍스트는 엔티티를 식별자 값으로 구분한다. 따라서 영속 상태는 식별자 값이 반드시 있어야 한다. JPA는 보통 트랜잭션을 커밋하는 순간 영속성 컨텍스트에 새로 저장된 엔티티를 데이터 베이스에 반영하는데 이를 flush라 한다. 영속성 컨텍스트의 장점 - 1차 캐시 영속성 컨텍스트 내부에는 캐시가 있는데 이를 1차 캐시라고 한다. 영속 상태의 엔티티를 이곳에 저장한다. 1차 캐시의 키는 식별자 값(데이터베이스의 기본 키)이고 값은 엔티티 인스턴스이다. // em.find(엔티티 클래스 타입, 식별자 값); Member member = em.find(Me..

DI(Dependency Injection) 객체를 클래스 내부에서 직접 생성하고 사용하는 것이 아니라, 다른 클래스에서 생성한 객체를 주입 받아 사용하는 것이다. 객체 간의 의존 관계를 느슨하게 만들어주는 디자인 패턴이다. Spring DI 방법 - 필드 주입 : 외부에서 객체 필드에 직접 접근할 수 있어 캡슐화가 깨질 위험이 있음 - 수정자 주입(Setter) : 객체의 값이 바뀔 수 있어 캡슐화가 깨질 수 있음 - 생성자 주입 : 불변, 단일 객체 생성 가능. 권장 되는 방법 DI 장점 - 결합도 감소 : 객체간 결합도를 낮춘다. - 테스트 용이성 : Mock 객체 주입을 통해 테스트를 쉽게할 수 있다. 테스트 결과의 일관성과 신뢰성을 높일 수 있다. - 코드가독성 : 의존성이 명시적으로 선언되므로..

어제 이야기를 나눴던 부분인데 나는 아래의 블로그를 참고해 소셜 로그인을 구현하고 로컬에서 email이 저장되는 것을 확인했다. 그런데 프론트엔드에서는 back end와 직접적 통신을 안하는데 어떻게 정보를 가져가냐고 해당 로직이 잘못됐다고 한다. 이 블로그에서 소셜 로그인 버튼이 back end와 연결해주는 부분이라고 생각했는데 해당 내용을 읽었는데 뭐가 잘 못 돼서 그렇게 말하는건지 이 블로그를 제대로 안 읽었는지 모르겠다. 프론트 설명은 한 페이지 반이 되는 내용이다 https://deeplify.dev/back-end/spring/oauth2-social-login#%EC%86%8C%EC%85%9C-%EB%A1%9C%EA%B7%B8%EC%9D%B8-%EB%B2%84%ED%8A%BC [Spring ..

발표 전날 마지막으로 API연결이 부족한 부분을 맞춰나갔다. 내가 맡은 소셜로그인은 이미 구현이 끝났는데 연결이 안 돼서 프론트엔드에서 작업을 해주길 기다리고 있었는데, 해당 내용이 늦게 시작돼서 맞춰보는데 한참 늦었다. 그런데 해당 내용을 API로 데이터를 보내준다고 했는데 나는 아래와 같이 구글 로그인을 성공하면 즉시 google에서 제공한 user 정보를 가져가서 올바르게 회원가입 후 토큰을 생성하고 토큰을 프론트에 넘기는 로직을 실행했다. .oauth2Login() .defaultSuccessUrl("/api/auth/login/google", true) .authorizationEndpoint() .baseUri("/oauth2/authorization/*") .authorizationReque..

프로젝트 발표를 위해 기존의 프로젝트를 정리한다고 이틀을 제대로 못 자면서 내용을 정리했다. TIL도 하루 못 적었다ㅠ TIL을 처음에는 개념도 정리하고 엄청 자세하게 적으려고 했었는데 하루하루 기록하는 것도 좋다고 해서 이런 형식으로 적어나갔다. 처음에는 이렇게 해도 도움이 될까 싶었는데 이번에 프로젝트를 정리하면서 쭉 훑어보니 많은 도움이 됐고 내가 뭘 배웠고 어떤 트러블 슈팅이 있었는지도 다시 잘 기억했다. 이래서 TIL이 중요하구나 하고 느꼈다. 조금 더 자세하게 적는 것도 좋아보이지만 지금처럼 적어도 잘 기억이 돼서 기분이 좋다. 항해가 끝난 후 부족한 CS 지식을 더 공부해야하니 이후에는 조금 더 개념적인 부분을 정리해봐야겠다.

현재 프로젝트에는 jwt와 redis를 활용한 로그아웃을 구현했었다. 구현 방식은 redis에 저장해 둔 access token과 refresh token을 삭제해서 로그아웃 하는 방식을 적용시켰다. 로그아웃에서 클라이언트의 header에 authorzation의 access token값을 삭제하는 내용은 프론트에서 적용해야 하는 부분으로 인지하고 해당 부분을 추가로 건드리지 않았다. 그런데 프론트에서는 왜 해당 로직을 제대로 처리하지 않았냐는 물음에 의문이 들었지만 현재 만료시간 전에 access token을 자동으로 발급해주는 로직이 있었고, 프론트에서는 response Header의 authorization에 token값이 들어오면 해당 값을 최신화 시켜주는 로직이 있어서 로그아웃 시 "" 값을 s..