[TIL] 6주차 미니 프로젝트ㅣReact + Spring boot 연동

 

미니 프로젝트 [감자마켓] 진행상황

React + Spring boot 연동

어제에 이어 프론트 분들이 만들어주신 화면에 API를 붙여 하나씩 테스트를 진행했다.
정말 말도 안 되게 많은 에러를 만났다.
너무 많이 만나서 무슨 에러를 만났는지 기억도 안 날 정도로..

CORS 에러 해결

대표적인 CORS 에러는 센스 있는 조원분이 미리 WebSecurityConfig에 추가해놓은 코드로 비교적 쉽게 해결할 수 있었다.

@Bean
public CorsConfigurationSource corsConfigurationSource(){

    CorsConfiguration config = new CorsConfiguration();
    config.addAllowedOrigin("http://localhost:3000"); // 프론트엔드 로컬서버로 테스트
    config.addExposedHeader(JwtUtil.AUTHORIZATION_HEADER);
    config.addAllowedMethod("*");
    config.addAllowedHeader("*");
    config.setAllowCredentials(true);
    config.validateAllowCredentials();
    UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource();
    source.registerCorsConfiguration("/**", config);

    return source;
}

 

 

 

오늘의 궁금증

 

도대체 에러를 어떻게 해줘야 되는 거야?

가장 큰 혼란이 왔던 부분이다.
예를 들어 아이디 중복 확인을 한다고 가정해 보자.
중복된 아이디라면 서버는 409 에러를 내보낼 것이다.
그럼 클라이언트에서는 당연히 에러가 나버린다?

아무래도 모두가 처음이다 보니 여기서 참 많이 헤맸다.
우리 스터디 팀원분들의 지인찬스를 이용해서
이런 에러를 어떻게 처리하시는지 현업에 계신 분들께 직접 여쭤보았다.
(규리님 승호님 상훈님 감사합니다😊)

의견은 2가지로 나뉘었다.

"에러코드를 보고 클라이언트가 판단해야 하기 때문에 서버는 409를 내려주는 게 맞다.
프론트가 에러핸들링을 하는 게 중요."

"rest 한 api를 짜는 거라면 프론트에서 4xx 오류를 처리하는 게 맞는 방법이지만
409라는 거 딱 하나만 보내면 이게 중복인지, 다른 이슈인지 모르기 때문에
200을 보내고 그 안에 code라는 부분을 정의해서 추가적으로 보낸다."

결론적으로 정답은 없고,
HTTP Status를 따르냐 vs 각 회사의 에러 명세가 기준되어있고 그 기준대로 따르냐
그 정도의 차이인 것 같다.

우리는 빠른 진행을 위해 먼저 200을 보내고,
따로 statusCode를 정의해서 보내기로 결정하였다.

 

📚 참고자료

[Network] HTTP 상태(응답) 코드 정리하기

 

 

ResponseEntity.ok()와 ResponseEntity.ok().body()의 차이점은 뭘까?

정답은.. 차이 없음!

public static <T> ResponseEntity<T> ok(@Nullable T body) {
   return ok().body(body);
}

ResponseEntity.ok(body) 이렇게 보내도
결국 ResponseEntity.ok().body(body) 이렇게 리턴되기 때문에 별 차이가 없다.

 

 

 

오늘의 나는

이전에 프로젝트를 리딩한 경험이 있고,
따라서 협업에 전혀 어려움이 없다고 생각했는데
이 협업이란 녀석은 그렇게 호락호락하지 않았다.

내가 조원분들과 더 적극적으로 소통했어야 했는데 그러지 못했다.
좋은 게 좋은 거지 하고 넘겼던 일들이 누군가에게 큰 상처가 될 수 있다는 걸 깨달았다.
앞으로는 소통을 위해 최선을 다 할 것이다.