Разработка CRM для ресторана с нуля: зачем я написал бэкенд для сайта на конструкторе

[mixsture]

Зачем делали именно на голых технологиях?

Почему не взяли:
odoo, frappe (как опенсорсные crm движки)
или тот же django, если прям хотите логику crm сами писать?

Там огромные куски из вашего кода уже реализованы. Вам только своих сущностей накидать и их представления (формы).

[nonsess]

Привет! Спасибо за вопрос

Готовые решения смотрели, но для небольшого ресторана они оказались оверхедом. А голые технологии выбрал осознанно - хотел не просто настроить CRM, а глубоко разобраться, как работают вебхуки, транзакции и идемпотентность изнутри

Если проект вырастет - точно посмотрим в сторону фреймворков

[dimulyaechayev]

Не все любят готовые решения, кому-то нравится с душой писать с нуля своё, я стараюсь такого же подхода придерживаться, если тому предрасполагает время, думаю, что со временем такие старания окупятся. Как и сам автор отписал - именно такая практика даст более глубокое понимание

[Zippy]

https://ru.zippy.com.ua/

бесплатная с втроеным модулем общепита и всеми учетными мульками

[DaneSoul]

В начале проекта мы решили, что хотим видеть, кто и когда изменил статус заказа, применил бонус. Для этого я реализовал систему аудита (Changelog). В качестве базы данных для changelog я выбрал MongoDB, ведь логи разные, все зависит от того какое действие делает пользователь.

Что мешало добавить в PostgreSQL несколько таблиц и хранить эту информацию там?
Зачем множить сущности?

[nonsess]

Привет! Вопрос справедливый

Честно: хотелось попробовать MongoDB в деле и разделить ответственность (операционка отдельно, логи отдельно). Документная модель казалась удобнее для разношерстных логов - не нужно думать о структуре таблиц

Но согласен: PostgreSQL с JSONB справился бы не хуже, а архитектура была бы проще. Для текущего масштаба - да, возможно, оверхед. Но для опыта - полезное решение

Спасибо за фидбек

[akaddr]

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

[nonsess]

Окей, посмотрю

[tmxx]

Я бы не тащил это на Хабр. Вдруг заказчик комментарии увидит...

[nonsess]

Ну увидит и что?

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

[tmxx]

Ведь я не просто написал систему и исчез, я в долгосрок над ней буду работать

а вот это правильно!

[notlimitedwolf]

Максимально странная статья при чтении. Напутанные понятия (audit с гордым названием changelog), не лучшие архитектурные решения (вторая бд под самый стандартный юз кейс постгреса, когда на деле им чуть ли не кафку с редисом заменяют), потерянный редис (так и не понял зачем он тут), и, самое главное - "масштаб". То какие то базовые и очевидные вещи преподносятся как архитектурные решения (к примеру, использование транзакий postgres), то эти самые базовые детали поясняются в ещё более базовых деталях

Валидация данных (Pydantic). Я не доверяю входящим данным. Все поля строго типизированы. Если вместо числа в сумме заказа придет строка - система отклонит запрос.

На выходе просто статья, которая выглядит как что-то крутое, но на деле преподносит самый обычный пет проект со своими минусами в красивом свете

[nonsess]

Спасибо за обратную связь. Учту, при написании следующей статьи. Только набиваю руку