Комментарии 2
Не хочу кидать палку. Но на streamlit не стоит писать высоконагруженные интерфейсы, хотябы по причине, что это медленный python кушающий много ОЗУ. Я конечно понимаю, что вы привыкли писать на нем скриптики, так как вы DevOps. Но по факту использования такого конструктора интерфейса, все превращается в будущую боль. Хоть вы и говорите, что красота это якобы техдолг. Но если у вас готовый конструктор компонентов, то техдолга нету. Вам же только панели управления нужны и мониторинга, для такого есть море библиотек. Также вы сами написали, что для обеспечения контролируемого доступа требуются дополнительные сервисы, что приведет к повышению потребления ОЗУ. И тут у нас уже потребление ОЗУ будет как атомный реактор. Хотелось бы примеров как вы проводите бенчмарки в своей компании при одновременном использовании единой панели на этом фреймворке. Так думаю будет более честно, чем говорить как весело пилить на нем интерфейсы. Если вы позиционируете такое решение только для малых команд, то хотелось бы, чтобы вы использовали все методы оптимизации на python, использовали .so библиотеки и использовали cython, как более эффективную альтернативу. Не знаю ваших скиллов поэтому можете считать это как предложения для следующих статей. И еще htop вставлять как факт достоверности не помешало бы.
Цель статьи была поделиться классным инструментом, который смотивировал меня самого к дальнейшему изучению python и инструментов для фронта. Плюс, как база для MVP streamlit, как мне кажется, довольно хорош из-за своей простоты. Или, например, как первая точка входа для человека, не знакомого с фронтом - помогает постепенно вкатиться во что-то более продвинутое.
Если вы позиционируете такое решение только для малых команд
Основное применение вижу в первую очередь для быстрого прототипирования или даже MVP, внутренних инструментов и тп в любых командах. А память…
Цена за простые GUI

Бенчмарки на будущее учту, спасибо за обратную связь!

Streamlit для внутренних GUI: быстрый и гибкий low-code инструмент