Как реализовать микросервис на Django?

Question

[Doomplex]

Необходимо реализовать один из микросервисов, для интернет-магазина, пришел к выводу что надо, создать пустое приложение и завернуть его в докер контейнер, для дальнейшего деплоя, все это хочу реализовать на Django. Нужна помощь, так как статьи которые нашел в гугле, не помогли мне)

Comments

[Doomplex]

Dr. Bacon, нет опыта, мое задание заключается в проектировании архитектуры системы backend сервисов службы доставки по городу интернет-магазина и реализации одного из компонентов на языке Python, есть возможность помочь объяснить?

[Кирилл Горелов]

Doomplex, даю 99% гарантию, что тут можно обойтись без микросервисов.

[Сергей Горностаев]

Кирилл Горелов, даю 99%, что тут нужно обойтись без микросервисов.

[Everything_is_not_so_bad]

Doomplex,
Вы хотя бы понимаете зачем вам нужны Docker и микросервисы?
У вас нет опыта ни с тем, ни с другим.

[beduin01]

Боже. Django то тут зачем? Возьмите Flask\Sanic\Falcon\...

[Кирилл Горелов]

Мы там наверху в комментариях отговариваем от микросервиса, а ты ему подсказываешь))

[beduin01]

Dr. Bacon, вы про Джангу?

[beduin01]

Dr. Bacon, вы надо понимать фреймворк кодер если так Джангу любите. Готов поспорить с вами, что вы без умеете только типовые задачи решать. Любовь к Джанге это гарантирует.

[Никита]

Господа, а если по существу - допустим запустили микросервис (отделньое приложение) на Django. Ему же надо взаимодействовать с монолитом? Как? Писать REST API в основном движеке магазина и в Django в каждой форме скидывать данные по API? или наоборот - делать API в Django на DRF?

[Ivan Yakushenko]

Dr. Bacon, не, ну за flask могу поспорить: когда есть задача сделать нечто максимально примитивное с http интерфейсом от django много смысла нет, у меня у самого на работе много микросервисов в flask крутятся, если что-то сложнее - здравствуй django. В остальном согласен - совершенно бесполезные поделки.

[Ivan Yakushenko]

Dr. Bacon, неа, они вообще с момента перехода на собственный cli ничего откровенно нового не добавляли, хотя мы и им в своих задачах не пользуемся. У нас flask - это когда есть модуль на 50-100-200-n строк код, который нет ни малейшего желаниях пихать в общую кодовую базу, но запустить нужно, в итоге пилится одним файлов во flask за пол дня с мыслями "когда то перенесем".

[Ivan Yakushenko]

Dr. Bacon, а, ну и в целом, они в лучшем случае раз в пол года версию обновляют и то с каким то высосанным фиксом, или что-бы в очередной раз поломать обратную совместимость обновлением werkzeug, так что если раньше не использовал flask, то и смысла нет начинать.

[Ivan Yakushenko]

Dr. Bacon, фактически единственное преимущество flask в том, что минимальное рабочее приложение может состоять из 6 строк кода, но всякий раз когда есть необходимость устанавливать больше 2-3 расширений - ну его нафиг, лучше django взять, а то из говна и палок городить продукт тоже особого желания нет.

Answer 1

[Никита]

Можно рассмотреть аналоги "микросервисов" - изолировать web-сервер "маленького" приложения (и связанную с ним разработку), а базу данных например оставить уже имеющуюся. Не придется писать API для обмена данными между микро и монолит сервисами, обмен будет сразу через БД. Вариант?