u r welcome

Причем тут диск? Я понимаю - жопа универсальный интерфейс и через неё можно сделать что угодно

В вашем случае это огромная куча одинакового кода

одинакового?

почему одинакового?

Ну Ваши ж микросервисы должны сообщаться как то между собой? Особенно те, для которых требуется наличие БД. И если это джанга, то наверняка вы пользуетесь ОРМ для обращений к базе... и из сервиса в сервис приходся таскать весь этот ОРМ. Либо Вы пользуетесь джанговским мультисайтингом, но в таком случае вам приходится таскать за собой всю кодовую базу. Либо сервисы определяются различными settings.py, но и в этом случае приходится таскать всю кодовую базу

Как итог, чтобы запусть 1 сервис вам нужен весь Ваш код

Да, это жёстко. А есть что почитать/посмотреть по микросервисам , так для развития?

В интернетах мало дельной инфы - всё приходит с опытом))) Нужен реальный проект, чтобы понять как лучше делать. Можно даже какой нить "домашний"

Ну Ваши ж микросервисы должны сообщаться как то между собой? Особенно те, для которых требуется наличие БД. И если это джанга, то наверняка вы пользуетесь ОРМ для обращений к базе... и из сервиса в сервис приходся таскать весь этот ОРМ. Либо Вы пользуетесь джанговским мультисайтингом, но в таком случае вам приходится таскать за собой всю кодовую базу. Либо сервисы определяются различными settings.py, но и в этом случае приходится таскать всю кодовую базу

Спорное утверждение, я считаю

микросервисы должны общаться друг с другом средствами внешних интерфейсов

REST, к примеру, или AMQP

иначе это не микросервисы получаются, а какое-то монолитно-распределённое ядро

<td>{{ item.id }}</td> <td>{{ item.date }}</td> <td>{{ item.price }}</td> <td>{{ item.des_from }}</td> <td>{{ item.des_to }}</td> <td>{{ item.driver }}</td> Но берется то все из дб по моделям?

Да, разобрался в def get кинул где квери

а данные эти сервисы должны откуда брать?

это зависит

иногда они сами репозитории данных

Можно по микро сервисы прочитать где нибудь?

иногда им на вход прилетают данные и они стреляют ответкой

посоны, чем заменить sorl-thumbnail?

кто что юзает?

Можно по микро сервисы прочитать где нибудь?

можно, но не нужно

можно, но не нужно

Уай нот?

кто что юзает?

я очень рекомендую thumbor (тоже как микросервис, кстати)

я очень рекомендую thumbor (тоже как микросервис, кстати)

спасибо!

@Masaaq http://pub.paradev.ru/books/%D0%A1%D0%BE%D0%B7%D0%B4%D0%B0%D0%BD%D0%B8%D0%B5%20%D0%BC%D0%B8%D0%BA%D1%80%D0%BE%D1%81%D0%B5%D1%80%D0%B2%D0%B8%D1%81%D0%BE%D0%B2%20%28%D1%84%D0%B0%D0%B9%D0%BB%20PDF%29.pdf

Уай нот?

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

а это неправильно, я считаю

в программировании главное не программирование само по себе, а выполнение бизнес-задач

Простой сферический пример в вакууме: Клон аппворка. Один сервис - борда вакансий и резюме, трекер работы, лк юзера

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

Нет нет, я просто прочитать,я ещё нуб чтобы ими заниматься

поставьте себе задачу типа такого: написать проект, чтобы работал, а не чтобы использовал cbv

поставьте себе задачу типа такого: написать проект, чтобы работал, а не чтобы использовал cbv

Так и есть

сделайте эт максимально быстро

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

каждый сервис должен использовать какую либо бд, либо свою собственную, либо общую...

диванные знания тут не помогут, только практика

каждый сервис должен использовать какую либо бд, либо свою собственную, либо общую...

кому должен?

сам себе. Каждый сервис выполняет свою задачу

океей

поставьте себе задачу типа такого: написать проект, чтобы работал, а не чтобы использовал cbv

Я с кбв начал по причине того что в туторе так было, и тип дела все то что мне нужно

ну вот у меня есть микросервис, который рендерит хтмл-ку, приходящую в POST, в pdf

какая ему нужна база данных и для чего?

Давайте мы не будем рассматривать Ваши частные случаи? Я согласен, что есть сервисы, которые не нуждаются в общей бд или которые используют сторонние, например нейросети

:) частные случаи - это кокрастыке требование микросервисом баз данных

потому что микросервисы по определению - это чёрные ящики

неважно, что у них внутри, как они работают

важно то, что они ожидают на вход и что возвращают

стандартный канал общения микросервисами - это tcp

чаще всего HTTP

он тормозной, с оверхедом, но такой простой и всем известный :)

Я понял Ваш подход, но у Вас оверхед с валидацией данных в таком случае

при чём любых данных

я так и сказал

но совершенно нет поводов для паники

А что касается чёрных ящиков, то тут некорректное сравнение. Тут больше подходят парадигмы unix каждая программа должна выполнять сввою и только свою задачу

но совершенно нет поводов для паники

Паники никакой - времени жалко)))

если latency в пределах миллисекунд, чего его жалеть-то

вот когда (если) latency будет в сотни и\или тысячи ms, тогда, конечно, нужно будет что-то делать

и сравнение вполне себе корректное

все эти штуки - unix way, solid, microservices - это ведь всё об одном и том же, хоть и сферы разные

Дело в том что эти миллисекунды зависят напряму от расположения этих сервисов

и?..

То есть чтоб работало "хорошо" нужно обязательно держать их все либо на одной ноде, либо на соседних

желательно

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

он может быть вполне себе скейлиться, как горизонтально, так и вертикально

это будет сложно, это будет боль. Но оно ускорится, а пользователь ничего не заметит

ERROR: S client not available

с горизонтальным проблема... при внедрении нового сервиса придётся править и остальные

или часть из них

умные головы придумали service discovery

если Вы уверены, что Ваш стартап перевернёт мир (а мы ведь все в этом уверены), то Вы учтёте этот момент при начале кодингда. И тогда ничего не придётся менять

всё, не хочу холиварить. Всё равно каждый останется при своём мнении)))

Можно было бы пофилософствовать на эту тему за пинтой пива))) В чатике это бессмысленно

стыдно пить пиво

Почему?

поставьте себе задачу типа такого: написать проект, чтобы работал, а не чтобы использовал cbv

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

тем более без добавочки "имхо", "я считаю" и "мне это помогло"

общий подход к обучению - это что?

это сказать "обучаться лучше вот так ..."

ах, это

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

тогда всё правильно. Обучаться нужно именно так

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

программист - это ремесленник, который решает прикладные задачи

только как это связанно с изучением программирования - не очень ясно

задачи бизнеса. За которые ему платят

какой-то ты сегодня холиварный :) у программиста, изучающего язык не стоит задача - решить задачу бизнеса, у него стоит задача - изучить язык/инструмент

а дальше уже идет холиварная тема: как этот инструмент изучать

элементарно. Программист, который умеет умно рассуждать про паттерны, но при этом не может, условно, сделать генерилку прайс-листа в 2 строки - не нужен

близко к реальной практике, по книжкам, по задачкам, по туторам...

потому что деньги платят не за знания и не за красоту код

это всё чудесно и применимо к работе, но к изучению - нет

а за выполнение бизнес-целей. А бизнесу абсолютно фиолетово, используются там паттерны и нет

это всё чудесно и применимо к работе, но к изучению - нет

вот тут мы и приходим к тому, что изучение просто программирования - не нужно

нужно умение решить бизнес-задачу

и этому нужно учить. А не паттерны по книжкам

гитом пользоваться - да. Тесты - обязательно (для самоконтроля). средства разработки, линуксы там всякие, контейнеры - нужны

а уж как ты будешь доставать данные из бд, голыми запросами, эктив рекордом или репозиториями - это не интересно никому, кроме твоего эго

и тех людей, с которыми ты будешь работать, и которым это поддерживать :)