Size: a a a

Django [ru] #STAY HOME

2019 May 02

AO

Alexander Ovchinnikov 🦁 in Django [ru] #STAY HOME
нормальное решение для крона должно работать с любым ЯП и любым фреймворком
источник

AO

Alexander Ovchinnikov 🦁 in Django [ru] #STAY HOME
поэтому обычный крон или systemd-timers выглядят лучше, чем вот это вот, они универсальны
источник

KC

Kenneth Chinedu in Django [ru] #STAY HOME
Alexander Ovchinnikov 🦁
если у тебя есть проекты не только на Django, и не только на питоне, то там ты крон таким образом (через celery-beat) сделать не сможешь
Это уже другие условия. Задачи решаются по разному в зависимости от условий. Но сказать что это абсолютное решение в независимости от условий уже не то
источник

AO

Alexander Ovchinnikov 🦁 in Django [ru] #STAY HOME
путь к прогрессу - это путь по стандартизации решений
источник

AO

Alexander Ovchinnikov 🦁 in Django [ru] #STAY HOME
примерно так появился и Kubernetes с контейнерами
источник

AO

Alexander Ovchinnikov 🦁 in Django [ru] #STAY HOME
люди захотели запускать что угодно одинаковым способом
источник

C

Cicerō in Django [ru] #STAY HOME
Он просто хотел запустить одну периодик задачу, кубик для него оверинжиниринг
источник

AO

Alexander Ovchinnikov 🦁 in Django [ru] #STAY HOME
Cicerō
Он просто хотел запустить одну периодик задачу, кубик для него оверинжиниринг
ну, рано или поздно все продакшены без Kubernetes вымрут, это вопрос времени
источник

AO

Alexander Ovchinnikov 🦁 in Django [ru] #STAY HOME
пока да
источник

C

Cicerō in Django [ru] #STAY HOME
Я так могу про что угодно сказать. Главное добавить рано или поздно)
источник

KC

Kenneth Chinedu in Django [ru] #STAY HOME
Alexander Ovchinnikov 🦁
нормальное решение для крона должно работать с любым ЯП и любым фреймворком
Также как сказать - не используйте орм. Запросы к базе должно работать с любым ЯП и любым Фреймворком. А в большинстве случаев, люди только один ЯП используют в своих проектов и они должны терпеть сложности ради генерализации которая им не нужна. Опять так - все зависит от условий
источник

AO

Alexander Ovchinnikov 🦁 in Django [ru] #STAY HOME
Kenneth Chinedu
Также как сказать - не используйте орм. Запросы к базе должно работать с любым ЯП и любым Фреймворком. А в большинстве случаев, люди только один ЯП используют в своих проектов и они должны терпеть сложности ради генерализации которая им не нужна. Опять так - все зависит от условий
GraphQL - это попытка сделать универсальный "ORM" к микросервисам (над gRPC / RESTful API)
источник

AO

Alexander Ovchinnikov 🦁 in Django [ru] #STAY HOME
вот это раз оно и есть, то, о чём ты написал) и поэтому GraphQL - круто)*
источник

KC

Kenneth Chinedu in Django [ru] #STAY HOME
А я про базу, не API. Тем более для graphQl важнее именно возможность динамической генерации ответа с желаемыми полями чем обобщение. Давно существуют общие рест клиенты. Так что это совсем не цель graphQl
источник

AO

Alexander Ovchinnikov 🦁 in Django [ru] #STAY HOME
Kenneth Chinedu
А я про базу, не API. Тем более для graphQl важнее именно возможность динамической генерации ответа с желаемыми полями чем обобщение. Давно существуют общие рест клиенты. Так что это совсем не цель graphQl
ну, GraphQL позволяет легко склеить разные микросервисы друг с другом на API Gateway
источник

AO

Alexander Ovchinnikov 🦁 in Django [ru] #STAY HOME
для фронтендера это будет один единый API, а по факту - куча микросервисов, каждый по-своему сделанный
источник

AO

Alexander Ovchinnikov 🦁 in Django [ru] #STAY HOME
и даже на разных ЯП, возможно
источник

AO

Alexander Ovchinnikov 🦁 in Django [ru] #STAY HOME
это opinionated решение, но оно достаточно неплохое (это не единственно правильный способ, но это хороший способ)
источник

C

Cicerō in Django [ru] #STAY HOME
Так и не добираются руки до него. Как в нем пермишены разруливаются?
источник

AO

Alexander Ovchinnikov 🦁 in Django [ru] #STAY HOME
это надо разруливать ДО допуска к ресурсу
источник