프론트엔드를 테마 컴포넌트로 분리하여 플러그인 개발 속도 향상

저는 이전에 플러그인을 개발할 때 더 빠르게 코딩하기 위해 로컬 환경을 설정하는 방법에 대해 질문한 적이 있으며, 다른 분들도 같은 질문을 했다는 것을 알고 있습니다.

최근 제가 사용하고 있는 새로운 워크플로우가 아주 잘 작동하고 있어서, 다른 분들께도 도움이 될까 해서 공유합니다. 모든 문제를 해결해 주지는 않지만, 작업 환경을 훨씬 쾌적하게 만들어 줍니다. 자세한 내용은 다음과 같습니다:

먼저, 이전까지 제가 겪었던 문제입니다:
플러그인을 개발하려면 로컬 인스턴스에서 Discourse를 실행하며 코딩해야 했는데, 이는 매우 느렸습니다. 그 이유는 1) 파일이 변경될 때마다 페이지를 새로고침해야 했으며, Discourse를 실행 중인 컴퓨터에서는 페이지 새로고침이 매우 느렸기 때문(페이지 새로고침에 약 30초 소요)이고, 2) 개발용으로 테스트하던 로컬 Discourse 사이트 자체가 매우 느렸기 때문(내비게이션 지연 등)이며, 3) 백엔드 플러그인 코드를 변경할 때마다 서버를 정지하고 다시 시작해야 했으며, 이 과정에 몇 분이나 걸렸기 때문입니다. 이 모든 동안 컴퓨터 팬 소리가 시끄럽게 났습니다.

그 결과, 매끄러운 워크플로우라면 약 10분 만에 코딩할 수 있는 작업을 약 1시간이나 걸렸습니다.


제 해결책

플러그인 개발과 달리, 테마 컴포넌트 코딩 워크플로우를 사용하는 것은 Discourse 테마 CLI 덕분에 훌륭합니다. (저의 사용 단계는 여기에 있습니다.) 빠르고 매끄럽습니다.

테마 또는 테마 컴포넌트 코딩이 훨씬 빠르고 쉬운 이유

테마 CLI 도구를 사용하면 로컬에서 테마를 코딩하면서 라이브 사이트(실제 사이트, 실제 사이트의 미리보기 모드, 또는 설정해 둔 테스트용 라이브 사이트)에서 테마를 실행(관찰)할 수 있습니다.

따라서 컴퓨터에서 Discourse 자체를 실행할 필요가 없으므로, 플러그인 개발 시처럼 컴퓨터가 느려지지 않습니다. 그리고 변경 사항을 만들 때마다 연결된 라이브 사이트를 새로고침하기만 하면 변경 사항이 바로 반영됩니다.

그래서 깨달은 점은 이렇습니다. 플러그인 코딩을 할 때 대부분은 프론트엔드 관련 작업(hbs 파일, javascript 파일 등)입니다. 백엔드 관련 작업(라우트 설정, 커스텀 필드 생성 등)은 아주 적은 비중을 차지합니다.

따라서 모든 것을 함께 코딩하는 대신, 테마 컴포넌트 워크플로우의 이점을 살리기 위해 프론트엔드 코딩을 모두 테마 컴포넌트로 옮기는 것입니다.

플러그인의 백엔드 부분을 업데이트해야 할 때만 다시 플러그인에서 코딩을 해야 합니다. 하지만 제 플러그인 개발에서는 그런 경우가 전체 작업 시간의 약 20%에 불과합니다. 덕분에 나머지 80%의 시간을 훨씬 더 나은 테마 컴포넌트 워크플로우로 보낼 수 있게 되었습니다.

모든 것을 프로덕션으로 옮길 때가 되면, 다음과 같은 방법을 사용할 수 있습니다:
-테마 컴포넌트와 플러그인을 분리한 채로 유지하고, 관련 Discourse 사이트에서 둘 다 사용하거나,
-모든 코드를 한 곳에 모으는 것이 중요하다면, 그때 테마 컴포넌트 코드를 플러그인으로 이동합니다. 솔직히 이 과정은 다소 번거로울 수 있지만, 프로덕션 업데이트를 준비할 때까지는 빠른 테마 컴포넌트 워크플로우의 이점을 즐기면서 한 번만 수행하면 됩니다.


이것이 전부입니다.

혁명적인 방법은 아닙니다. 하지만 한동안 저를 힘들게 했던 문제를 훨씬 더 나은 방향으로 바꿔 주었습니다.

네, 좋은 접근 방식입니다.

저는 그 접근 방식을 주제 목록 미리보기에 이미 꽤 오랫동안 적용해 왔습니다. 가능한 한 많은 기능을 TC(토픽 컨트롤러)로 이동시켜 독립적으로 동작하도록 만들었습니다. API 수정이 필요한 추가 기능은 플러그인으로 분리하고, 사용자가 해당 기능을 활용하려면(가능하다면) 이 플러그인도 함께 설치하도록 권장하고 있습니다.

이 접근 방식의 유일한 문제는 코드를 공유하면서 API 수정이 필수적인 경우, 사용자가 두 구성 요소를 모두 설치하도록 해야 한다는 점입니다. 두 부분으로 나누는 것은 사람들이 여러분의 작업을 활용하기 위해 가장 편리한 방식이 아닐 수 있으므로, 결국 이러한 성격의 오픈소스 작업에는 단일 플러그인 설치가 여전히 최선의 방법이라고 생각합니다.

단, 여러분의 사이트에서만 사용할 것이라면 이 방식이 훌륭합니다!

네, 결국 단일 코드베이스가 필요한 상황이 분명히 있죠. 제가 깨달은 순간은, 최종적으로 단일 코드베이스를 원하더라도 프론트엔드 관련 코딩을 모두 테마 컴포넌트에서 하고, 그걸 작동시킨 다음에 플러그인으로 옮기면 된다는 점이었습니다. 조금 번거롭긴 하지만, 대부분의 시간을 테마 컴포넌트 워크플로우에서 코딩에 쏟고 있는 저에게는 전체적으로 훨씬 나은 방법입니다.