2차 프로젝트 메인페이지 기능 구현을 위한 목록 조회 API 기능 구현 시
필요한 request.GET / request.GET.get() 에 대해 공부
먼저 Pagination 기능에 대해 알아보겠다.
Pagination(Paging)기능
백엔드에서 가지고 있는 데이터는 많고, 그 데이터를 한 화면에 전부 보여줄 수 없는 경우에 사용한다. 일정 길이로 끊어서 전달한다.
데이터베이스에 많은 수의 데이터가 있을 때, 한 번에 모든 데이터를 돌려주는 대신 예를 들어 0번부터 49번까지 50개씩 돌려주는 것을 의미한다.
즉 한정된 네트워크 자원을 효율적으로 활용하기 위해 쿼리의 결과값으로 리턴된 리소스를 분할하여 전달하는 것을 의미한다. 이러한 기능을 구현하게 되면 리소스 낭비를 막고 빠른 응답을 기대할 수 있다.
"이전/다음 페이지"를 끊어 보여주는 기능
Pagination은 프론트엔드, 백엔드 양쪽에서 모두 구현해야 한다.
프론트엔드에서 현재의 위치(Offset)과 추가로 보여줄 컨테츠의 수(Limit)를 백엔드에 요청한다.
페이지네이션 방식은 현재의 위치를 의미하는 offset (page) 과 한 번응답 시 돌려줄 갯수를 의미하는 limit(per_page), 두 가지의 파라미터를 이용한다.
GET 요청시 URI 예시
https://todo.com/todos?offset=3&limit=20 // 페이지는 3번, 갯수는 20개
request.GET
request.GET은 GET으로 받는 인자들을 다 포함하는 딕셔너리 객체이다.
{'key1': 'value1', 'key1' : 'value2'}
get() 메서드는 키값이 딕셔너리 안에 있으면 밸류값을 리턴해준다. 키값이 존재하지 않으면 디폴트값 None을 리턴한다.
request.GET.get()은 위 두 개념을 합친 것으로 GET요청이 접근할 수 있는 키와 밸류값을 이용한다.
궁금한점
유저단에서 실제 페이지 요청 시 URI에 offset과 limit 값은 나타나지 않는다.
유저 요청 -> 프론트 서버 -> 백엔드 서버로 API 요청
백엔드 서버 -> 프론트 서버(offset,limit 값이 나오지 않게 처리) -> 유저
대략 통신은 이렇게 진행 되는 것 같은데.. 더 찾아봐야 겠다.
페이지 네이션 기능은 이전 기록까지 불러오기 때문에 성능이 좋지 않다고 한다.
개선 방법으로는 Cursor 기반 페이징 이라는 방식이 있다.. (직전 조회 결과의 마지막 ID 를 넘겨서 다음 페이지를 조회하는 방식) 해당 방법에 대해 공부하여 나중에 적용해 보면 좋을 듯!