Дневники разработки #1: фундамент баз знаний сообщества

👋 Приветствую, друзья!

Активно работаю над базами знаний сообществ. В наш микросервисный стек добавились два новых сервиса: первый отвечает за экземпляры баз знаний сообществ, второй — за статьи внутри них. Технически ничего сложного: идейно они очень похожи на микросервис сообществ и микросервис постов.

✅ Функционально они уже готовы. Осталось докрутить пермишены, чтобы система прав и ролей работала корректно, добавить мелкие приятные штуки и подправить визуальные шероховатости. Всё основное уже на месте: статьи, версионирование, откаты к прошлым копиям, подключение внешних JS-библиотек в head.

🎨 В ходе разработки я немного переиграл принцип добавления кастомных JS-скриптов. Теперь при создании корневой категории базы знаний можно выбрать тематику — и все подкатегории внутри неё эту тематику наследуют. Именно тематика решает, какой JS-скрипт будет инжектиться в head. Сейчас вариантов два: без тематики либо World of Warcraft — тогда во всех статьях внутри категории и её подкатегорий в head появится скрипт wowhead. В будущем планирую новые тематики: Diablo, PoE2 и другие. Но на релизе будет только WoW или «без тематики».

🧩 Почему я ушёл от произвольных скриптов к фиксированным по тематике? Потому что под тематику подстраивается редактор статей. Выбрал WoW — получил готовые кастомные блоки: окно талантов персонажа, окно ротации, специальный разделитель и специальные табы. Не выбрал тематику — этих блоков в редакторе просто нет. В будущем у Diablo и PoE2 появятся свои блоки, заточенные под эти игры. Всё честно: тематика определяет и скрипты, и инструментарий автора.

🤔 Но главная цель этого поста — не отчёт о проделанной работе. Мне нужен ваш фидбек по вопросу, который я сам однозначно решить не могу. Речь о выборе движка рендера статей. Разберу три варианта, которые лежат на столе.

1️⃣ Обычный EditorJS — то, что работает прямо сейчас. Всё сохраняется в JSON, мы парсим его и рендерим на страницу. Плюсы: очень просто, понятный паттерн, статьи уже живут на нём, идеальное SEO. Минусы: это классический редактор для блогов. Форматирования немного, и для полноценной базы знаний с руководствами и документацией он, честно говоря, не сильно воодушевляет.

2️⃣ Quarkdown — «Markdown с суперсилами». Свежая typesetting-система, расширяющая CommonMark функциями, переменными и скриптингом. Поддерживает MathML для сложнейших формул, из одного источника собирает статьи, презентации и целые книги. SEO тоже в порядке. Но есть жирное «но»: написан на Kotlin и живёт на JVM, требуя Java 17+. Тащить Java в контейнер мне крайне не хочется, работать через CLI внутри контейнера — тоже, а прямой интеграции в наш Go-бэкенд не выйдет: придётся компилировать статьи через обёртки над CLI и JVM. Лицензия вроде нормальная, но когда-нибудь может выйти боком. Пахнет костылями.

3️⃣ Typst — ультимативное решение для документации. Современная сверхбыстрая система на Rust: компилирует в разы быстрее LaTeX, а по мощности не уступает ему, оставаясь при этом намного проще в освоении. Вёрстку можно выверять попиксельно: хоть десять колонок на страницу, хоть оформление как в глянцевом журнале, хоть работа всей жизни для Нобелевской премии. MathML на месте. Компилятор на Rust нативно ложится в наш стек: один микросервис статей на Rust — и он через gRPC прекрасно дружит с остальным Go-бэкендом. Минусы тоже весомые. Нативно Typst сохраняет в SVG, PDF и PNG — то есть SEO нет от слова совсем и никакой адаптивности под разные экраны. Есть официальный, но всё ещё экспериментальный экспорт в HTML: он живёт за feature flag, API может меняться, а вдобавок придётся писать огромное количество своих CSS-стилей под сгенерированную разметку и внимательно следить за безопасностью вывода. Поддерживать это будет непросто, пока всё не устаканится. Зато, выбрав Typst сейчас, в будущем мы можем выиграть очень сильно.

💭 Если честно, я склоняюсь к Typst. План такой: пишем микросервис рендера на Rust, делаем привычный режим написания статей с готовыми пресетами — пользователь просто пишет текст и может вообще не знать, что под капотом Typst. А рядом будет кнопка расширенного режима: уже не окно редактора статьи, а полноценный редактор кода с подсветкой синтаксиса Typst. Да, для рядового пользователя это порог входа. Но не все пользователи рядовые: многие с радостью разберутся, когда им дают такую возможность. А у остальных сегодня под рукой нейронки, которые отлично пишут Typst-разметку, — человеку останется только текст. Однако, объективно, это самый глупый вариант.

💬 Вот эти мысли по поводу ядра для статей я и хотел вынести на обсуждение. Мне правда интересно и важно услышать ваше мнение: какой вариант выбрали бы вы и почему? Быть может, я чего-то не учёл? Давайте обсудим — именно из таких разговоров и рождаются правильные решения.