폰으로 적는거라 예시나 자세한 내용 없이 몇 글자로만 적어봅니다.

 

라우터는 bramus/router가 많이 언급되긴 했는데 막상 살펴보니 요청이나 응답에 대한 구현이 없어서 어차피 만들어 써야겠더군요. 이걸 사용하신분 걸 보니 응답 구조를 추가해서 사용하셨던데 저는 slim 쪽으로 기우네요.

덩치가 조금 커지지만 어차피 구현하다보면 덩치가 키워질거라서 그냥 슬림 붙이는게 나을 것같습니다. PHP 지원 버전도 7.4라서 딱이네요.

 

DB wrapper도 필요한데 아직 정하지는 못했네요.

PDO 지원하고 의존라이브러리가 많지 않으면 될 것같네요. Model의 쿼리 빌더로 사용되어야해서 구현과 지원하는 것들을 좀 검토해봐야할 것같네요.

 

당장은 그누보드 자체의 리소스들의 API는 지원하지 않을 생각이지만 테스트나 구현의 문제점을 확인하기 위해서는 어차피 하나쯤은 구현 필요가 있어서 회원정보만 간략하게 모델을 구현해보는 정도는 해봐야할 것같네요.

member 테이블을 기반으로한 모델을 만들고 db wrapper를 이용해 쿼리 빌더가 붙어야하겠고요.

모델에는 개인정보나 관리자에게만 보여지면 될 데이터는 가려야하고 graphql을 동시 지원해야하므로 데이터 필터링은 어쨌든 필요해지고요.

member는 본인의 정보를 다루는 정도로 /me 리소스를 구현하면 될것같네요. graphql 다중 리소스 접근에 대한 구현 테스트를위해 쪽지도 다루면 되겠네요. 일단은 딱 여기까지만. 제 플러그인에서 쓸것도 어차피 회원정보가 필요하고 /me/passkeys로 붙이면 될거라서 회원정보에 대해서는 어느정도 돌아가도록 구현이 필요하긴합니다.

 

컨트롤러가 rest와 graphql에 대응해야하고... 그렇다고 둘다 구현하는걸 강제하지는 않을 생각입니다. graphql은 옵션으로 둘 생각입니다.

 

db wrapper도 나중에 교체하게 될지 모르니 인터페이스를 따로 두는게 나을 것같네요.

 

cache도 고려해야하는데 그누보드 자체가 스킨에서도 쿼리를 날리고 워낙 규칙없이 데이터를 조작해버려서 사실상 db 데이터에 대한 캐시를 사용하기는 현실적으로 어려운 지경이죠. sql_query() 함수에서 insert/update 쿼리를 감시하여 캐시를 갱신해야하나 싶습니다.

Etag나 Age를 이용하는 정도가 현실적인 최선인 것같네요.