Так, а какой тезис мы обсуждаем? Если я правильно понял, идея в том, что при высоком тестовом покрытии можно вообще не использовать специализированные инструменты для кодогенерации и просто писать код через GPT?
Если да, то можно ли тогда отказаться, например, от protoc и просто генерировать всё через GPT? Или там почему-то подход с тестами уже не считается достаточным?
Просто интересно понять, где проходит грань между «давайте заменим специализированный инструмент на AI» и «ну тут всё же нужен формальный генератор».
Да, жпт может нагенерить код, но sqlc решает другую задачу — он гарантирует, что мои SQL-запросы точно соответствуют схеме БД, даёт мне строгую типизацию и убирает рутинный набор кода.
GPT напишет запрос, но не проверит его на ошибки, не встроится в CI/CD и не обеспечит безопасность типов. sqlc делает это автоматически и без магии.
SQLC поддерживает PostgreSQL, MySQL и SQLite, используя их нативные парсеры, но не пытается быть универсальным инструментом. Он хорошо работает с простыми и средними запросами, но сложные конструкции могут потребовать ручной доработки. Например, вызовы хранимых процедур не поддерживают автоматическое определение схемы результата, а динамические SQL-запросы вообще невозможны, кроме того, что я описал в статье. Для специфичных функций (unnest), JSON_TABLE) SQLC может неправильно определить возвращаемый тип, поэтому в таких случаях нужно либо использовать sqlc.embed, либо явно кастовать данные. В целом, инструмент ориентирован на статический SQL и ограничен его возможностями.
Я знаю, что я не пишу универсальные SQL-запросы и никуда не уйду в ближайшие годы с него, поэтому меня эта особенность не тяготит.
На меня повлияли следующие вещи: легкость развертывания, исходный код на go, консультация с авторами Temporal и разработчиком, который внедрял Temporal, скорость написания кода.
Camunda выглядела довольно энтерпрайзной и мне показалось, что я не осилю все то, что нужно для того, чтобы затащить order processing на camunda за 2 месяца, а сроки очень горели.
У нас разделено на несколько репозиториев, но самый большой называется oms и он содержит 5 workflow, отдельно есть еще репозиторий с логистическими заказами и у них своих workflow, которые общаются с нами через temporal. Каждый workflow с его activity имеет отдельный воркер и каждый воркер имеет свой собственный деплоймент в кубе.
Если бы я делал сейчас заново работу с temporal, то я бы каждый воркер выносил в отдельный репозиторий, а сами рабочие процессы бы описывал с помощью proto-файлов и генерил бы весь код и скелет рабочего процесса через https://github.com/cludden/protoc-gen-go-temporal.
Мы не рассматривали службы AWS или других облачных платформ при проектировании, поэтому не могли на них завязываться. Если быть честным, то при старте разработки мы рассматривали только три варианта:
Так, а какой тезис мы обсуждаем? Если я правильно понял, идея в том, что при высоком тестовом покрытии можно вообще не использовать специализированные инструменты для кодогенерации и просто писать код через GPT?
Если да, то можно ли тогда отказаться, например, от protoc и просто генерировать всё через GPT? Или там почему-то подход с тестами уже не считается достаточным?
Просто интересно понять, где проходит грань между «давайте заменим специализированный инструмент на AI» и «ну тут всё же нужен формальный генератор».
Да, жпт может нагенерить код, но sqlc решает другую задачу — он гарантирует, что мои SQL-запросы точно соответствуют схеме БД, даёт мне строгую типизацию и убирает рутинный набор кода.
GPT напишет запрос, но не проверит его на ошибки, не встроится в CI/CD и не обеспечит безопасность типов. sqlc делает это автоматически и без магии.
SQLC поддерживает PostgreSQL, MySQL и SQLite, используя их нативные парсеры, но не пытается быть универсальным инструментом. Он хорошо работает с простыми и средними запросами, но сложные конструкции могут потребовать ручной доработки. Например, вызовы хранимых процедур не поддерживают автоматическое определение схемы результата, а динамические SQL-запросы вообще невозможны, кроме того, что я описал в статье. Для специфичных функций (unnest), JSON_TABLE) SQLC может неправильно определить возвращаемый тип, поэтому в таких случаях нужно либо использовать sqlc.embed, либо явно кастовать данные. В целом, инструмент ориентирован на статический SQL и ограничен его возможностями.
Я знаю, что я не пишу универсальные SQL-запросы и никуда не уйду в ближайшие годы с него, поэтому меня эта особенность не тяготит.
На меня повлияли следующие вещи: легкость развертывания, исходный код на go, консультация с авторами Temporal и разработчиком, который внедрял Temporal, скорость написания кода.
Camunda выглядела довольно энтерпрайзной и мне показалось, что я не осилю все то, что нужно для того, чтобы затащить order processing на camunda за 2 месяца, а сроки очень горели.
Да, все верно :)
У нас разделено на несколько репозиториев, но самый большой называется oms и он содержит 5 workflow, отдельно есть еще репозиторий с логистическими заказами и у них своих workflow, которые общаются с нами через temporal. Каждый workflow с его activity имеет отдельный воркер и каждый воркер имеет свой собственный деплоймент в кубе.
Если бы я делал сейчас заново работу с temporal, то я бы каждый воркер выносил в отдельный репозиторий, а сами рабочие процессы бы описывал с помощью proto-файлов и генерил бы весь код и скелет рабочего процесса через https://github.com/cludden/protoc-gen-go-temporal.
Мы не рассматривали службы AWS или других облачных платформ при проектировании, поэтому не могли на них завязываться. Если быть честным, то при старте разработки мы рассматривали только три варианта:
Camunda
Temporal
Свое решение с PG и Kafka