js-библиотек для форматов Visio и Archi не встречал.
Если углубиться в сценарии - важно четко понять ценность таких решений, кому и для каких действий нужно. Несколько соображений:
С одной стороны, посмотреть в "одном окне" сборную солянку разных диаграмм может быть удобно. С другой, чтобы этим начали пользоваться, такой сервис должен быть действительно очень удобным, или как-то по-другому обеспечивать "выгоду" для потребителя по сравнению с использованием 2-3 разных инструментов для просмотра соответствующих типов диаграмм.
Моя практика показывает, что для задачи просмотра (потребители диаграмм - аналитики, разработчики, РП, ИБ итд) достаточно просто графического представления диаграммы + собрать (крайне желательно - автоматизированно) дополнительные текстовые/табличные представления под конкретную потребность.
При этом если идея глубже - не просто обеспечить просмотр отдельных диаграмм и их разрозненных метаданных, а как-то объединить это все в единый "архитектурный репозиторий", то здесь нужна общая метамодель под капотом, слой "адаптеров" для уже существующих форматов и т.д.
Если говорить про функцию редактирования, а не только просмотра, то тут еще бОльшие усложнения и целый ряд интересных челленджей
Но это именно viewer. Можно раскатить где-то у себя на сервере, чтобы все желающие потребители архитектурных диаграмм могли посмотреть сами диаграммы, прочитать свойства объектов.
Как у вас устроен процесс версионирования as is и to be? Когда нужно одновременно иметь 2 диаграммы - для текущей ситуации и для, скажем, планового длительного рефакторинга, по итогу которого будут существенные архитектурные изменения.
Про это и речь. Возможно, мне не хватает деталей для полной картины, но пока выглядит как неочевидный UX, если пользователю потребуется еще раз нажимать на кнопку "купить" уже после произведенной оплаты.
js-библиотек для форматов Visio и Archi не встречал.
Если углубиться в сценарии - важно четко понять ценность таких решений, кому и для каких действий нужно. Несколько соображений:
С одной стороны, посмотреть в "одном окне" сборную солянку разных диаграмм может быть удобно. С другой, чтобы этим начали пользоваться, такой сервис должен быть действительно очень удобным, или как-то по-другому обеспечивать "выгоду" для потребителя по сравнению с использованием 2-3 разных инструментов для просмотра соответствующих типов диаграмм.
Моя практика показывает, что для задачи просмотра (потребители диаграмм - аналитики, разработчики, РП, ИБ итд) достаточно просто графического представления диаграммы + собрать (крайне желательно - автоматизированно) дополнительные текстовые/табличные представления под конкретную потребность.
При этом если идея глубже - не просто обеспечить просмотр отдельных диаграмм и их разрозненных метаданных, а как-то объединить это все в единый "архитектурный репозиторий", то здесь нужна общая метамодель под капотом, слой "адаптеров" для уже существующих форматов и т.д.
Если говорить про функцию редактирования, а не только просмотра, то тут еще бОльшие усложнения и целый ряд интересных челленджей
Есть вариант со сборкой archi viewer в условиях пайплайна https://habr.com/ru/articles/583314/
Но это именно viewer. Можно раскатить где-то у себя на сервере, чтобы все желающие потребители архитектурных диаграмм могли посмотреть сами диаграммы, прочитать свойства объектов.
Какой у вас сценарий использования?
Модель использовал пару часов - ни разу oom не ловил
На
deepseek-r1:14bпо ощущениям проблема еще хуже. В одном ответе может 3+ языка встречатьсяПри запуске локально
deepseek-r1:32bв ответах периодически каша из языков:Пару раз китайские иероглифы добавил:
Только что запустил на 4080, утилизируется ~15800 MB
Как у вас устроен процесс версионирования as is и to be? Когда нужно одновременно иметь 2 диаграммы - для текущей ситуации и для, скажем, планового длительного рефакторинга, по итогу которого будут существенные архитектурные изменения.
Про это и речь. Возможно, мне не хватает деталей для полной картины, но пока выглядит как неочевидный UX, если пользователю потребуется еще раз нажимать на кнопку "купить" уже после произведенной оплаты.
По схеме возможна ситуация:
П.1 и 2 корректно отработали - пользователь выбрал товар, перешел на платформу, оплатил.
П.3 не отработал (по какой-то причине) - бэкенд вообще не узнает о попытке оплаты и ее результате со всеми вытекающими.
На схеме просто не отражено, или вы такие ситуации не учитываете?