3주차 프로젝트 체크 미팅

 

프론트에서 Json server 쓰는 것의 장점

 

프론트가 안되도 백엔드가 계속 다음 task 진행할 수 있도록 쓰는 것.

 

Hikari Pool을 줄여야 하는 이유 .

Application properties 에서 hikari.maximumpool-size 설정 부분이 있음. 

-> 현 프로젝트 springboot기반이고, mvc 구조를 따른다. 즉 서블릿 요청 하나 올 때마다 요청 하나에 thread를 추가한다. 스레드의 수만큼 db에 접속(커넥션 풀 - 히카리)할 수 있게 된다.  

Heroku-Postgres는 20개까지만 제공하는데 기본적으로 spring connection-size가 10개이기 때문에, 

개발할 떄는 4-6개 정도로 낮춰주면 좋다 (backend engineer 2명이 쓴다고 생각할 떄 12개-18개가 총 사용되게) 

여기서 Connection 은 일종의 Funnel (통로?길의 갯수? 같은 개념으로 이해하면 좋겠다) 

 

인증 - JWT Token 

현재 프로젝트는 로컬에서는 mock로그인을 구현하고 (jwt 토큰을 쓰는 절차 없이도 통과할 수 있게) 

실제 배포 서버에서는 jwt 토큰을 쓰는 구조를 구현할 것이다. 

mock 로그인을 쓰는 이유는, 그렇게 안하면 화면에서 보내주는 authentication을 써야하는데 보통 프론트의 개발속도가 더 느리기 때문에 프론트에 의존하지 않도록 우선은 테스트 데이터로 채우는 것이다. 

 

테스트

지난 번에는 Postman을 썼으니 이번에는 .http를 활용해도 좋겠다. 

 

@Profile Annotation 

실행환경을 구분해줄 때 쓴다. main, local 등 여러 세팅을 설정해놓고 필요에 따라 주입한다. 

ex.Procfile에서 Dspring.profiles.active=main 하면 main으로 바뀜.

 

#기타

 

왜 setAuth를 했지?

OncePerRequestFilter : 스프링에서 모든 http요청이 오기 전에 거치는 개념..

@Component.@bEAN으로 FILTER가 등록되면, 모든 요청 앞에 FILTER 가 등록됨.

우리는 그렇게 하면 안됨. SECURITY CONFIG에 FILTER를 요청할 것도/무시할 것도 있음.

FILTER cONTAINE클래스로 한번 감싸준 것..

 

Signature: 구글이 찍어주는 인장.

 

getContext()..setAuthentication(authentication) 여기서 user를 넣어주는 것.

로그인한 유저 객체를 가져올 수 있음. (controller안에서 http바디를(authentication)  받ㄴ 것..)

@requestheader 를 받을 수도 있고.. Http 구조 이해하는 것이 중요함