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 전체에 걸쳐 구현되어 있습니다.