vue2로 할때도 그랬지만 소셜로그인이 가장 복잡합니다.

결국 여기서 흐지부지 하다가 vue3 나오면서 아예 뒤엎기로 마으을 굳혔기도 했구요.

그냥 개인용이라면 db 구조 무시하고 하면 각각의 로그인 api를 제공하는 사이트에 맞춰 제작하면 되지만,

그누보드의 db구조에 맞춰 소셜 로그인까지 갖춰서 하려 하니 복잡하네요.

그누보드 소셜로그인의 경우 별도의 공개된 php 플러그인을 커스텀하여 활용하고 있는데,

공개 된 소스에서 커스텀하다보니 흔히 말하는 스파게티 코드가 많은것 같습니다

단순히 제가 분석을 못하는걸수도 있지만요.

기존소스를 그대로 활용할까 하다가도 기존 소스 활용시 개발시에 크로스도메인 설정이나 예외설정 환경 설정이 복잡하여 생산성이 떨어지고, 새로 만들자니 그누보드에서 소셜로그인 테이블과 실제 테이블을 연동시키는 방법을 직접 하나하나 실행해보면서, 또는 소스를 봐가면서 해야하기 때문에 매우 번거로운 형태입니다.

기존의 소스를 활용 vs 그냥 새로운 api에 맞는 소스 작성

둘 중 어느걸 할까 계속 고민해왔지만 결국 후자를 선택했습니다

그누보드 api 자체를 최대한 그누보드 코어 부분만 뗀 형식으로 하려는 큰 방향성이 있긴 하지만, 이 부분만큼은 예외네요.

그누보드에서 사용하는 php 플러그인은 아예 벗기고, 그누보드에 맞게 해당 플러그인을 커스텀한 functions.php의 일부 함수 구조는 그대로 따라갈 것 같습니다.

현재 그누보드 db 형태에 맞춰야 하니까요.

둘 다 오래 걸리지만 그나마 후자가 유지보수나 api 형태로 제공할 때 더 간편하고 이해하기 쉽단 생각이 들었네요.

그나마 차악을 선택하는 형식입니다

이러한 api형태로 바꿀 때 번거로운 부분은 그누보드 내에서 첨부된 파일을 저장하는 db형식에서도 어려움을 느꼈고, 그 부분에선 결국 업로드 쪽의 프론트 컴포넌트를 그누보드에 맞게 커스텀화 했었습니다.

그리고 현재 그누보드 소셜 로그인의 경우 구글 로그인은 제대로 지원되지 않고 있으며(구글 API+ 종료예 따른) 페이코 등 잘 쓰이지 않는 소셜로그인도 있고,

구글 로그인의 경우 백단에서만 처리하려고 한다면 people api+까지 동원해야하지만, 프론트쪽에서 일부 처리를 한다면, 그렇게까지 하지 않는 편의성도 있습니다.

그렇기에 마음이 더 기운것 같기도 하네요.

현재는 카카오쪽만 20% 정도 완성된듯 하네요.

우선 하나의 소셜 로그인만 완성하면 네이버 구글 등의 문서 참조시간 이상으론 걸리지 않을듯 하지만 

소셜로그인쪽은 아예 새로 개발하는것이라 버그 체크, 안정성 등을 체크하는데 상당히 오래 걸릴 듯 합니다.