루프크리에이티브 Version2 제작(Spring Data JPA, React.js 후기)

Version 1.

SpringMVC

Build: Maven

Java: 1.8

JSP

Mybatis

🔽 Upgrade

Version 2.

SpringBoot: 3.1.3

Build: Gradle

Java: 17

React:18.2

Spring data JPA

목표

약 1년 전 즈음 만든 프로젝트의 업데이트 제안을 받았다.

→ SpringMvc 복습, Spring JPA, data JPA, React.js의 목적으로 프로젝트 진행

→ 예외처리 등 운영 때에 불편했던 점 개선

→ 분편했던 Work UI 개선

---

BACK 단(소스확인)

예외처리 공통 기능

batch size처리, 쿼리 요청 횟수 줄임으로 속도개선

1. 예외처리

예외처리는 크게 바뀐 부분으로 고민이 많이 되었다. 실무에서는 어떻게 사용될까를 고민하며 진행했다. 공통으로 잡고 오류에 대한 처리를 직접 보내는 것이 front에서도 데이터를 받을 때 공통으로 만들어 사용하기 좋다고 생각했다.

 

GlobalExceptionHandler

1. 예외가 터지면 모두 GlobalExceptionHandler을 통하게 만들었다.

RestApiException

@RestControllerAdvice

RestControllerAdvice, ControllerAdivce는 전역으로 ExceptionHandler를 적용해 준다. 스프링은 4개의 우선순위로 우선처리 하는 기능이 있다. 그중에 @ExceptionHandler는 원하는 Exception 클래스들을 속성으로 받아 처리할 예외를 지정할 수 있다.

 

UserErrorCode

1. 예외를 예상할 수 있는 부분들은 모두 RestApiException을 예외로 던지며 예외메세지를 Enum으로 만들어 보내준다.

front에서는 예외가 터질 경우 result.data 안에서 데이터를 확인할 수 있고, status가 200이 아닌 경우로 분기처리 해서 로직을 분리해 사용할 수 있다.

 

 

2. 아쉬운 점

FRONT에서 API를 호출 했을 때 오류가 난다고 해도 에러를 그대로 표출할 수는 없었다.

두 가지의 중 하나의 선택을 고민했다.

1. 예외 이유에 대한 status와 Message 응답 (ex. 값이 잘 못 되었습니다.)
2. 예외 이유가 아닌 status와 개발자가 공통으로 만든 에러코드 응답 (ex. W01, W02.. 등 )

→ 1번으로 진행했다. React.js 에서 Alert으로 띄우는 식으로 사용하기 좋다고 생각 → 하지만 여러 곳에서 해당 API를 사용할 경우에는 오류의 이유는 외부에서 알게 되면 안된다. 오직 개발자만 그 내용을 파악해야 한다 → 개발을 다하고 나서 선배에게 피드백 받았던 부분 → 젠장 아쉽다. 메세지를 에러코드로 변경 진행 필요

---

FRONT 단( 소스확인)

향상된 점

게시글 등록 속도 향상

게시글 등록 간편한 UI 인터페이스 제공

 

첫 React.js를 사용하면서 많이 헤맸다. 이 시간에 백엔드 공부를 더 할까 싶었지만, 프론트 개발도 알아야 실무에서 소통이 잘 될 거라는 생각에 계속했다. 기간이 짧았기에 깊이 공부하진 못했고, chatGPT의 도움을 많이 받으며 프론트 전반을 진행했다.

1. React.js 여러 라이브러리 사용

    return(
        <div class="wrapper">
            <UserHead />
            <Header />
            <Routes>
					<Route path="/" element={<Main />  } />            
					<Route path="/work/view/:id" element={<WorkView />  } />
                    <Route path="/work/init" element={<WorkList />  } />
                    <Route path="/about/init" element={<About />  } />
                    <Route path="/contact/init" element={<Contact />  } />
			</Routes>
            <Footer />
        </div>
    )

관리자와 사용자 화면을 나누기 때문에 Route,Helmet도 찾아보며 공부하며 한 땀 한 땀 진행 → Route로 url path을 나눌 수 있고, Helmet으로 url path에 따른 html head의 조정을 배웠다.

이미지 한개 당 ImageUploadBox 한 개

특히 Work 게시판의 등록폼을 나누기 어려웠다.

→ 유형 별로 각기 다른 모양을 넣어야 했기에 도저히 공통으로 잡을 수가 없었다(ImageUpload1,2 등)

→ 그래서 각각 템플릿을 추가하는 방식으로 진행

→ 다만 이미지에 대해서는 ImageUploadBox라는 컴포넌트를 만들어 사진 1개에 대해서만 등록, 삭제를 사용했다.

2. Work 등록 UI 개선

OLD

NEW

• OLD : 제공해 준 매뉴얼 pdf를 보고 올림
• NEW : 템플릿 모양대로 이미지 업로드 제공

이어지는 내용으로 고객은 Work 게시글을 올리기 힘들다고 했다.. OLD의 사진처럼 템플릿을 자유롭게 사용하기 힘들었다. 변경된 UI와 기능으로 인해 더 이상 매뉴얼 pdf가 필요 없어졌다. 고객도 크게 만족했다.

이미지 저장로직 변경

• form 작성 후 등록 버튼 클릭으로 저장 → 용량이 큰 이미지 파일을 다량으로 저장하기에 속도가 느려 등록 버튼 클릭 후 한참을 기다려야 한다. → → 이미지를 드래그하여 넣으면 1장씩 저장으로 개선 → 기다릴 필요 없이 back에서 순서대로 처리되어 속도 개선

---

아쉬운 점

1. 여전히 gif를 불러오는 속도가 느리다. 속도 개선을 위해 AWS S3 도입이 시급함으로 고객과 협의가 필요
2. React.js에 대한 설계가 조금 아쉽다. 폴더 구조를 url에 맞추는 게 좋은 개발이라고 한다. 다음에 참고하자
3. 기존 DB 구조로 파일첨부는 한 개의 테이블에서 처리

→ 큰 프로젝트가 될 일은 없지만, 나중에 서비스를 만들 때에 규모를 보고 선택을 잘해야 할 것 같다.

→ 파일 테이블을 여러 테이블에서 쓰다 보니, 트래픽 증가의 문제가 있을 수 있고, entity를 사용하는 JPA를 사용하니 코드복잡성이 올라간다.

→ 만약 정말 큰 규모에서 CQRS 기법 같은 것을 쓸 경우 테이블 분리에도 문제가 있을 것 같다. 아예 따로 사용하는 게 여러모로 좋을 것 같다는 생각이 들었다.

이번 프로젝트를 끝내면서 JPA와 Spring을 더 이해해야겠다는 생각이 들었다. 프로젝트를 만들어 볼수록 공부해야 할 점도 많고 사용해보고 싶은 기술이 늘어난다.