\--> spring.jpa.show-sql=truespring.jpa.properties.hibernate.format_sql=true 시 조회 가능쿼리가 excute될 때, 요청한 페이지만큼 조회하는 것이 아닌 전체조회가 발생됨.전체조회 결과를 in-memory에

X-Forwarded-For : 클라이언트의 원 IP 주소를 보기위해 X-Forwarded-For 요청 헤더가 사용다음과 같이 콤마를 구분자로 client 와 proxy IP 가 들어가게 되므로 첫번째 IP 를 가져오면 클라이언트를 식별할 수 있다.순차대로 들어오게 되

팀 프로젝트를 하던 중 프론트 단에서 무한 스크롤을 적용한 조회 api를 구현해야 했다. 스프링 데이터 jpa의 Page 기능을 통해 구현할 수도 있지만, no offset 기능을 적용하기 위해 Querydsl을 사용하였다. no offset을 적용하지 않을 경우, 데

팀 프로젝트를 진행하면서, JWT 기반 로그인 기능을 구현한 후에, 로그아웃 기능 또한 구현해야 했다. 여러 로그아웃 구현 방법들을 찾아보다가, 세션 로그인의 경우에는 세션에서 해당 유저 데이터를 삭제하면 되지만, 토큰의 경우에는 이미 발급된 토큰을 무효화 시키거나 조

이번에 진행하는 팀프로젝트에서 소셜 로그인 기능을 구현해야 했다. 로그인 방식은 JWT 기반 로그인 방식으로, 프론트 측에서 인가코드를 가지고 백엔드 서버로 요청을 보내는 방식으로 구현하였다.그림 출처: https://velog.io/@padd60/%EB%84

Json 포맷을 이용하여 사용자에 대한 속성을 저장하는 Claim 기반의 Web Token토큰을 통해 사용자 인증 처리Header, Payload, Signature의 3 부분으로 구성서버 측에서 사용자들의 정보를 기억사용자들의 정보를 기억하기 위해서는 세션을 유지해야

게시판 사이트 구현 중 게시판 내의 글을 검색하는 기능을 추가해야 했다.쿼리문 생성을 위해 querydsl을 사용하였으며, 검색은 제목, 내용, 제목+내용으로 검색이 가능하게끔 구현하였다.PostGetDto.java게시글 데이터를 조회하기 위한 DTO이다.QueryPr

스프링에서 제공하는 AnnotationAwareAspectJAutoProxyCreator는 Advisor를 자동으로 찾아와서 필요한 곳에 프록시를 생성하고 적용또한 @Aspect 를 찾아서 이것을 Advisor 로 변환해서 저장어드바이저를 기반으로 프록시를 생성포인트컷

Request Response 구조클라이언트는 서버에 요청을 보내고, 응답을 대기서버가 요청에 대한 결과를 만들어서 응답전체 흐름① 사용자가 웹 브라우저의 검색창에 특정 사이트의 주소를 입력한다.② 웹 브라우저가 DNS에게 특정 사이트의 (도메인)주소를 요청한다.③ D

유튜브 댓글 분석 서비스 프로젝트를 진행하던 중, 싱글톤 방식의 설계가 잘못되어 분석을 계속해서 실행할 때마다 이전 분석 값이 누적되어 출력되는 현상이 발생하였다.Flask 서버에서 분석된 결과를 JSON 형태로 받아와 통계를 추출하여 Front 서버에 전달하는 형식인

싱글톤으로 등록된 스프링 빈은 객체의 인스턴스가 애플리케이션에 딱 1개만 존재이렇게 하나만 있는 인스턴스의 필드를 여러 쓰레드가 동시에 접근할 경우 문제가 발생FieldService.javaFieldServiceTest.java먼저 thread-A 가 userA 값을

데이터베이스 커넥션을 미리 생성해두고 사용하는 방법데이터베이스 커넥션을 획득할 때는 다음과 같은 복잡한 과정을 거침커넥션을 새로 만드는 것은 과정도 복잡하고 시간도 많이 많이 소모DB는 물론이고 애플리케이션 서버에서도 TCP/IP 커넥션을 새로 생성하기 위한 리소스를

개발자가 컨트롤이 불가능한 외부 라이브러리들을 Bean으로 등록하고싶은 경우에 사용된다ex) Spring Security에서 제공하는 PasswordEncoder는 Spring Security 개발자에 의해 만들어진 클래스(라이브러리)개발자가 직접 컨트롤할 수 있는 클

N + 1문제란 1번의 쿼리를 날렸을 때 의도하지 않은 N번의 쿼리가 추가적으로 실행되는 것을 의미JPA Repository를 활용해 인터페이스 메소드를 호출할 때(Read 시)1:N 또는 N:1 관계를 가진 엔티티를 조회할 때 발생JPA Fetch 전략이 EAGER

SQL에 의존적인 개발을 피하기 어렵다.패러다임의 불일치 => 객체 vs 관계형 데이터베이스계층형 아키텍처 진정한 의미의 계층 분할이 어렵다.객체답게 모델링 할수록 매핑 작업만 늘어남 -> 객체를 자바 컬렉션에 저장 하듯이 DB에 저장할 수는 없을까? -> JPA가 탄

HTTP 프로토콜로 들어오는 모든 요청을 가장 먼저 받아 적합한 컨트롤러에 위임해주는 프론트 컨트롤러(Front Controller)Front Controller는 주로 서블릿 컨테이너의 제일 앞에서 서버로 들어오는 클라이언트의 모든 요청을 받아서 처리해주는 컨트롤러로

• HTML, TEXT• IMAGE, 음성, 영상, 파일• JSON, XML (API)• 거의 모든 형태의 데이터 전송 가능• 서버간에 데이터를 주고 받을 때도 대부분 HTTP 사용• 클라이언트 서버 구조• 무상태 프로토콜(스테이스리스), 비연결성• HTTP 메시지•

• 서버가 클라이언트의 상태를 보존X• 장점: 서버 확장성 높음(스케일 아웃)• 단점: 클라이언트가 추가 데이터 전송• 고객: 이 노트북 얼마인가요?• 점원: 100만원 입니다.• 고객: 2개 구매하겠습니다.• 점원: 200만원 입니다. 신용카드, 현금중에 어떤 걸로

Spring 프레임워크는 3가지 핵심 프로그래밍 모델을 지원하고 있는데, 그 중 하나가 의존성 주입(Dependency Injection, DI) 이다. DI란 외부에서 두 객체 간의 관계를 결정해주는 디자인 패턴으로, 인터페이스를 사이에 둬서 클래스 레벨에서는 의존관

• 지정한 IP 주소(IP Address)에 데이터 전달• 패킷(Packet)이라는 통신 단위로 데이터 전달비연결성• 패킷을 받을 대상이 없거나 서비스 불능 상태여도 패킷 전송비신뢰성• 중간에 패킷이 사라지면?• 패킷이 순서대로 안오면?프로그램 구분• 같은 IP를 사용