MetaORM — когда устал от ORM настолько, что написал свою 16 лет в разработке, 10 из них ежедневно с базами данных, и человек спокойно пишет, что путается в уровнях изоляции, не выучил расшифровку ACID и простой запрос с JOIN осиливает только через Гугл. За 7 лет коммерческой разработки сложный SQL-запрос не понадобился ни разу, а больше половины возможностей популярных ORM так и остались нетронутыми. Один и тот же кусок кода перекочёвывал из проекта в проект, пока не превратился в отдельный пакет. Внутри декларативные фильтры, генераторы стандартных CRUD-операций и тонкий слой транзакций через contextvars. Ни unit-of-work, ни identity map, ни ленивых прокси, ни магического отслеживания состояния объектов. Остаётся только то, с чем backend сталкивается каждый день, взять запись по идентификатору, отфильтровать список, обновить пару полей, создать сущность внутри транзакции. Посмотрим, что остаётся от ORM, когда убираешь из неё всё, чем не пользуешься.

Периодически на проектах возникает необходимость определить геолокацию пользователя по его IP. Например, узнать его страну, чтобы сменить линейку тарифов или учесть законодательство. Раньше мы пользовались базами MaxMind GeoIP. Их можно было выгрузить в виде MMDB-файлов, это такой формат, поддерживающий бинарный поиск по диапазонам IP. У них есть Lite версия, ее вполне хватало. Но сейчас, вижу, для использования нужна регистрация, а еще лучше - много денег в кассу. Еще один вариант - DB-IP, у них тоже есть Lite-версия. Причем базы можно скачать. Правда, лицензия там - Creative Commons Attribution, для использования в веб-приложениях нужно будет разместить ссылку на их сайт. Есть IP2Location, но там сразу цены конские. Можно работать с сервисами через API. Есть, скажем, IPinfo, онлайн, с бесплатным тарифом и рядом ограничений. Или вот IP-API. Отдают немало инфы. Но есть лимит в 45 запросов в минуту. И, понятно, в наше время нет гарантий трансграничной доступности сервиса. Ну а бесплатно можно скачать MMDB с вот этого сайта. Пишут, что не надо лицензий и ключей. Детализация только до уровня страны, город уже не найти. Но для многих случаев этого достаточно. Если используете что-то подобное, поделитесь. #tools

Веб-разработчики прекрасно знают HTTP-методы для взаимодействия клиента с сервером. Через GET обычно данные с сервера получают. Через POST можно создать или обновить. Удалять логично через DELETE. А вот HEAD, например, мы используем для проверки соединения, чтобы сэкономить трафик а теле запроса. Так вот, кто-то сидел и скучал о методе, который бы объединил GET и POST. Чтобы слать для запроса извлечения данных дополнительные параметры, скажем, фильтры, не в строке запроса, а в теле. Ну, типа мутант - GET-запрос с телом от POST. И придумали новый метод - QUERY. На эту тему даже сформировали отдельный RFC 10008 - The HTTP QUERY Method. То есть это как раз и получается идемпотентная операция запроса данных, аналогичная GET, но с телом POST, где вы можете слать тот же JSON с фильтрами и пагинацией. Подробности - в статье. #web

PostgreSQL для бэкендера: 10 фич, которыми мало пользуются, а зря В PostgreSQL уже хранятся пользователи, заказы и платежи, а потом стек начинает расти сам собой, когда рядом появляются Redis для очереди задач, отдельный Python-скрипт для дедупликации событий, Go-цикл, который считает интервалы между статусами заказа, свой поисковик вместо простого поиска по тексту и самодельная таблица locks для координации воркеров. Большая часть этой инфраструктуры дублирует то, что PostgreSQL умеет делать сам, причём атомарно, транзакционно и с индексами, без лишней сетевой болтовни между приложением и базой. Механизм, который снимает необходимость в отдельном брокере задач, живёт в PostgreSQL ещё с версии 9.5, просто про него редко вспоминают. Та же история с оконными функциями, полнотекстовым поиском и блокировками на уровне базы, где задачи, ради которых обычно поднимают отдельный сервис, часто закрываются прямо в таблице. Обсудим, сколько из этой цепочки сервисов держится просто на привычке.