Хорошо спроектированные и качественно документированные API — это удовольствие в работе.

Сегодня индустриальным стандартом де-факто стал OpenAPI, который предлагает методологию: сначала проектируем интерфейс API, а уже потом строим вокруг него остальную систему. Такой подход помогает сделать API понятным, стабильным и удобным для всех участников разработки.

Генератор в Go позволяет асинхронно обрабатывать данные без перегрузки памяти. Разбираем основы работы.

Статья объясняет горутины и каналы в Go с наглядными визуализациями, показывая, как они работают и взаимодействуют для конкурентности.

Когда я присоединяюсь к новой компании, меня часто посещает синдром самозванца. После всех этих собеседований кажется, что парни знают, что делают и я смиренно настравиаюсь учиться у лучших.

Однажды, я столкнулся с инцидентом на проде и обратился за помощью к самому опытному инженеру. Он пришел на помощь и с легкостью изменил значение в БД с помощью... ручного обновления. 🤯 Проблема заключалась в том, что набор SQL-обновлений не был выполнен внутри транзакции.

Работа в новой компании — это всегда увлекательно. Я осознал, что даже если какой-то аспект кажется простым, например, SQL-транзакции, его легко упустить из виду.

SQL кажется чем-то, что мы все хорошо знаем, и мало чем может удивить. (Ему уже 50 лет!) Возможно, пришло время пересмотреть подходы, так как мы уже прошли фазу хайпа по поводу NoSQL, и снова возвращаемся к “используйте просто Postgres”, а иногда и к “SQLite тут за глаза”.

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

Основной принцип многослойной архитектуры заключается в разделении критически важных частей кода (логики) от деталей реализации (например, SQL-запросов). Одним из способов достижения такого разделения является паттерн «Репозиторий». Однако, наиболее сложным аспектом такой архитектуры является обработка транзакций.

В какой-то момент моей карьеры меня перестало радовать ПО которое я разрабатывал.

Больше всего мне нравилось работать с низкоуровневыми деталями и сложными алгоритмами. Но после перехода на пользовательские приложения эта часть работы почти исчезла. Теперь программирование казалось мне просто перемещением данных из одного места в другое с помощью уже готовых библиотек и инструментов. Знания, которые я получил раньше о программном обеспечении, уже не были такими полезными.

В процессе работы с Go я столкнулся с ещё одной проблемой — обработкой ошибок в хендлерах. Как можно сделать этот процесс удобным и эффективным для 150+ обработчиков? Как обеспечить консистентность и поддержку при обработке ошибок?

Разумеется, мои поиски палочки-выручалочки закончились ничем, хочется чтобы бум и все готово. Есть протокол RFS7807, есть библиотека, есть масса противоречивых статей. По существу статья ниже полностью не отвечает на все, но в ней есть позиция и предложено решение, и я думаю, это решение может быть полезным. Статья лишь повод/предложение поделиться вашими примерами успешных кейсов.

Собственно, статья, приятного прочтения.

Недавно мы столкнулись с необходимостью найти библиотеку для удобной работы с базами данных. В проекте было принято решение не использовать ORM, а вместо этого применить миграции. Так как я работал только с ORM, мне, как и автору статьи, было мало знакомо понятие миграций баз данных. В поисках информации о миграциях и популярных решениях, я наткнулся на эту статью. Перевод статьи я оставил ниже. Возможно, она будет вам полезна. Буду признателен, если вы сможете поделиться библиотеками, которые используете.

Перед вами перевод статьи автора Doug Bridgens, в которой он рефлексирует свой опыт и критически отзывается о Agile. В его статье совсем нет анализа и аргументации, это личные размышления на тему конкретного разработчика.

Это мой второй перевод и я позволю себе в этом предисловии пару предложений о том, зачем я потратил свое время на этот перевод:

Это перевод одноименной статьи.

Базовое использование

Сериализации JSON в Go

В стандартном пакете encoding/json присутствуют механизмы сериализации marshaling и десериализации unmarshaling JSON.

Пример: