게시판 조회 관련에 대한 고찰

우선 이번 포스팅을 하게된 계기는

처음 게시판 조회를 구현하며  아래와 같은 여러가지 게시판 각각에 대해

어떻게 더 효율적으로 코딩하며 디렉토리 구조를 가져가는게 나을지에 대한 고민에서 시작한다.

 

우선 현재는 아래와 같이 app 디렉토리를 사용한 라우팅 페이지들이 너무 많다.

기본적인 회원가입, 로그인, 게시글 작성, 등등 핵심 기능 이외는 모두 slug를 사용해서

동적 라우팅을 할까 생각 중이다.

애브리타임의 웹상에서도 우선 각 게시판마다 특정 숫자(23123,71324)를 url로 지정해 둔것을 확인하였다.

.

.

.

또한 게시글 조회 api 구성에서도

전체 게시글을 반환한 뒤 프론트 단에서 건물별로 필터링을 하게 할지 혹은

백엔드 단에서 각각의 api 마다  필터링을 한뒤 그 필터링된 값들을 넘겨줄지에 대해 고민한 결과.

아무래도 데이터 로직관련은 백엔드에서 처리해주는것이 맞다고 생각하여 우선은 백엔드 단에서 필터링을 한다.

.

.

또한 백엔드 단에서 필터링을 하더라도 그 구성에 대해서도 고민이 되었다.

해당 게시판에 대한 url 값을  param 으로 받으면 api 하나의 호출로 인해 프론트단 모든 페이지에서

필터링이 한번에 될꺼 같다고 생각하였다.

.

.

.

결국 처음부터 너무 효율성을 따지기 보단 기능 구현을 마친후 현재의 기록들을 정주행하며

다시 리팩토링을 하기로 하였따.

.

.

결론적으로는 현재는 각각의 게시판 마다 api 를 생성 하려 한다.