Этот GitHub-репозиторий выглядит просто дико

Это огромная подборка из 2600+ API для скрейпинга, с помощью которых можно вытаскивать данные с сайтов, соцсетей, e-commerce-платформ и много чего ещё.

👉 @BackendPortal

Бесплатный API для определения геолокации по IP-адресу.

Безлимитные запросы и без регистрации.

→ ip․guide

Подходит для JavaScript, Python, PHP и любого другого языка.

👉 @BackendPortal

Правила выбора структур данных:

* Небольшие коллекции (<100) → линейный проход быстрее HashMap
(хэш + лишняя индирекция дороже, чем O(n))

* В основном чтение, записи редкие → иммутабельные структуры
(JIT оптимизирует, нет рехэша, проще рассуждать о коде)

* Высокая частота записей → избегай отсортированных структур
(ротации деревьев добавляют скрытую стоимость)

* Порядок нужен только на выходе → храни без порядка, сортируй при чтении
(одна сортировка дешевле, чем поддерживать порядок всегда)

* Частые итерации → оптимизируй локальность памяти
(arrays > ArrayList > HashMap > TreeMap)

* Hot path → избегай полиморфных структур
(виртуальные вызовы мешают инлайнингу)

* Стабильные ключи → заранее агрессивно задавай размер HashMap
(resize = всплеск латентности)

* Разреженные числовые ключи → массивы лучше мап
(смещение по индексу быстрее хэширования)

* Плотные enum-ключи → EnumMap
(реализация на массиве, без хэширования)

* Нужны и membership, и порядок → LinkedHashSet
(платишь памятью, но избегаешь TreeSet)

👉 @BackendPortal

SQL-совет: как работает ORDER BY с несколькими колонками

Когда в запросе используется ORDER BY с несколькими полями, база сначала сортирует весь результат по первой колонке (в примере — sales).
Так формируются группы строк с одинаковым значением первичного поля, например все строки с sales = 12000.

Дальше включается вторичная сортировка (age ASC).
Она применяется не ко всей таблице, а только внутри этих групп.

В результате видно, что строки с одинаковым sales стоят рядом.
Например, Mira и Bob сгруппированы вместе, потому что у них одинаковые продажи (12000).
Первичная сортировка по sales DESC дала равенство, и тут в дело вступает второе поле.

Так как сортируем по age по возрастанию, Mira (30) идет перед Bob.

То же самое происходит для всех значений, которые совпали в первой сортировке:
каждое следующее поле в ORDER BY работает как тай-брейкер для предыдущего.

👉 @BackendPortal

Сгенерируй headless-бэкенд для e-commerce за считанные секунды 🤯

Есть open-source проект Storecraft, который позволяет быстро поднять полностью AI-управляемый бэкенд интернет-магазина. Ты сам выбираешь стек, базу данных и все необходимые компоненты.

👉 @BackendPortal

Что общего у Git, Cursor и Dynamo?

Деревья Меркла.

Это отличная структура данных для отслеживания изменений файлов и инкрементальной синхронизации с удалёнными серверами.

Допустим, мы хотим отслеживать изменения кодовой базы на уровне отдельных файлов. Для каждого исходного файла считается хеш — это будут листья дерева.

Дальше строится дерево по структуре директорий. Хеш родительского узла — это хеш от конкатенации хешей всех его дочерних узлов. Хеши внутренних узлов зависят от данных или хешей всех их потомков. В итоге всё сходится в корневой узел, хеш которого зависит от ВСЕХ отслеживаемых исходников.

Если изменить один файл, изменения хеша прокатятся вверх по дереву вплоть до корня.

При синхронизации локальных изменений с удалённым сервером (например, в Git) можно быстро понять, были ли изменения, просто сравнив корневой хеш клиента и сервера. Если они отличаются, дерево обходится вниз, пока не будут найдены листья с изменениями, и пересинхронизировать нужно только эти файлы.

В итоге получаем быстрое обнаружение изменений (O(log n)) и экономию трафика, потому что мы пересылаем только те файлы, которые точно были изменены.

👉 @BackendPortal

Нашли способ быстро превратить уже существующую БД в наглядную админ-панель: basemulti

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

Доступны варианты локального деплоя и деплоя в Vercel в один клик. 👏

👉 @BackendPortal

Лучшая альтернатива POSTMAN получила новую версию

Bruno это минималистичный и опенсорсный API-клиент

✓ без проблем с приватностью
✓ коллекции можно синкать через Git
✓ есть Windows, Linux и macOS сборки

→ usebruno․com

👉 @BackendPortal

в Postgres 18 появился новый возвращаемый полеcет для OLD и NEW данных. куча прикладного кода зависит от того чтобы вставить данные и сразу знать старое и новое состояние. теперь можно сразу подтверждать INSERT и UPDATE без лишних костылей.

👉 @BackendPortal

Нашли офигенный способ выучить PostgreSQL в браузере : crunchydata

PostgreSQL-песочница с практическими уроками SQL, транзакциям, индексам, PostGIS и не только

🛌

👉 @BackendPortal

Сборник документации множества языков программирования, библиотек и фреймворков в одном интерфейсе

Экономим время ✌️

👉 @BackendPortal

Бэкапит базы на несколько хранилищ сразу, плюс умеет присылать нотификации.

https://github.com/RostislavDugin/postgresus

👉 @BackendPortal

Эта open-source система для управления проектами реально впечатляет

Работает через веб, бесплатная и закрывает весь базовый набор: планирование, задачи, таймлайны, прогресс команды.

Если нужен мощный PM-инструмент без дорогих SaaS — стоит глянуть :)

👉 @BackendPortal

R-trees это мощная структура для индексации геометрических данных.

Их используют в MySQL, а Postgres применяет похожий на R-tree подход через GiST в PostGIS.

По сути они работают похоже на B-tree: это древовидная структура, где на каждом узле страницы хранится несколько записей. Такой дизайн держит дерево неглубоким и позволяет эффективно искать миллионы элементов на диске. Данные обычно лежат только в листьях, как у B+tree.

Записи в R-tree это ограничивающие прямоугольники. Сами геометрические фигуры обычно сложнее прямоугольников, поэтому на уровне листьев хранят минимальный ограничивающий прямоугольник (MBR) для каждой фигуры, плюс ссылку на полную геометрию, которая лежит отдельно на диске. Родительский узел для листового MBR хранит прямоугольник, который полностью покрывает все дочерние.

Чем выше по дереву, тем больше становятся bounding-прямоугольники. В корне обычно остаётся несколько больших bounding-боксов.

Ключевое отличие от B-tree: поиск одного прямоугольника может потребовать обхода нескольких путей в дереве. В идеале B-tree даёт O(log n) на поиск, но из-за перекрытий у R-tree худший случай может быть O(n).

R-tree также можно использовать в 3D и выше, обобщая ту же идею ограничивающих регионов.

👉 @BackendPortal

Автоматизация рабочих процессов с мониторингом серверов: xyops

👉 @BackendPortal

PostgreSQL позволяет клонировать базу на 6 ГБ за 212 миллисекунд вместо 67 секунд. Вот как это работает.

Клонирование баз данных полезно в нескольких сценариях:

* тестирование миграций без трогания продакшн-данных
* поднятие свежих копий под каждый прогон тестов
* сброс sandbox-окружения между сессиями
* воспроизводимые снапшоты для отладки

Когда база весит несколько мегабайт, pg_dump вполне справляется. Но когда речь идёт о сотнях гигабайт, «просто сделать копию» превращается в серьёзный узкий момент.

В PostgreSQL система шаблонов была всегда. Каждый CREATE DATABASE тихо клонирует template1 под капотом, и вместо template1 можно использовать любую базу.

В версии 15 появился параметр STRATEGY, и по умолчанию включили WAL_LOG — поблочное копирование через журнал предзаписи (WAL). I/O становится ровнее, но для больших баз это медленнее.

В PostgreSQL 18 появилась опция file_copy_method = clone. На современных файловых системах вроде XFS, ZFS или APFS она использует операцию FICLONE. Вместо копирования байтов файловая система создаёт новые метаданные, которые указывают на те же физические блоки. Обе базы используют одно и то же хранилище, пока вы ничего не меняете.

Всю магию здесь делает файловая система, создавая copy-on-write (CoW) клон файлов.

Когда вы обновляете строку, файловая система запускает copy-on-write только для затронутых страниц. Всё остальное остаётся общим. Клон на 6 ГБ изначально не занимает дополнительного места и растёт только по мере расхождения данных.

Важно помнить один момент: у исходной базы не должно быть активных подключений во время клонирования. Это ограничение PostgreSQL, а не файловой системы.

Довольно круто.

👉 @BackendPortal

Совет по Postgres: используй filter вместо case when для условных агрегатов. Читается проще, выглядит более идиоматично для SQL и часто работает быстрее.

--  не делай так: громоздко и хуже читается
select
  count(case when status = 'active' then 1 end) as active_count,
  count(case when status = 'archived' then 1 end) as archived_count
from projects;

--  лучше так: чище и оптимизируется Postgres
select
  count(*) filter (where status = 'active') as active_count,
  count(*) filter (where status = 'archived') as archived_count
from projects;

👉 @BackendPortal

Я всегда хотел понять, как SQL-базы реально исполняют JOIN'ы. Теорию я знал, но какое-то время назад потратил пару часов на исходники MySQL, чтобы разобраться в деталях.

Оказалось, что MySQL строит join-планы инкрементально, чтобы найти оптимальный порядок соединений. Он идёт от однотабличных access paths к join'ам на 2 таблицы, затем на 3, и так далее. В качестве оптимизации он отбрасывает поддеревья, которые гарантированно дадут более высокий cost.

Интересно, что там заметны следы динамического программирования. MySQL кеширует промежуточные результаты, чтобы не считать cost заново при расширении join-плана.

Именно за это я люблю open source: если есть вопрос, можно просто зайти в код и найти ответ самому.

Если любопытно, начни с файла sql_optimizer, а в нём — с функции get_best_combination. И да, спокойно используй LLM, чтобы разбирать исходники; я делал так же.

Вот код, который находит оптимальный порядок соединения

👉 @BackendPortal

9 принципов софт-дизайна, которые стоит знать каждому разработчику:

1. DRY (Don’t Repeat Yourself). Избегай дублирования кода. Логику лучше держать в одном месте, так кодовая база намного проще в обслуживании.

2. KISS (Keep It Simple, Stupid). Тянись к простоте. Не городи архитектуру без реальной необходимости и не добавляй лишние уровни.

3. YAGNI (You Aren’t Gonna Need It). Реализуй только то, что нужно сейчас. Не трать время на потенциальные фичи, до которых может так и не дойти.

4. LOD (Law of Demeter). Общайся только с ближайшими соседями. Избегай бесконечных цепочек вызовов.

SOLID принципы:

5. SRP (Single Responsibility Principle). Класс должен отвечать только за одну вещь. Компоненты должны быть узкими и целостными.

6. OCP (Open/Closed Principle). Код должен быть открыт для расширения, но закрыт для модификации. Новое добавляем через расширение, а не переписывание старого.

7. LSP (Liskov Substitution Principle). Подклассы должны нормально подменять родительские без поломок в поведении.

8. ISP (Interface Segregation Principle). Разделяй интерфейсы на небольшие и сфокусированные, вместо огромных интерфейсов на все случаи.

9. DIP (Dependency Inversion Principle). Высокоуровневые модули не должны зависеть от низкоуровневых. Оба должны зависеть от абстракций.

👉 @BackendPortal