[Milestone Week 2] 알람 일정 CRUD 기능 구현

1. 알람 일정 등록 기능

2주차의 알람 일정,  특히 등록에 관한 기능은 약올림 서비스의 핵심 서비스 중 하나로, 카메라 촬영 또는 직접 입력으로 촬영한 이미지와 함께 알약을 등록하며 캘린더와 시간, 주기 계산 등이 모두 복합적으로 이루어져야한다.

 

그래서 온 팀원이 마치 한 몸인 것처럼 기능구현의 티키타카가 이루어져야했고, 실제로 그렇게 하였다! 그래서 아래와 같은 아름다운 기능이 구현 될 수 있었던 것이다.

 

특히 약 등록의 과정이 매우 복잡했다. 스크린 이동이 많았고, 그 스크린마다 정보(state)를 항상 가지고 이동시켜야했기 때문이다. 

 

이 과정에서 나는 camera에 접근하여서 전방/후방카메라 선택/이미지 촬영/선택 또는 재촬영 기능과 알약 이미지를 통한 종류 예측 기능에 대해 집중하였고,  HJ님이 image caching에 대해, SH님이 stack과 screen에 대해 밤낮없이 고민하고 공부해주셨다. 그 결과 

아래와 같은 순서로 약 등록 기능은 잘 마무리 되었다. 

( HJ님께서 담당해주신 image caching과 S3를 이용한 이미지 저장기능에 대해서는 [Sprint 2]Data Caching / Schedules 관련 기능 구현(Week5)을 참고하면 아주 잘 설명되어있다.🙂)

이미지 촬영 -> 이미지 캐싱처리 -> 이미지 확인 화면에서 캐싱 저장소에서 해당하는 약 이미지 불러오기 / 해당 이미지 server로 전달 ->이미지 예측 후 결과값 client 전달 ->캐싱된 이미지 + 예측값 렌더링 ->  약 이미지 server에 전달 ->
이미지 S3 업로드 후에 링크 값 전달 -> 최총 약정보와 이미지 링크 대응/ 서버에 약정보 create 요청

2. 알람 일정 수정 기능

어디선가 그런 말을 들은 적이 있다. 'ver 2.0까지는 해봐야 아 진짜 서비스 하나 완성했구나'(?)(이런 느낌의 말이었는데, 아무튼 ㅋㅋ)

알람 일정 수정 기능 구현을 진행하면서 이 말이 계속 머리속을 맴돌았다. 이래서 처음 구현보다 수정이 어렵구나.. 싶었기 때문이다.

 

일정 등록시에는 완전히 새로운 데이터를 생성하는 것이므로 기존 데이터와의 중복의 걱정이 없었지만 수정같은 경우는 기존의 데이터를 새로운 것으로 바꾸어야 한다는 점에서 철저하게 DB 트랜잭션의 단위가 순서대로 잘 진행되어야 한다. 

 

그런데.. 아직 restful API에 대해서 확신을 가지지 못하여서 무조건 한 단위로! 하나의 기능!을 하도록! 짜는게 최고의 restful 한 API인줄 알았던 당시는 여러개의 DB에 join되어서 처리할 수 있는 것인데도 모두 개별API로 만들어버렸고, 결국 .then 지옥과 같은 코드가 생겨났다. 

게다가 Heroku의 clearDB 무료 버전은 DB connection을 10초 밖에 할당해주지 않는다.ㅠ

 

이 과정에서 HJ님이 DB transaction공부를 하시고 일단 에러 발생시마다 어느 단계에서 에러가 발생했는지를 조건문으로 다 파악하여서 그 부분만 에러발생 alert를 띄워 쿼리문을 다시 보낼 수 있도록 많은 고생을 해주셨다. 

 

이런 저런 문제점을 근본부터 해결하지 않고는 안된다고 판단이 되어서 먼저 우리 팀이 취한 조치는

1. Heroku clearDB connection을 10초라는 치명적인 문제를 해결하기 위해 DB를 유료 RDS로 바꾸었다. 

2. HJ님과 내가 전적으로 API 리펙토링을 담당하기로 하였다. 

 

Restful API는 도대체 어떤것일까?

비효율적이지만 이론상 맞는 API가 좋은 것일까 아니면 restful하다고는 못하지만 우리 서비스의 통신에 가장 효율적인 형태가 좋은 것일까? 수많은 질문을 가지고 HJ님과 이런저런 대화 끝에, HJ님께서 실무에서 일하시면서 배운 바를 공유해 주셨고, 그 방향으로 리펙토링 해 보자고 결론이 났다. 

HJ님 말대로, 정답은 없고, 서비스의 특성에 맞게 하되 약올림 서비스의 경우 client를 최대한 가볍게 만들어야 한다는 점에서 client 기준에서는 진짜 최소한으로 API를 보내고, 서버에서 client을 맞이하는 controller라는 폴더에서 세부적으로 쿼리를 쪼개고 그 응답을 다시 합쳐서 client에 보내주는 것이 좋을 것이다. 

(이에 대한 내용은 HJ님께서 작성한 [Sprint 2]Data Caching / Schedules 관련 기능 구현(Week5)을 참고하면 아주 잘 설명되어있다.🙂)

3. 알람 일정 삭제 기능

위의 두 기능을 구현하고 나면 알람 일정 삭제 기능은 뭐... 매우매우 쉽게 느껴진다.

 

등록시에 한 알람 당 '주기'를 설정하여 여러 날짜에 일정이 등록되는데, 삭제시에도 클릭한 그 날짜의 알람만 삭제할 것인지, 아니면 주기를 설정한 모든 날짜의 알람을 삭제할 것인지 선택하고, 그에 맞게 hard delete 시켜주었다. 

 

 

 

그래도 여기까지 하고 나니 큰 산 하나는 넘은 듯 했다.(그렇다 말 조심해야한다..ㅋㅋㅋ)

아니 그래도 정말 대단한건 사실이다. 낮에는 회사를 퇴근 후에는 이런 프로젝트를 한다는게, 

그리고 매번 피곤한 기색 하나도 하지 않으시면서, 활발한 커뮤니케이션, 마일스톤에 맞추려는 책임감, 장인 정신.. 우리 팀원 분들 정말 다들 대단하시고 배울 점이 참 많다.