Если бы делал новый проект с нуля — смотрел бы на задачу:
— если куча интеграций, сложная бизнес-логика, нужны чёткие валидации и привычная JVM-инфраструктура — Kotlin отлично подойдёт, особенно если команда уже с ним работает.
— если хочется real-time, WebSocket, минимальные ресурсы и чтобы быстро собрать и запустить — Go может быть удобнее.
Spring Boot — мощный, но часто тянет за собой много всего: автоконфигурации, DI, аннотации. Это круто, когда проект большой, но на старте может быть тяжеловато.
В Go всё проще: один бинарник, запустил и работает, ничего лишнего не надо.
По async тоже своя история: в Kotlin корутины довольно управляемые, меньше шансов облажаться. В Go синтаксис проще, но если не аккуратно — можно нарваться на гонки или утечки.
Так что выбор — это не про «что лучше», а про задачи, окружение и то, как тебе удобнее работать.
Справедливо подмечено — REST всё же стиль, а не конкретный протокол. Я в статье больше про "типичное" REST API на HTTP, где запрос — ответ и всё. Но да, формулировку стоило бы уточнить, чтобы не путать архитектуру с реализацией. Спасибо, что поправили.
Спасибо за развёрнутый и точный комментарий — особенно ценно, что подметил сильные стороны JVM: AOT, CDC, виртуальные потоки, тестируемость. Всё так и есть — сейчас с этим действительно удобно жить. Полностью согласен, что Spring Boot отлично подходит для прокси-сервисов, особенно когда важна скорость разработки и зрелость экосистемы.
Но тут история была не про замену, а про попробовать другой стек на реальном проекте. Хотелось посмотреть, как Go поведёт себя с WebSocket, стримингом, CI/CD и в целом в продакшене. Планирую сделать сквозное нагрузочное тестирование и сравнить, как чувствуют себя корутины и горутины под нагрузкой.
Ну и в целом — если бы я шёл только от здравого смысла и плюшек JVM, этой статьи бы не появилось. Иногда надо просто сделать шаг в сторону, чтобы прочувствовать всё на практике.
Спасибо! Да, мобайл звучит разумно — особенно если появится реальный кейс. Пока приоритет — добить роли, метрики, стабильность. А там посмотрим, будет время — расширим.
Справедливое замечание. Сейчас проект использует OpenAI API как наиболее доступное и мощное решение для генерации ответов — в том числе ради эксперимента и быстрого старта.
Но архитектура чата построена таким образом, что модель можно заменить — например, на свою LLM, развернутую локально или в изолированном контуре. Для этого достаточно адаптировать один сервис, отвечающий за генерацию ответов. Возможность полного контроля над обработкой данных — как раз один из аргументов в пользу собственной модели.
Кстати, на Хабре действительно есть отличные статьи про развертывание LLM в закрытом контуре — рекомендую.
Kotlin остаётся моим основным рабочим инструментом в финтехе, где важна совместимость с существующим Java-стеком и зрелая экосистема.
Go в этом проекте — способ расширить экспертизу и сравнить, как в реальных условиях ведут себя корутины и горутины: по стабильности, масштабируемости, отладке и поведению под нагрузкой. Особенно интересно было протестировать асинхронную работу с OpenAI через стриминг токенов — в Go с горутинами и каналами это реализуется довольно естественно, без дополнительных библиотек.
В дальнейшем хочу продолжить развивать тему — уже с акцентом на производительность, профилирование и реальные сценарии.
Спасибо, что прочитал и за замечание. Вижу, что пользователи хотят больше технических подробностей(название ввело в заблуждение). Не хочется, чтобы «много-букав» превращались в гайд и код-ревью. В общем буду работать над материалом лучше.
Если бы делал новый проект с нуля — смотрел бы на задачу:
— если куча интеграций, сложная бизнес-логика, нужны чёткие валидации и привычная JVM-инфраструктура — Kotlin отлично подойдёт, особенно если команда уже с ним работает.
— если хочется real-time, WebSocket, минимальные ресурсы и чтобы быстро собрать и запустить — Go может быть удобнее.
Spring Boot — мощный, но часто тянет за собой много всего: автоконфигурации, DI, аннотации. Это круто, когда проект большой, но на старте может быть тяжеловато. В Go всё проще: один бинарник, запустил и работает, ничего лишнего не надо.
По async тоже своя история: в Kotlin корутины довольно управляемые, меньше шансов облажаться. В Go синтаксис проще, но если не аккуратно — можно нарваться на гонки или утечки. Так что выбор — это не про «что лучше», а про задачи, окружение и то, как тебе удобнее работать.
Справедливо подмечено — REST всё же стиль, а не конкретный протокол. Я в статье больше про "типичное" REST API на HTTP, где запрос — ответ и всё. Но да, формулировку стоило бы уточнить, чтобы не путать архитектуру с реализацией. Спасибо, что поправили.
Спасибо за развёрнутый и точный комментарий — особенно ценно, что подметил сильные стороны JVM: AOT, CDC, виртуальные потоки, тестируемость. Всё так и есть — сейчас с этим действительно удобно жить. Полностью согласен, что Spring Boot отлично подходит для прокси-сервисов, особенно когда важна скорость разработки и зрелость экосистемы.
Но тут история была не про замену, а про попробовать другой стек на реальном проекте. Хотелось посмотреть, как Go поведёт себя с WebSocket, стримингом, CI/CD и в целом в продакшене. Планирую сделать сквозное нагрузочное тестирование и сравнить, как чувствуют себя корутины и горутины под нагрузкой.
Ну и в целом — если бы я шёл только от здравого смысла и плюшек JVM, этой статьи бы не появилось. Иногда надо просто сделать шаг в сторону, чтобы прочувствовать всё на практике.
Спасибо! Рад, что было полезно.
Спасибо! Да, мобайл звучит разумно — особенно если появится реальный кейс. Пока приоритет — добить роли, метрики, стабильность. А там посмотрим, будет время — расширим.
Интересно было читать. Статья вдохновила на безопасность)
Справедливое замечание. Сейчас проект использует OpenAI API как наиболее доступное и мощное решение для генерации ответов — в том числе ради эксперимента и быстрого старта.
Но архитектура чата построена таким образом, что модель можно заменить — например, на свою LLM, развернутую локально или в изолированном контуре. Для этого достаточно адаптировать один сервис, отвечающий за генерацию ответов. Возможность полного контроля над обработкой данных — как раз один из аргументов в пользу собственной модели.
Кстати, на Хабре действительно есть отличные статьи про развертывание LLM в закрытом контуре — рекомендую.
Спасибо, что читаете.
Kotlin остаётся моим основным рабочим инструментом в финтехе, где важна совместимость с существующим Java-стеком и зрелая экосистема.
Go в этом проекте — способ расширить экспертизу и сравнить, как в реальных условиях ведут себя корутины и горутины: по стабильности, масштабируемости, отладке и поведению под нагрузкой. Особенно интересно было протестировать асинхронную работу с OpenAI через стриминг токенов — в Go с горутинами и каналами это реализуется довольно естественно, без дополнительных библиотек.
В дальнейшем хочу продолжить развивать тему — уже с акцентом на производительность, профилирование и реальные сценарии.
Большое спасибо за такую подробную и интересную статью. Подчеркнул для себя несколько идей)
Спасибо, что прочитал и за замечание. Вижу, что пользователи хотят больше технических подробностей(название ввело в заблуждение). Не хочется, чтобы «много-букав» превращались в гайд и код-ревью. В общем буду работать над материалом лучше.