정치판 개발 계획(문제 확인과 해결)

Kyung yup Lee·2021년 1월 3일
0

문제

현재 정치판 앱이 가지고 있는 가장 큰 문제점은 당선자 공약을 open api를 통해 가져오는 데 시간이 너무 오래걸린다는 것이다.

약 15초~20초 사이가 걸리는데, 사용자가 앱을 바로 지우고 떠날 수도 있는 어마어마한 시간이다.

이 문제는 꼭 해결해야 하는데

현재 생각하고 있는 해결 방법은 두 가지가 있다.

맥락은 둘 다 같은데, 캐싱을 이용한 해결책이다. 다만 이 캐싱을 서버에서 진행할 것인지, 클라이언트 부분에서 진행할 것인지가 고민이다.

해결

클라이언트에서 캐싱을 한다면 Room을 이용한 로컬 스토리지를 이용하게 된다.

candidateId와 sgId 를 결합해 key를 만들고 처음 공약을 받아온다면 서버에 접속하여 open api를 받아오고,

이미 room에 해당 key에 링크된 데이터가 있다면 room에서 바로 데이터를 받아올 수 있다.

해당 방법의 단점은 반드시 한번은 사용자가 open api에 접속을 해야만 그 공약 데이터를 받아올 수 있다는 것이다.

장점은 돈이 안 든다.

서버 에서 캐싱을 한다면 mySQL 데이터베이스를 이용할 계획이다.

해시테이블을 구성하는 방법은 클라이언트에서 캐싱을 하는 방법과 같지만, aws 의 rds를 사용하고 트래픽이 늘어나 돈이 드는게 단점이다.

특히 open api의 모든 공약 데이터가 데이터베이스로 들어가게 되면 비용이 얼마나 커질지 알 수 없다.

데이터베이스 캐싱은 대다수의 사용자가 속도의 문제를 느끼지 못하게 되겠지만, open api를 사용하는 의미가 퇴색된다.

그래서 나는 두 가지 방법을 결합하려고 한다.

현재 앱에서는 가장 빈번하게 받아오는 공약데이터가 정해져 있다.

문재인 대통령 공약과, 각 시도지사 공약인데, 이 데이터들은 좋은 UX(사용자 경험)을 위해서는 반드시 빠르게 데이터를 받아와야 한다.

때문에, 이 데이터들은 데이터베이스에 미리 캐싱해두고, 클라이언트 쪽에서 이중 캐싱을 하는 방법을 택하려 한다.

그리고 나머지 후보자들의 공약들은 그렇게 빈번하게 접근되는 데이터가 아니기 때문에 클라이언트에서만 캐싱을 함으로써, 약간의 사용자 경험을 포기하더라도 비용적인 측면을 챙기는 것이 맞다고 생각이 들었다.

profile
성장하는 개발자

0개의 댓글