python3 최근 코드를 리펙토링하는 도중 각 프로세스별 로그가 매우 지저분하다는것을 느꼈다.
따라서 핸들러를 통해 한번의 기능의 시작과 끝을 알 수 있으면 좋을것같고, request 파라미터들과 return하는 값들을 알면 한번에 내용들을 파악하기 편할 것 같았다.
기본적으로 내가 개발에 사용하는 통신방식은 http통신이다.
각각의 핸들러는 실행되는 순서에 따라 나뉜다.
- before_first_request()
웹서버 실행이후 가장 먼저 처음으로 들어오는 api요청에만 실행된다. - before_request()
매 api요청마다 실행된다. - after_request(response)
http 요청이 실행되고 api발신지로 return 하기 전에 실행된다. - teardown_request(exception)
api발신지로 return 한 후에 실행된다. - teardown_appcontext(exception)
(http요청이 완전히 완료되면 실행된다는데. 이것과 teardown_request와 차이점은 아직 모르겠다.)
내가 핸들러를 사용하는 가장큰 목표는 가시적으로 프로세스단위의 로그를 한눈에 확인할수있도록 하는데에 중점을 두었다.
먼저 아래와같이 시작하기전에 각 요청의 파라미터와 요청 방식(post/get)인지 확인할수 있도록 했다.
위와 같이 로그가 남은후에 각 프로세스마다 실행결과를 각각 로그로 남겼다.
이후 모든 프로세스의 실행이 끝난이후에 어떤결과값이 리턴이 되었으며, 해당 결과를 로그로 남기기 위하여 after_request(response)를 사용했다.
response값을 로그로 남기기 위하여 엄청 애를 썼다. after_request의 매개변수인 response를 표현하기위하여 온갖 방법을 다 써봤는데 다 실패한후, 구글링을 통해 찾을 수 있었다.
response의 type은 <class 'flask.wrappers.Response'> 이고
프린트를 찍었을땐 <Response 45 bytes [200 OK]> 결과의 status_code만 나오는것이 확인되었다.
결국 response의 data값을 뽑아내어 바이트의 형식의 값을 decode하여 표현했다.
예외처리한 이유는 api요청에서 로그로 남기는 작업보다 프로세스의 실행과 return 은 무조건 되야한다고 생각했기에 finally를 사용했다.
나중에 기회가 된다면, http 요청 핸들러를 더 깊게 공부할 수 있는 기회가 오면 좋겠다.
-- 처음작성하는 velog 재밌당
404 not found