https://github.com/ohah/gnubaord_api

글쓰기부분, 글수정 부분까지 업데이트 되었습니다.

API에서 훅 기능은 필요 없지 않을까 싶었는데 그냥 훅 기능 넣는게 개발하기 더 편할것 같아 API에도 동일한 이벤트 발생시 동일한 훅을 사용하게 해놨습니다.

단순히 db에 저장되어있는걸 보여주는건 정말 쉽습니다.

예를 들어 게시판을 보여준다면 그냥 쿼리 날리고 해당문을 json이나 약속된 포맷으로 변환시키면 됩니다

단 글쓰기나 글 수정, 글 읽기 등의 권한 체크 등이 일원화되거나 체게적으로 되어있지 않고

board.php 또는 write.php, password.php에서 걸러지고 또 설정에 따라 보여줘야할 것이 다른 경우가 많습니다.

그누보드 구조처럼 백앤드와 프론트앤드를 크게 구분하지 않으면 보여줄 필요가 또는 보여줘서는 안되는 변수는 그냥 선언을 하더라도 사용하지 않으면 되지만, 

api제공시에는 보안상 필터해야되거나 api에선 보여주면 안되는것들이 있습니다

예를 들어 권한 체크를 할때 get_member, get_group, get_config등의 함수를 자주 사용하는데

이부분에는 암호화 되어있다고는 하나 패스워드값 또한 가져오고,

회원가입자의 개인정보인 집주소나 핸드폰 번호가 다 담겨있습니다.

config에도 구글로그인이나 네이버 로그인 영카드 사용중이라면 결제 키값 등 노출되서는 안되는 값들이 들어있습니다.

이러한것은 모든것을 관리하는 관리자 계정이 아니라면 api 요청시 절대 노출되어야 하지 않아야하고 별도의 필터링을 갖추어야 합니다.

그리고 해당 값 $config, $board, $member, $group 부분에서 저장된 데이터에 사용자가 글을 쓰거나, 글을 삭제하거나, 글을 보거나 접근을 할 때에서 이 부분의 db에 접근하여 확인해야합니다.

하나의 이벤트를 위해 여러가지의 db를 호출한다는것은 그리 좋은 방법은 아니라 생각되지만,

그누보드에선 그렇게 호출하고 체크하기 때문에 API에서도 이런 방식을 취해야합니다.

php같은 위에서 아래로 순차적으로 실행하는 언어의 경우는 그래도 좀 낫지만,

node같은 자바스크립트형 언어로 활용할때는 비동기 동기 프로그래밍을 잘 구분지어서 호출해야합니다.

node로 그누보드 api 백단을 설계할시 어쩔 수 없이 await, async, promise를 남발하게 되는데 이것도 속도 저하의 요인이 됩니다.

그리고 그누보드에선 세션을 활용하여 이미 인증된 권한에 대해 처리하고 있는데 이 부분도 연동시켜줘야 하구요.

소스를 분석해보시면 알겠지만 그누보드의 대부분의 권한 체크, 또 함수 사용에서 global변수를 활용하는 경우가 많습니다.

변수를 함수에 전달하고, 그 변수를 함수에 처리하고 결과물을 리턴해줘야 후에 유지보수하거나 분석하기 편한데,

글로벌 변수를 많이 쓰다보니 해당 함수를 호출하는 모든 페이지에 가서 어떤식으로 그 변수를 호출하고 있는가를 살펴봐야합니다.

그리고 이러한 글로벌 변수는 백단과 프론트앤드가 구분되어 있지 않으면 유용하지만, 구분되어야 하는 경우에 그대로 활용하기 어렵습니다.

또한 글쓰기나 글 수정의 경우 게시판의 설정에 따라 돌려줘야하는 값이나 줘야하는 값 등의 부분이 다르기에 백단에서 다 걸러서 보내줘야합니다.

지금 그누보드 형태는 일단 다 불러오고 필요 없는 부분을 안 보여주는 형태가 대부분인데

백앤드와 프론트앤드과 구분되어있지 않은 프로그래밍에선 변수를 노출만 시키지 않으면 되니 괜찮은 방법이지만

API처럼 백단과 프론트앤드를 구분할때는 이 필요없는 부분을 API에서 다 확인하여 보내줘야합니다.

그리고 그누보드에서 사용하는 함수들은 모두 클래스화 되어있지 않고 function으로 정의 되어있는데

이 부분 또한 API 설계를 매우 어렵게 합니다.

이러나 저러나 최근 트렌드는 자바스크립트든, 함수형 프로그래밍과 객체지향 프로그래밍을 만들고자 하는 프로그램에 따라 적절하게 사용하고 있는데

그누보드의 경우 핵심 코어라고 할만한 함수나 객체가 없습니다.

common.php에서 대부분의 권한체크와 변수, 보안처리가 이뤄지고 common.lib.php에서 대부분의 함수가 존재하긴 하지만 위에서 말했듯이 global 변수의 잦은 사용으로 변수가 들어가고 나가는 과정이 명확하지 않고 난잡한 편이기도 하구요.

그리고 captcha_html, chk_captcha, token_check, editor_html, commom.js 등에 있는 보안이나 값 전송에 관한 부분분, 그리고 글쓰기 에디터의 종류 등은 프론트앤드에게 떠넘길 부분이 아닌 API에서 어느정도 명확한 값을 별도의 포맷으로 전달해줘야 하는 점이 있습니다.

이부분에서 가장 번거로운게 그누보드 소셜로그인 쪽이구요.

API화를 시킨다면 그누보드내의 설정값과 별도로 버려야할 것도 생깁니다.

예를 들면 테마 경로, 테마값, 게시판 스킨 경로등은 API화 할 때 필요 없는 부분입니다

add_styleshteet도 마찬가집니다

단 add_javascript 등 script로 불러오는 공통된 자바스크립트에서 페이지에 따라 폼값 토큰값 생성, 폼값 전송, 주소, 다음 url 등 페이지에서 필요한 부분을 불러오는 스크립트 부분이 있는데, 여기서 처리하는것을 API에서 처리하게 할것이냐, 아니면 별도로 프론트앤드 개발시 필수로 넣어야 할 부분으로 해야할것이냐도 고민해봐야 하는 부분입니다.

현재 그누보드에선 대부분 클라이언트 스크립트에서도 체크 하고, php에서도 체크하는 경우가 대부분이지만,

여전히 클라이언트에서만 체크하는 부분도 적지만 있습니다.

또한 최근에 나온 짧은주소의 경우도 그누보드는 get_preety_url, shot_url 등이 함수로 변환하고 있는데

이러한 주소 설정에 따른 url 리턴이나 프론트앤드에서 지켜야할 url 규칙 또한 생각해봐야 합니다

그나마 별도의 프레임워크를 사용하지 않고 php로 api를 개발하고 있는

저같은 경우 어느정도 소스의 변환만 하면 그누보드의 권한 체크 및 변수를 어느정도 수정만 가한다면  그대로 활용할 수 있는것이 많습니다.

하지만 언어가 다르다면 이러한 부분에서 대부분 막혀서 어려워질거라 생각이 되네요

과거 react 1년전쯤에 그누보드 db를 활용한 개발을 잠깐 취미삼아 해본적이 있었는데

이때는 백앤드를 node로 했다가 로그인 처리에서 엄청 오래걸리고, 그리고 값 보여주는데서도 처리가 너무 번거로워 포기한적이 있었거든요.

말이 너무 길었는데 결론만 보시려면 아래의 3줄요약을 보시면 됩니다.

1. 그누보드의 경우 API 시킬 때 그누보드의 특유의 권한체크 방법을 API에서만 처리하여 가공한 데이터를 보내주는게 매우 번거롭습니다.

2. 그누보드에서 필수적인 플러그인 사용이 있는데 이것도 백단과 프론트앤드과 명확히 구분되어있지 않고 호출하는 페이지와 받는 페이지의 구분이 명확하지 않다. 이 부분을 잘 구분해서 처리해줘야한다.

3. 그누보드에서 작성 및 권한체크는 php에서도 스크립트(클라이언트)쪽에서 처리하는 부분이 중구난방하게 있다. 해당 부분의 권한 처리는 API쪽으로 다 넘기는것이 보안상 낫지만 그 경우 권한 체크는 더 복잡해지고 리턴값에 대한 처리기준이 새로 있어야 한다