TL;DR: Вот репка на GitHub с приложением, а кто любит (настоящие) лонгриды — прошу под кат.
Практическое руководство по разработке бэкенд-сервиса на Python
TL;DR: Вот репка на GitHub с приложением, а кто любит (настоящие) лонгриды — прошу под кат.
Пользователь
Эта памятка писалась для внутренних нужд (открыть глаза менее опытным в вебе коллегам). Но, т.к. я насмотрелся велосипедов от довольно уважаемых, казалось бы, контор, — выкладываю на хабр. Мне кажется, многим будет полезно.
Надеюсь, читающий уже понимает, зачем ему вообще нужен именно REST api, а не какой-нибудь монстр типа SOAP. Вопрос в том, зачем соблюдать какие-то стандарты и практики, если браузеры вроде бы позволяют делать что хочешь.
{error: "message","result":...}
невозможно нормально тестировать и отлаживать200 ОК
— ну, это такое себе развлечение.Недавно LINBIT выпустили свое новое решение для оркестрации и управления множеством DRBD-массивов.
К примеру у вас может быть несколько нод и у каждой будет собственный LVM или ZFS пул в котором LINSTOR будет автоматически создавать новые тома и реплицировать их между нодами используя DRBD-протокол.
LINSTOR поддерживает thin-provisioning, снапшоты и много других интересных штук.
Это решение хорошо подойдет для виртуальных машин и контейнеров.
Академическое проектирование хранилища данных рекомендует держать все в нормализованной форме, со связями между. Тогда накат изменений по реляционной математике даст надежное хранилище с поддержкой транзакций. Atomicity, Consistency, Isolation, Durability — вот это все. Иначе говоря, хранилище специально строится для безопасного обновления данных. Но оно вовсе не оптимально для поиска, особенно широким жестом по таблицам и полям. Нужны индексы, много индексов. Объемы разрастаются, запись замедляется. SQL LIKE не индексируется, а JOIN GROUP BY отправляет медитировать в планировщик запросов.