공부기록/기술공유
스프링 부트 한무 403 Error
배경백엔드 프론트엔드 각자 열심히 개발을 진행하면서 드디어 프론트쪽 UI작업이 어느정도 끝나고 API 연동 시점에서 계속해서 403 에러가 터지기 시작했다.. 분명 로컬에서 잘 작동을 했고 이미 모든 권한에 관련된 것들은 처리를 해둔 상태인데 도데체 왜???문제에러가 발생한 이유는 되게 간단했다develop 환경에서 JPA.ddl-auto 설정 값을 none으로 설정을 해뒀더니 개발을 진행하면서 변경된 엔티티 반영이 되지 않아서 SQLSyntaxErrorException 이 발생하게 되었다그럼 여기서 이해가 되지 않는 점은 예외가 발생하면 아래와 같이 500에러가 터지기를 기대했는데 왠걸? 403????!?무한 403에러가 나는 것은 바로 시큐리티에서 찾을 수 있었다AuthorizationFilterSe..
RequestBody Runtime시 동적 주입
배경여러개로 나뉘어있던 이력서 내부 값들을 저장하는 테이블들을 하나로 합치면서 Service, Repository가 하나로 합쳐지게 되었다테이블 구조 변경 관련 이로인해 API들도 Request를 제외한 모든게 동일하게 되었다(기존에는 구조는 같았지만 접근해야 할 Service, Repository도 모두 달랐다)변경 후 Controller@PostMapping("/{resumeId}/activities")public IdResponse createActivity( @PathVariable Long resumeId, @RequestBody ActivityRequestDto request) { return new IdResponse(componentService.create..
??? : 어딜 보시는 거죠 그건 제 잔상입니다만?!?
배경진행 중인 프로젝트에서 API 문서화를 위해 Spring Rest Docs를 사용하고 있다API 문서를 만드는 과정에서 생긴 html 파일을 함께 서버에 배포를 해서 사용을 하고 있고 https://{백엔드 도메인 주소}/docs/index.html 로 접속을 하면 문서가 나오도록 설정을 해두었고 이를 위해 build.gradle에 copyDocument 라는 Task를 만들어 두었다tasks.register('copyDocument', Copy) { dependsOn asciidoctor doFirst { delete file('src/main/resources/static/docs') } from file("build/docs/asciidoc") into f..
Redis 사용기
배경회원가입 시 카카오 인증만 진행하고 필수 정보를 작성하지 않은 사용자는 사용자가 맞을까?? 일단 내 기준에서는 아니다필수로 받아야 한다고 정책으로 정해진 것이고 해당 값들이 있어야 저장을 시켜준다라고 정해진 이상 해당 값들이 없다면 그건 사용자가 아닌 것이고 저장을 해주면 안된다 라는 정책과 그럼 카카오로 부터 받은 값들을 필수 값이 들어오기 전까지 어디에 안전히 가지고 있을 지 문제에서 시작되었다대안1. 서버 내부 메모리에 저장가장 간단한 방법이다 추가로 외부 리소스를 사용할 필요도 없고 내부에서 Map 형태로 우리가 만든 key 값, 사용자 정보 value로 저장을 한 후 해당 key 값을 제공하여 필수 정보 값과 같이 요청에 담아 보내도록 하면 된다하지만 단점으로는 서버가 증가한다면?!?!? (..
이력서 저장 테이블 구조 재구성
배경일단 동작되게 만들어!!!이게 문제였는지 현재는 너무 화면에 치중된 ERD가 나오고 화면이 바뀌면 Controller, Service, Repository, 심지어 Database까지 모두 변경이 이루어지게 된다 (천지개벽!)또 화면에 ERD를 맞추다 보니 API를 찍어내는 것 이외의 작업이 없다 또한 추후 커스텀한 템플릿을 만들어 제공을 해주기 위한 Should 기능이 있는데 이러한 정적으로 구조화된 DB를 가지고서는 유연하게 많은 구조를 저장을 하기 불가능 하다고 생각이 되어 이를 하나의 테이블로 변경을 해보고자 한다현재 화면 상태 및 ERD 구상중인 새로운 Entity이를 해결할 방법으로는 다단계 Table!!하나가 여러개를 계속해서 증식할 수 있고 최고 등급 컬럼이 모든것을 먹을 수 있도록구상..
Git Branch Linear
Git Branch Linear배경기존에는 아무 생각 없이 Branch만들고 Merge를 진행하면서 Branch 관리에 대해서 별 다른 생각과 노력을 하지 않은 채로 개발을 진행해 왔지만 이번에는 Branch를 linear하게 관리를 하고자 한다 처음에는 그냥 rebase하고 squash하면 되는거 아니야? 가장 최신 시점에서만 merge하면 되겠네! 라고 생각을 했지만 시점을 잘못 파악해 몇 번의 문제점이 생기고 Linear하지 못하게 관리가 되게 되어 PR을 다시 올리고 Branch를 다시 만드는 과정을 몇번이나 진행하게 되었다 그리고 또 하나의 고민되었던 부분은 Github PR에서 Rebase And Merge, Squash And Merge 를 하게 되면 Fast Forward 와 같이 계속해서..
Git Submodule 적용기
배경2차 팀 프로젝트를 하면서 외부에 노출되면 안되는 값(DB 주소, 비밀번호, JWT 생성 키 등)들을 관리하기 위해서 Github Environment secrets, Dock .env 파일, Git Submodule 중에서 선택을 하게 되었다선택을 하게 된 이유로는 아무래도 추가적인 Github Repository에서 관리할 수 있고 Versioning도 되고 여러 파일로 나눠 특징 별로 application-jwt.yml application-db.yml와 같이 파일을 나눠 관리 및 추가와 수정 삭제등이 용이하다는 장점들 때문이다 Submodule 이란쉽게 말하자면 Git 저장소 안에 Git 저장소를 만들어 넣는 것이다 당연히 .git 폴더가 각각 생기고 개별적으로 Version, Commit 관..