Пример паттерна Fan-Out/Fan-In на Go с подробным описанием кода. Пример подходит для знакомства с паттерном в процессе обучения, собеседования, но не является шаблоном для production кода.

Пример паттерна Worker Pool на Go с подробным описанием кода. Пример подходит для знакомства с паттерном в процессе обучения, собеседования, но не является шаблоном для production кода.

О том, как сделать функцию main приложения на Go чистой, понятной, открытой для расширения.
Театр начинается с вешалки, а любая программа на Go - с функции main. Собственно, что может быть сложного и плохочитаемого в main, казалось бы? Но нет. На написание этой статьи меня сподвиг реальный кейс.

Мухи — отдельно, котлеты — отдельно. Отделяем Go-код от SQL-запросов. Зачем это делать и как?Личный опыт миграции большого проекта на новую СУБД показал: смешивание SQL с кодом приложения создаёт проблемы. Представляю простую библиотеку SQLSet для хранения именованных SQL-запросов в отдельных файлах.

Важность хорошей структуризации проекта могут недооценивать только совсем уж начинающие программисты. Сопровождение и развитие проекта с непродуманной структурой кода со временем превращается в сущий ад. Тут выплывают и проблемы со связанностью модулей и проблемы с плохой читабельностью и экспотенциально растущая трудоемкость развития проекта. Но всякая структура должна подчиняться некой логической концепции. И тут появляется великое поле для холиваров.

Доброго дня! Хочу поделиться лайфхаком по реализации универсального способа пагинации в произвольных запроса к БД для получания списков.

Имеем изначально задачу по реализации HTTP REST CRUD сервера на Go. База данных - PostgreSQL. Используемый драйвер - pgx - PostgreSQL Driver and Toolkit.

Задача в общем тривиальная - сделать так, чтоб запросы получали на вход параметры пагинации (номер страницы, количество записей на страницу) и отдавали на выход поля таблицы и общее доступное количество страниц.

Общее количество страниц в таблице БД получить несложно:

SQLite во многих случаях является удобным, незаменимым инструментом. Я уже не могу себе представить - как мы все жили без него. Тем не менее, есть некоторые неудобства при его использовании, связанные с тем, что это легкая встраиваемая СУБД.

Самое большое неудобство для меня, как Delphi-разработчика - отсутствие хранимых процедур. Я очень не люблю смешивать Delphi-код и SQL-скрипты. Это делает код намного менее читабильным, и затрудняет его поддержку.

Предлагаю свой вариант решения проблемы:

Выносим весь SQL-код в отдельный файл ресурсов, подключенный к проекту

Запросы в SQL-файле разделяем маркерами начала с идентификаторами и маркерами конца

Создаем класс - менеджер SQL-запросов. При загрузке приложения он читает SQL-файл из ресурсов и составляет из него список хранимых процедур.

В процессе работы приложения менеджер извлекает текст SQL-запроса по его идентификатору для последующей его передачи на выполнение