코드그라데이션

요청 매핑 핸들러 구조 - HTTP 메시지 컨버터는 스프링 MVC 어디쯤에서 사용되는 것일까? 이 구조에서는 없다. SpringMVC 구조 모든 비밀은 애노테이션 기반의 컨트롤러, 그러니까 @RequestMapping 을 처리하는 핸들러 어댑터인 RequestMappingHandlerAdapter (요청 매핑 헨들러 어뎁터)에 있다. RequestMappingHandlerAdapter 동작 방식 ArgumentResolver 생각해보면, 애노테이션 기반의 컨트롤러는 매우 다양한 파라미터를 사용할 수 있었다. HttpServletRequest, Model 은 물론이고, @RequestParam, @ModelAttribute 같은 애노테이션 그리고 @RequestBody, HttpEntity 같은 HTTP ..

HTTP 메시지 컨버터 HTTP 메시지 컨버터뷰 템플릿으로 HTML을 생성해서 응답하는 것이 아니라, HTTP API처럼 JSON 데이터를 HTTP 메시지 바디에서 직접 읽거나 쓰는 경우 HTTP 메시지 컨버터를 사용하면 편리하다. @ResponseBody 사용 원리 [그림] 다시 돌아가서 HTTP 메시지 컨버터 인터페이스 /** * HTTP 요청 및 응답 메시지를 변환하는 데 사용되는 인터페이스입니다. * 이 인터페이스를 구현하는 클래스는 HTTP 요청 메시지를 Java 객체로 변환하거나, * Java 객체를 HTTP 응답 메시지로 변환하는 작업을 수행할 수 있습니다. * * @param 변환할 객체의 타입을 나타내는 제네릭 타입 매개변수 */ public interface HttpMessageConv..

JWT는 Header, Payload, Signature 이렇게 3개 부분으로 구성되어 있다. Header는 Signature을 해싱하기 위한 알고리즘 정보들이 담겨있고, Payload는 서버와 클라이언트가 주고받는, 시스템에서 실제로 사용될 정보에 대한 내용들을 담고 있다. Signature은 토큰의 유효성 검증을 위한 문자열이다. - 이 문자열을 통해 서버에서는 이 토큰이 유효한 토큰인지를 검증할 수 있다. JWT 장점 - 중앙의 인증서버, 데이터 스토어에 대한 의존성 없음, 시스템 수평 확장 유리 - Base64 URL Safe Encoding => URL, Cookie, Header 모두 사용 가능(범용성) JWT 단점 - Payload의 정보가 많아지면 네트워크 사용량 증가, 데이터 설계 고려가..

AWS IAM에 들어가 사용자 만들기 생성된 boot3을 클릭하여 [액세스 키 생성] 버튼 클릭 후 작업 시작 이제 값을 등록하기 위해 github 에 접속 후 Settings -> Secrets and Variables -> Actions 순서로 클릭 이러면 기본 세팅은 끝 이제 파일을 작성하면 가장 바깥 폴더에 .github 디렉토리 생성하고 workflow 디렉토리 하위에 생성 후 안에 cicd.yml 만들기 cicd.yml name: CI/CD # 이 워크플로의 이름 on: push: branches: [main] # main 브랜치로 푸시되었을 때만 실행 jobs: build: runs-on: ubuntu-latest # Ubuntu 환경에서 실행 steps: - uses: actions/che..

# CI / CD는 도구가 아니라 방법이다. * CI / CD가 필요한 상황 만약 서비스를 배포하고 운용하던 중에 코드를 변경할 일이 생기면 어떤 작업을 할 것인가? 우선은 코드 수정을 하고, 로컬 환경에서 테스트를 진행한다. 그리고 빌드도 잘되는지 확인할 것이다. 그런 다음에는 jar 파일을 생성해 복사하고， AWS에 접속해서 복사한 jar 파일을 업로드해 새 배포 버전을 제공해야 한다. 지금 이 과정을 기계적으로 계속하는건 현실적으로 어렵다. 프로젝트 규모가 커진다면 더 말할 필요도 없고. => 이럴 때 도입하는 것이 CI/CD 이 방법을 도입하면 빌드부터 배포까지의 과정을 자동화할 수 있고, 또 잘 되는지 모니터링 할 수 있다. 사실 이는 지속적 통합, CD는 지속적 제공이라는 의미가 있다. CI ..

IntelliJ 우측 상단의 그래들 버튼 누르고 빌드 하면 build/libs 에 jar 파일이 생성된다. 이후 Beanstock 화면으로 돌아와서 클릭 배포 버튼 클릭해서 설정을 완료하고 이 URL을 복사하여 구글 클라우드 콘솔로 이동하여 다만 형식을 "주소/login/oauth2/code/google" 뒤에 붙여줘야 한다. 이러고 수정한 후 시도하면 구글 로그인이 완료됨.

Elastic Beanstock로 서비스 생성하기 - 이 과정은 https://www.youtube.com/watch?v=UgKFaUHaIsg 참고하여 진행 (책에는 많은 부분이 생략되어 있음.) Elastic Beanstock 에서 RDS 생성하기 - 현재 나는 배포를 완료했으므로 생성이 된 상태이긴 함. 접속하고 나면 다음 단계로, 환경변수를 추가해주어야 한다. 추가할 내용 이름 값 JWT_SECRET_KEY 설정한 값 SERVER_PORT 5000 SPRING_SECURITY_OAUTH2_CLIENT_REGISTRATION_GOOGLE_CLIENT_ID 구글에서 발급 받은 값 SPRING_SECURITY_OAUTH2_CLIENT_REGISTRATION_GOOGLE_CLIENT_SCOPE email...

AWS란 - 지금까지는 로컬에서 실행. 이렇게 로컬에서만 실행하고 테스트하면 휴대폰이나, 다른 PC에서 접속할 수 없다. - 만약 다른 PC에서도 이 서비스에 접속하려면 실제 서버에 스프링 부트 서버를 올려 실행해야 한다. - 이런 행위를 실무에서는 배포라고 한다. 배포는 서버용 PC를 구매해서 배포하는 방법과 AWS와 같은 클라우드 컴퓨팅 서비스를 이용해 배포하는 방법이 있다. AWS 서비스로 나의 애플리케이션 배포하기 [그림] AWS 서비스의 대략적인 구조 # 가상의 PC 또는 서버 EC2 - EC2는 AWS에서 제공하는 클라우드 컴퓨팅 서비스로 가상의 PC, 즉, 서버 한 대를 임대하는 서비스. # 유동적으로 EC2를 관리해주는 오토 스케일링 그룹 - 그런데 앞 그림을 보면 EC2는 3개이다. 왜?..