왜?
DRF를 제대로 이용해보고 싶었고, 토이 프로젝트 대신 외주를 받았다. 또한 외주 내용중에 외부 API와 끊임없이 소통하며, 판매량을 통계내며, 이를 .csv파일로 다운로드가능하게하며, 또 다른 외부 API로 관련된 데이터를 보내는것이 재밋어보였다.
후기
AWS+DRF로 구현하였는데, 확실히 3번째 외주니까.. 방황하지않고 차근차근 구현하고, 문제들을 해결했다.
DB는 아래와 같이 설계하고 도중에 기획자와 피드백을하며 상당부분 바뀌기도했다.
재밋었던것은 외부 API의 구조를 분석하고, 다시 정제하고 외부 API를 사용하고, 다시 정제하고 계속반복해서 마지막으로 원하는 품목 주문정보, 이벤트 참가자 이름등을 알고 내가 만든 DB에 저장할수있었다.
이때, 자주쓰는 요청 함수들을 따로 utils.py로 빼내어, 코드량을 줄일수있었다. 그리고 필요하다면 utils.py안에 함수들이 서로 호출하여 서로의 데이터를 토대로 다시 외부 API로 요청하였다.
왜 자주쓰는 함수들을 빼내야하고, 범용적으로 쓴다면 return값은 어떻게 줘야하는지 생각하는 시간을 가졌다.
내가 구현한 함수들이 깔끔하고, 베스트는 아니겠지만 잘굴러간다!
docker에 Mysql을 띄어놓고 로컬서버와의 통신은 잘되어서, 그것을 그대로 AWS에 올렸다. docker-compose덕분에 구성자체는 만질것이없어서좋았다.
(docker 좀더 공부해서 더 다양하게써보자)
의외로 시간이 오래걸린 구현은 프로덕트 서버에서 crontab을 활용하는 것이었다.
내가 crontab을 이용해 서버 백그라운드에서 원하는 시간에 원하는 함수를 호출하는것을 짯는데, 내함수를 따로crontab돌려서 테스트해보니 오류가 안나서 내함수가 아닌 다른 문제인줄알고 4시간을 삽질했다.
하지만, 내함수가 문제였다.
내가 짠 함수 2개가 같은 외부 API를 사용하므로 이를 동시간에 token값을 받아 요청을 계속 보내고, 이는 결국 외부 API가 TOO_MANY_REQUEST 가 떳고, 원하는 처리를 하지못했기때문이였다.
깨달음
내 함수를 믿지마라
오류를 읽자(crontab은 log를 어떻게 찍는지몰라서 한참을 찾았다)
오류를 두번읽자