나의 WAS 변경점, 한계 그리고 개선사항

지난 내용은 여기와 같다.

https://b1ackhand.tistory.com/262

이후에 나의 WAS를 어떻게 발전시켰고 어떤 문제점을 마주했는지 기록해보려고한다.

 

발전사항 및 변경점

나의 구조를 요약하자면 Request에서 api 처리를 Response에서 정적인 컨텐츠를 반환한다. 그림으로 보면 위와 같다. 다음으로 구현해야 될 내용은 Post요청 -> Session 로그인 -> 동적인 HTML -> 게시판 처리 이와 같다.

 

먼저 Post요청을 처리하기 위해 Request에 Body Parser라는 클래스를 만들어줬다. Post요청에서 지금은 post request x-www-form-urlencoded 형태로 들어오지만 다른 스프링 프로젝트를 해보면 json형태로 오거나 다양한 형태로 오기 때문에 이를 처리하기 위한 클래스이다. 이를 팩토리 패턴으로 처리했다.

 

다음은 Session 로그인이다. SessionManager를 만들어주고 Session값은 uuid또는 secureRandom등으로 만들어주고 hashmap형태로 저장한다. cookie형태로 저장하고 있으면 프론트에서 백엔드에 요청을 보낼때 헤더에 값을 넣어서 들어온다.

 

나의 완벽했다고 생각한 구조가 한번 어려움을 겪었던 곳이 동적인 HTML처리이다. ResponseHandler가 HTML을 보내줬는데 이걸 처리 할 수 있는 곳이 애매한 것이다. 동적인 HTML예시로는 로그인 했을때는 로그인 버튼에 유저의 이름을 적어주는 등의 처리를 한것이다. 이는 보통 프론트에서 변수로 두고 백엔드의 요청에 따라 자바스크립트로 처리를 할 수 있지만, 이번에는 BE에서 처리를 해줬다. HTML을 StringBuilder에서 값을 찾아 replace해서 HTML을 직접 변경해주는 것이다.

 

마지막 게시판 처리에서는 H2 데이터베이스와 연결하고 api마다 request에서 처리를 해줬다. 원래 요구사항에 파일업로드 및 처리등이 있었다(그리고 이것까지 한 사람들의 말을 들어보면 꽤나 오래걸린다고 한다) 시간이 있었으면 파일업로드 까지 하고 싶었는데 데이터베이스 연결 및 오류처리 하는데 시간을 썼다. 최종적인 구조는 아래와 같다.

 

 

한계

우선 가장 큰 문제점이라고 생각하는 부분은 RequestHandler부분이다. Scale이 작다고 생각하고 HashMap형태로 Route, 함수를 때려박은게 없지 않아 있긴하다. 문제가 생긴 부분은 예외처리 부분이었다. 최종적으로 Response에서 StatusCode를 처리 해주는데 RequestHandler에서 문제가 생기거나 ResponseHandler에서 문제가 생겼을때 이를 어떻게 든 처리해서 Response에게 문제가 생겼음을 처리 시켜줘야 되는데 현재의 구조는 절차지향? 의 느낌이라서 처리하기 어려웠던 것이다.

개선사항

1. 쓰레드 안전성

멀티쓰레드에서 안전한 방식으로 구현을 고려해 봐야했다.

2. 일급컬렉션

HashMap에 해당하는 변수들을 class화 해서 안전하게 처리할 수 있다.

3. 싱글톤 패턴

RequestHandler나 ResponseHandler는 들어온 요청을 처리하고 반환하기 때문에 싱글톤 패턴으로 처리가능하다.

4. 예외처리 및 테스트코드

시간이 부족하여 이 부분에 힘을 주지 못했다. 실제 프로젝트에서는 제일 중요한 부분이다.

 

후기

처음에는 요구사항대로 따라가는데 급급하고 내 방식으로도 완벽하게 처리 할 수 있다고 생각하였는데 처리할수록 조금 불편한 구조가 됐었다. 그리고 Spring을 사용하는 방법에 급급했는데 이렇게 직접 만들어보고 나니 현대 다른 상용화된 WAS들이 복잡하지만 크게 어떤의미로 동작하는지 이해하는데 더 도움이 된것같다. 

 

스스로 생각하고 구현했던 코드는 아래 주소에 있다.

https://github.com/sjmjys954646/be-was/tree/main