wasm serait certainement exclu ici ; la charge utile serait beaucoup plus lourde. Il y a de nombreux problèmes de sécurité liés à son exécution correcte avec les CSP (et des préoccupations concernant les CORS). L’implémentation de markdown.it est extraordinairement rapide et extensible, permettant de nombreux plugins et bénéficiant d’un vaste écosystème existant.
Voici un peu plus de contexte sur mini_racer. Dès le jour 0 chez Discourse, nous avons insisté sur un pipeline unique pour traiter le markdown, ce qui a complètement éliminé une classe très problématique de bugs que j’avais rencontrés chez Stack Overflow, où le serveur et le client parlaient des dialectes légèrement différents. Pour Discourse, c’est encore plus important car les plugins peuvent modifier le pipeline. Par exemple :
est implémenté dans un plugin (analyse de [])
Nous bénéficions de plusieurs fonctionnalités « qualité de vie » en utilisant Unicorn et en nous appuyant sur le forking, voir :
En particulier, nous surveillons et gérons un processus fils Sidekiq depuis le processus maître.
Mais… Truffle n’a pas de GIL. Puma est déjà présent dans le Gemfile une fois que mini_racer fonctionne. Nous pourrions collaborer sur une configuration Truffle économe en mémoire qui maintient Sidekiq et Puma dans le même processus. Ou les utilisateurs pourraient simplement lancer un processus Sidekiq manuellement. Puma peut certainement fonctionner ; nous utilisons largement Rack.hijack, mais cela est déjà implémenté dans Puma, Unicorn et Passenger.