제 부족한 생각으로는 백엔드에서 필터링해서 처리해서 넘겨주는 것이 나을 것 같습니다. 프론트엔드단은 혹시라도 js 계열로 가게되면 소스가 보여지고 보안에 아직까지는 부족한 부분들이 있는 것 같아서... (예를 들어 회원정보가 모두 프론트로 넘겨진다했을 때, 레벨이 전송되면 js 단에서 값을 변경해서 다시 req할 수도 있을 것이고... -숨겨진 글들을 본다든지, 다른 사람의 쪽지를 본다든지 하는 일이 벌어지지 않을까요? 부족한 생각입니다... ㅜㅜ; PHP서버에서 global 변수 $member정보처럼 백단에서 처리를 잘해주어야... )

최소한의 정보를 서버에서 처리해서 넘겨주는... 레벨과 상황에 따라 배열의 요소들의 수도 조절해서... 백엔드에서 할 일이 많겠지만... ㅜㅜ;

예전에 네이버 계시던 선배는 데이터베이스가 대부분이라고... 거의 모든 요청들을 디비에서 처리해서 던져주고 프로그램은 결과를 받는 위주로... DBA의 역할이 커졌지만, 지금은 워낙 거대기업들이 클라우드로 고성능 HA를 보장해주니 성능보다 다양한 문제해결 로직에 더욱 집중할 수 있게 되어가고 있는 것 같습니다.

API서버를 얼마나 잘 만드는가가 관건인 것 같다는... 부족한 자의 생각입니다.

모든기능이 RESTful로 전환되어야 하는건 아닌것 같습니다.

적절하게 Mix되어도 충분히 좋은 기능들이 있는것 같구요

제가 겪은  걸림돌이 되는것들은
흔히들 대시보드와 SPA적용에 관련된 부분들이었습니다.

사용자(회사의 사용자)측에선 예쁜페이지들을 선호하고
최근 신입개발자들은 React / Vue 만 할줄알고
백엔드로 Django 의 샘플정도만 사용하다보니
Django로 다 충당하기엔 걸림돌이 많고,
그누보드를 하자니 React가 안되고 하더군요

기존것을 버리지 않더라도
서로 가려운곳을 긁어주는 역할을 할수있게 하는게 중요하다는 생각입니다.

개발하기에는 그냥 값 다 넘겨주는게 편합니다
다만 보안상 문제가 있고,
간단한 예를 들어 아이피를 보이고 아니고는 g5_board의 테이블은 설정값에 들어있는데
이것을 그누보드에서는 $is_ip_view라는 변수에 새로 받아 사용합니다
이러한 맥락의 것들로 $admin_href, $list_href, $write_pages 등이 있죠
이 부분들을 다 정리하여 최소한의 정보만 넘겨주는 형태(page의 경우 총페이지개수, 리스트에서 보여지는 개수만 있으면 됨)으로 할것이냐(어차피 페이지 개수나 번호, 계열등은 board, config에서 한번 요청하여 받아와 저장하면 받아올 필요가 없습니다)
또한 자주 변하지 않는 값들은 로컬스토리지같은데에 저장하면 api 요청을 줄일 수 있습니다.
다만 작업이 엄청 번거롭습니다.
아니면 active 페이지, 현재 페이지, 보여질 페이지의 범위까지 다 보내줄것이냐 등 그누보드에서 자잘하게 각종 테이블에 연결된 설정값이나 권한에 따른 출력값이 다른데,
분석이 조금 복잡할뿐 어렵진 않습니다.
다만 조잡하다는 느낌이 있어 작업하기는 매우 어려운 형태입니다.
특히 그누보드의 경우 관리자 설정에 따라 레이아웃이 변하는(카테고리, 비밀글, 에디터, 추천,비추천, 검색) 등이 상당히 많습니다.
그렇지 않고 현재 그누보드의 기능들을 최대한 가져오는 형태로 꾸민다면, react나 vue등의 프레임워크로 가져오는것은 상당히 버겁습니다.
물론 그누보드의 config, board 테이블에서 가져오는 설정값을 무시 하고 보안만 신경 쓴 채 요청과 해결을 하면 되겠지만
이러한 작업들은 한마디로 귀찮습니다.
현재 개인적으로 개발하는건 프론트쪽은 게시판 댓글작성, 글작성,캡챠 등까지 처리하였고 회원가입 부분과 소셜부분만 처리하면 어느정도 동작은 되는것은 완성될것 같지만
다른 일들이 바빠 진행하기에는 어렵네요.