네, 저쪽은 제가 신경 쓰고 있습니다. 다만, 몇 가지 다른 라이브러리(byebug, ruby-prof, better_errors, rbtrace, gc_tracer, stackprof, memory_profiler)는 어떻게 해야 할지 확신이 서지 않습니다. 어떻게 처리해야 하나요?
그리고 다음 이슈로 인해 mini_racer가 작동할 때까지 truffle은 완전히 막혀 있는 상태입니다:
unicorn은 fork에 의존하기 때문에 TruffleRuby에서는 작동하지 않을 가능성이 높지만, 실제로는 설치됩니다.
Discourse를 Puma에서 실행할 수 있으며, 이를 위해 필요한 설정이 있나요?
확신이 안 서서 남겨둔 것들이 몇 더 있는데, 어떻게 처리해야 하나요? (byebug, ruby-prof, better_errors, rbtrace, gc_tracer, stackprof, memory_profiler)
네, 그것들은 모두 MRI에 매우 특화되어 있습니다(다른 백엔드를 지원하기 시작할 때까지). 따라서 당분간 platforms: :mri로 설정하는 것이 좋습니다. better_errors는 작동할 수 있지만, binding_of_caller는 아직 TruffleRuby를 지원하지 않습니다.
이러한 gems는 대부분 앱 실행에 필수적이지 않은 디버깅/성능 도구로 보입니다.
네, mini_racer를 살펴봐야 합니다.
참고로, 왜 마크다운 렌더링에 JS를 사용하는지 궁금합니다.
클라이언트 브라우저에서 실행될 때와 정확히 동일한 결과를 보장하기 위해서인가요?
wasm은 여기서 확실히 배제되어야 합니다. 페이로드가 훨씬 더 커질 것이며, CSP(콘텐츠 보안 정책)와 함께 올바르게 실행되도록 하는 데 관련된 보안 문제가 산더미처럼 많습니다(또한 CORS 문제도 있습니다). markdown.it의 구현은 놀라울 정도로 빠르고 확장성이 좋아 수많은 플러그인을 지원하고 거대한 기존 생태계를 갖추고 있습니다.
mini_racer에 대해 조금 더 맥락을 설명하자면. Discourse에서 우리는 0일차부터 마크다운을 처리하는 단일 파이프라인을 고집해 왔습니다. 이는 Stack Overflow에서 경험했던, 서버와 클라이언트가 약간 다른 변형을 사용하는 매우 까다로운 유형의 버그를 완전히 제거했습니다. Discourse의 경우 플러그인이 파이프라인을 수정할 수 있기 때문에 이 점이 더욱 중요합니다. 예를 들어:
은 플러그인에서 구현됩니다([]의 파싱)
우리는 unicorn을 사용하고 포킹(forking)에 의존함으로써 얻는 몇 가지 “품질 향상” 기능이 있습니다. 관련 내용은 다음을 참조하세요:
특히 마스터 프로세스에서 sidekiq 자식 프로세스를 모니터링하고 관리합니다.
하지만… truffle에는 GIL이 없으며, mini_racer가 작동하게 되면 puma는 이미 Gemfile에 있습니다. sidekiq과 puma를 동일한 프로세스에 유지하면서 메모리를 절약하는 truffle 설정을 함께 작업할 수 있습니다. 또는 사람들이 단순히 수동으로 sidekiq 프로세스를 시작할 수도 있습니다. Puma는 확실히 작동할 것이며, 우리는 Rack.hijack을 광범위하게 사용하지만 이는 이미 Puma/Unicorn/Passenger 전체에 걸쳐 구현되어 있습니다.