Comments 17
В итоге про Go только 1% статьи, остальное про CI/CD, Docker, GPT (?) - в общем, про вещи с заявленной темой не связанные...
Наблюдал как из каждой радиоточки было педалирование Котлина, теперь такой свитчинг в другие языки...
Спасибо, что читаете.
Kotlin остаётся моим основным рабочим инструментом в финтехе, где важна совместимость с существующим Java-стеком и зрелая экосистема.
Go в этом проекте — способ расширить экспертизу и сравнить, как в реальных условиях ведут себя корутины и горутины: по стабильности, масштабируемости, отладке и поведению под нагрузкой. Особенно интересно было протестировать асинхронную работу с OpenAI через стриминг токенов — в Go с горутинами и каналами это реализуется довольно естественно, без дополнительных библиотек.
В дальнейшем хочу продолжить развивать тему — уже с акцентом на производительность, профилирование и реальные сценарии.
Странно читать про защищенность данных пользователей, когда все данные из чата улетают за бугор в прямом эфире.
Справедливое замечание. Сейчас проект использует OpenAI API как наиболее доступное и мощное решение для генерации ответов — в том числе ради эксперимента и быстрого старта.
Но архитектура чата построена таким образом, что модель можно заменить — например, на свою LLM, развернутую локально или в изолированном контуре. Для этого достаточно адаптировать один сервис, отвечающий за генерацию ответов. Возможность полного контроля над обработкой данных — как раз один из аргументов в пользу собственной модели.
Кстати, на Хабре действительно есть отличные статьи про развертывание LLM в закрытом контуре — рекомендую.
Красавчик. Чувствуется системный подход и работа в Энтерпрайзе. Была та же идея год назад написать проксирующий сервис для различных моделей, но 100500 причин не дали. Рекомендация - предусмотреть возможность расширения решения на мобайл
Спасибо! Да, мобайл звучит разумно — особенно если появится реальный кейс. Пока приоритет — добить роли, метрики, стабильность. А там посмотрим, будет время — расширим.
Основательная статья. Мне понравилось. Почерпнул некоторые вещи, например про Portainer.
так на spring boot такие же приложения точно так же компилируются сек за 5 и запускаются за 2. + вроде если докер контейнер собираешь, то он умеет еще и aot-cdc прогнать чтоб на проде ускорить запуск с этим профилем еще на 40%, при этом вам руками ничего делать не надо. учитывая, что ваш сервер это прокси между gpt и юзером то можно одной строчкой включить виртуальные потоки и обрабатывать тысячи тысяч параллельных запросов. + вы получаете все плюшки спринг бута в виде удобного тестирования всех уровней. из плюсов go только то что он сильно меньше памяти кушает в сравнении с приложениями такого же (малого) функционала. горутины прикольно, но насколько понимаю можно с каналами накосячить и получить разные проблемы - следовательно под это желательно иметь тесты. в общем если у вас дохлая vps и вы хотите запустить на ней все ваши pet проекты в количестве 10 штук - норм, в остальном сомнительная замена. В принципе если сильно хочется то можно и graalvm заюзать и точно так же собрать exe с сильно меньшим потреблением памяти, но мне было бы лень без острой необходимости ждать пока это скомпилируется и резолвить проблемы, хотя опять-таки, для вашего случая наверно все заработает сразу и дополнительно для нативного имиджа ничего делать не придется. В общем я фишку го не выкупаю, я хочу язык с большим количеством крутых фич на котором я минимальным кодом буду делать много. Ну а так сэкономлю я 250 мб памяти (в лучшем случаи), но сейчас разве это проблема? Вроде как за компьют деньги просят.
Спасибо за развёрнутый и точный комментарий — особенно ценно, что подметил сильные стороны JVM: AOT, CDC, виртуальные потоки, тестируемость. Всё так и есть — сейчас с этим действительно удобно жить. Полностью согласен, что Spring Boot отлично подходит для прокси-сервисов, особенно когда важна скорость разработки и зрелость экосистемы.
Но тут история была не про замену, а про попробовать другой стек на реальном проекте. Хотелось посмотреть, как Go поведёт себя с WebSocket, стримингом, CI/CD и в целом в продакшене. Планирую сделать сквозное нагрузочное тестирование и сравнить, как чувствуют себя корутины и горутины под нагрузкой.
Ну и в целом — если бы я шёл только от здравого смысла и плюшек JVM, этой статьи бы не появилось. Иногда надо просто сделать шаг в сторону, чтобы прочувствовать всё на практике.
REST — это хорошо для запросов с мгновенным результатом.
REST - это вообще ни разу не про протокол взаимодействия. REST - это унифицированный набор правил для каждой конкретной системы; архитектурный стиль, если угодно. REST вполне себе может быть не поверх HTTP реализован.
Хочу спросить, есть ли выигрыш именно в программировании проекта на Go по сравнению с использованием Kotlin? В новом проекте Вы бы что стали использовать?
Если бы делал новый проект с нуля — смотрел бы на задачу:
— если куча интеграций, сложная бизнес-логика, нужны чёткие валидации и привычная JVM-инфраструктура — Kotlin отлично подойдёт, особенно если команда уже с ним работает.
— если хочется real-time, WebSocket, минимальные ресурсы и чтобы быстро собрать и запустить — Go может быть удобнее.
Spring Boot — мощный, но часто тянет за собой много всего: автоконфигурации, DI, аннотации. Это круто, когда проект большой, но на старте может быть тяжеловато. В Go всё проще: один бинарник, запустил и работает, ничего лишнего не надо.
По async тоже своя история: в Kotlin корутины довольно управляемые, меньше шансов облажаться. В Go синтаксис проще, но если не аккуратно — можно нарваться на гонки или утечки. Так что выбор — это не про «что лучше», а про задачи, окружение и то, как тебе удобнее работать.
Все сообщения, которые отправляются через чат — и от пользователя, и от AI — сохраняются в базу в хешированном виде (через SHA-256).
Поскольку содержимое сообщений хранится в базе в хешированном виде, обычный поиск по тексту невозможен.
Кажется, с таким же успехом сообщения можно было и не сохранять
Как я ушёл с Kotlin (Spring Boot) на Go (Gin) и сделал AI-чат с WebSocket и GPT-4