생애 첫 Front와 협업 후 회고

Retrospection

• 어제 너무 진도가 안나가고 에러가 많이 터져서 TIL작성을 못함.

• 개발 공부 시작 후 생애 첫 프런트와 협업을 하고 있다.

• 몇시간 뒤면 최종 배포 및 발표를 앞두고 있다.

• 우리 백앤드 쪽은 배포할 웹에 필요한 기본적인 api는 모두 만들었고 좀 더 기능이 추가된 기능은 넣지 못했다.

• 프런트 분들도 화면을 좀 더 다듬고 계신다.

우리 팀의 첫 설계 및 개발 계획(총 7일)

1. 하루나 이틀안에 api명세서 설계 완료 및 와이어프레임 완성후 화면 개발
2. 화면 개발 후 실제로 서버를 배포하여 화면과 결합.(3일차)
3. 서비스 상태 확인 및 에러 발견시 수정 및 추가기능 논의(4일차)
4. 기본적인 CRUD 및 서비스 정상 작동 확인시 간단한 추가기능 api 개발 및 추가 와이어프레임 화면 개발 시작(5일차)
5. 간단한 추가기능 개발 완료 및 화면 개발 완료후 서버 배포후 재확인(6일차)
6. 발표 당일 최종점검및 웹 실행 영상 촬영및 발표 준비 및 발표

설계 후 실제 개발 시작 시

• .....

• 나의 모습
  

• 진짜 이렇게 뭐가 문제인지 생각하고 있었음.

• 실제 개발 시작시 발생한 일련의 사건은 다음과 같다.

1. 프런트 쪽에서 화면 개발을 예정된 시간 보다 1~2틀 정도 뒤에 완성함.
2. 백앤드는 백앤드대로 개발을 시작했고 변수명이나 api명세서를 프런트와 소통하지 않고 우리대로 만들어서 명세서를 작성함.
3. 백앤드에서 되는 response 값이 프런트에서 response가 되지 않음.
4. Cors 발생 X 10000000000000000000000
5. Acess-Token값이 아닌 Refresh-Token만 받아와짐.
6. Acess-Token값 사용시 Cors 발생
7. form-data 이미지 파일 업로드시 오류.

• 일단 내가 지금 돌아봤을 때 큰 문제점은 바로 2번이었다.

• 와이어프레임을 보지 않은 채 스프링은 스프링대로 변수를 정해서 api명세서를 작성했고 프론트분들은 프론트분들대로 와이어프레임을 보면서 작업을 했을것이다.

자세하게 설명하면

• 1. 회원가입페이지에서 responseError가 발생

  • 실제로 이메일 중복검사나 닉네임 중복 검사에서 백엔드는 http메서드가 GET으로 판단해서 명세서를 작성해서 api를 만들어서 배포 했고 프론트에서는 post로 사용해서 오류가 났었다.

    (그때도 이상하다고 생각했지만, 생각해보면 프론트에서는 email을 입력해서 서버에 준다고 Post를 사용했다고 했고 GET으로 했는데 오류가 났다고 했는데 내가 알고 있는거랑 달라서 프런트에서는 원래 post를 쓰는건가 하고 넘어감. 일단 협업이기 때문에넘아감. 참고로 GET으로도 data를 보낼 수있다.)

  • 백앤드와 프런트 둘다 다른 정규식을 사용해서 responseError가 발생했는데, 이건 꽤나 발견하기가 어려웠다. 왜냐하면 프런트에서 에러코드를 httpstatus 200으로 false값만 달라고 하셔서 false값만 response했는데 이것도 큰 문제점이었다. 실제로 우리는 fail값까지 사용해서 자세한 오류데이터를 전달하려고 했으나 실제로는 false라서 왜 이 오류가 발생하는 지 몰랐기 때문이다. 결국은 서로 다른 정규식으로 인한 회원가입의 오류였지만 말이다.

• 2. 로그인시 access-token이 아닌 Refresh-token만 발급해주는 오류
     
     
  • 처음 문제가 발생 했을때 우리 백엔드 쪽에서 제대로 발급해 줬는데 프런트애서 못찾는 것이라고 생각했다. 왜냐하면 post맨에서는 정상 출력되었기 때문이다.(포스트맨은 내가 내로컬로 접속하는 것이라 cors가 걸릴 염려가 없다. 그래서 백앤드에서는 정상적으로 출력이 된것 같았다.)
    
    
  • 위의 경우가 아니라면 이것은 백앤드의 실수였는데 알고 보니 나의 webConfig라는 클래스에서 WebMvcConfigurer를 Implement하는데 코드를 잘못 사용한 것이다.

@Override
    public void addCorsMappings(CorsRegistry corsRegistry) {

        corsRegistry.addMapping("/**")
                .allowedOrigins("*")
                .allowedMethods("*")
                .allowedHeaders("*")
                .exposedHeaders("*")
                .exposedHeaders("Authorization")
                .exposedHeaders("Refresh-Token") // 이렇게 2개 쓰면 안된다.
                .maxAge(3000);


    }

• 따라서 마지막에 있는 refresh-token만 발급해주고 있었다는 것이다.

@Override
    public void addCorsMappings(CorsRegistry corsRegistry) {

        corsRegistry.addMapping("/**")
                .allowedOrigins("*")
                .allowedMethods("*")
                .allowedHeaders("*")
                .exposedHeaders("*")
                .exposedHeaders("Authorization","Refresh-Token")
                .maxAge(3000);


    }

• 그리고 브라우저 정책상 access-token은 원래 디폴트로 숨겨져 있는데 우리가 exposedHeaders()를 적용함으로써 보여진다.

• 3. Cors문제
  • 이것도 진짜 공부많이해보고 구글링도 많이 해봤는데 결국 내가 위에 사용한 코드의 문제의 연장선 인것 같다. 즉 토큰값이 없는데 권한이 있는 페이지에 접근하니까 cors가 발생한거 아닌가라고 같이 공부하는 스프링분들이 말씀해주심. 그리고 프론트분들도 요청헤더에 토큰값을 넣지 않고 접근한 것도 문제였던 것 같다.
    
    
• 4. form-data 설정 문제
  • 이것은 프로젝트 발표 당일아침에 발생해서 일단 @RequestBody에 이미지 링크를 회원테이블에 저장하는 것으로 결론을 지었다.

• 결국 이번 협업을 통해서 화면의 내용과 그에 관련된 표현 및 변수 그리고 페이지 이동시 어떻게 이동하는지 흐름을 파악하면서 동시에 api명세서를 작성해야 했는데 이 기본적인 부분을 놓쳐서 많이 해메인것 같다.

• 커뮤니케이션이 굉장히 중요한 부분을 차지하는 것 같다.

• 다들 고생하셨습니다. 감사합니다.!

기술매니저님들, 담당매니저님 정말 감사합니다!!!

깃헙 주소 : https://github.com/pmjn1025/MyFristMiniProject

---