서론
Unsolved.wa 프로젝트 기획 회의 중, 현재의 방식으로는 api 호출제한의 문제로 인해 정상적인 서비스가 불가능 할 것 같아 구현 방식을 변경하기로 하였다
먼저 기존의 방식은 백엔드에서 필요한 데이터를 전부 solved.ac api를 이용하여 호출해 작동하는 방식이었다
https://github.com/AnA-algorithm/boj-organization-solved-list
각 유저의 푼 문제수가 변화했음을 감지해 줄 수 있는 트리거가 없어 각 유저에 관한 정보를 전부 호출해야 하기 때문이다
현재는 시간이 오래걸려도 하루에 한번 unsolved 문제 리스트를 공유하기 때문에 문제가 되지 않지만 이를 웹서비스로 구현하려면 실시간으로 작동을 해야 할 것이다
첫번째 시도, 하지만 아쉬운...
그래서 생각한 방법이 문제를 푼 유저가 사이트에서 갱신 버튼을 누르면 그 유저에 대한 정보를 요청해 갱신을 해주는 것이다
그러면 모든 유저에 관해 갱신을 하지 않고 각 유저에 대해서만 호출을 하면 되므로 호출수가 현저히 줄어든다
하지만 이 방법에는 크게 두가지 문제가 있다
첫번째는 문제를 많이 푼 유저일수록 100개 단위로 pagination되어있는 푼 문제리스트를 조회하게 되면 15분당 총 256회 제한이니 1000문제를 푼 유저가 25명만 갱신버튼을 눌러도 호출 제한에 걸릴것이다
두번째 문제는 unsolved 리스트만을 제공하는것이 아닌 유저의 조직 랭킹에 관한 기여도를 보여주기 위한 기능때문에 생긴다
조직 랭킹 상승에 관심 동기를 부여 받을 수 있는 성향의 유저라면 본인이 랭킹또한 제공하는 것이 더욱 동기를 부여 할 수 있을 것이라 생각됐다
그래서 우리의 조직의 랭킹을 올리는데 내가 어느 정도 기여했다를 보여주려고 한다
하지만 이 기능을 제공하려면 어떤 유저가 특정 문제를 조직내에서 First Solve 했는지 알아야한다
유저가 갱신 버튼을 눌러 갱신하도록 하면 만약 동시에 두 유저가 같은 문제를 풀었을 때 문제를 먼저 풀었더라도 갱신 버튼을 느리게 눌렀다면 반영되지 못하는 문제가 발생한다
두번째 시도
고민을 하다가 문득 생각이 났는데 보통 api서버를 제공해 주는것이 back-end 그리고 그 api서버를 이용하여 페이지를 그려주는 것이 front-end라는 생각이 들고 solved.ac api 호출을 꼭 back-end에서 해야하는가? 라는 생각이 들었다
그래서 front-end에서 solved.ac api를 호출하고 받은 값을 다시 back-end로 넘겨주는 방법을 생각했다
그러면 각 유저가 solved.ac api 호출을 담당하기 때문에 back-end에서는 조직에 관한 정보만을 호출해서 사용하면 되기 때문에 호출 제한에 걸릴 일이 없어질 것이다
하지만 이 방식으로 하더라도 두번째 문제인 각 유저가 직접 갱신을 하도록 해서 생기는 문제는 해결되지 않았다
그렇다고 하더라도 이 문제는 유저의 편의성 문제이며 사이트가 아예 15분동안 작동하지 않을 수 있는 문제인 첫번째 문제를 해결 할 수 있었던 것은 큰 수확이었다
세번째 시도
결과가 전부 pagination되어있어 100개마다 호출을 한번씩 해야한다는 점은 계속 골칫거리였다
다음과 같이 /search/problem?query=solved_by:siontama 와 같은 형태로 호출을 하면 문제에 대한 여러가지 정보를 담고있기 때문에 reponse가 너무 커질수도 있기 때문인 것 같기도 하며, solved.ac가 100개마다 페이지로 화면을 제공하고 있기 때문이 가장 큰 이유인 것 같았다
계속 다른 방법을 고민하며 여러가지 방법을 생각해보던 중 /account/verify_credentials 이라는 api에서 본인 시도한 문제 목록을 전부 반환해 주는 것을 알게되었다
이 방법은 내 정보 보기와 같은 /account의 api를 활용하여 입력으로 solvedacToken 즉 유저의 로그인 된 정보를 알 수 있는 키 값이 필요했다
쿠키에 저장되는 값인데 solved.api documentation 사이트에서 잘 작동되지 않아 어떻게 쿠키값을 활용해서 요청 할 수 있는지를 팀원들과 알아보기로 했다
https://solvedac.github.io/unofficial-documentation/#/operations/verifyAccountCredentials
마치며
기존에 제공하던 기능들을 웹서비스의 형태로 제공하려다 보니 생각보다 고려해야 할 점들이 많았다
특히 서비스라는 것이 되기위해 어떠한 기능들이 들어가고 그 기능들은 어떤 요구사항이 존재하며 어떤 스펙으로 제공되지에 대해서 팀원들과 논의하는데 한참 걸렸다
일단 가장 먼저 중요한 이 서비스의 목적 및 방향성부터 팀원들과 서로 생각하는 바가 달랐고 그것부터 일치시켜 나갔다
다들 많은 의견과 아이디어들을 내줘 좋은 방향으로 서비스를 기획하며 개발이 진행되고 있다
누가 시켜서 하는 프로젝트가 아닌 정말 필요에 의해 시작한 프로젝트인 만큼 훨씬 많은 공부가 되고 있는것 같다
