AO
Size: a a a
2019 April 24
AO
https://cloud.google.com/firestore/docs/concepts/data-types типы данных тут
D
не очень понял вопрос)
ну например есть сеть медцентров и пишем мы электронные карты и интерфейсы к этому всему на джанге. Диагнозы ставит какая нибудь AI приблуда на Жабе. 300 клиник, 10 миллионов карт. Нужно ли уходить с постгре и смотреть в сторону микросервисов?😊
AO
если всё устраивает, то не нужно
AO
микросервисы часто рождаются по причине того, что "слишком много кода в 1 месте, мы запутались"
D
я о применимости вопрос и задал:). Вы очень удачно обозначили как-то применимость AWS, кажется было что-то вроде от 200 до 200 000 баксов бюджет на хостинг - AWS будет выгоден. Вот и тут - а нужна ли асинхронность?
AO
да в общем-то если всё устраивает - можно и не менять
AO
микросервисы хороши чем - в случае аварий видно, где она, проще найти ошибку, проще проверить, исправить, потому что кода меньше, тестов меньше, сами тесты будут прогоняться быстрее даже для маленького проекта, чем для большого
AO
то есть я вижу некоторую естественную эволюционную плавную потребность в переходе на микросервисы, но это не "всё бросить и бежать туда быстрее"
AO
так само будет получаться
D
микросервисы хороши чем - в случае аварий видно, где она, проще найти ошибку, проще проверить, исправить, потому что кода меньше, тестов меньше, сами тесты будут прогоняться быстрее даже для маленького проекта, чем для большого
но мы платим дороговизной сейчас за то, что будет дороже потом. У бизнеса может и не наступить потом. То есть переход с джанги на что-то другое по мере роста это кул и лойс. Но ведь сама джанга - это просто питон, который может вырезать, оставив одну ORM, в которой тоже можно под капотом рыться при желании. В общем терминатора мне кажется лучше сначала лепить из лего, а джанго - лучший лего:)
AO
переход на микросервисы, да, вероятно, сначала разделит 1 большой Django-проект на несколько мелких (по приложениям или группам приложений), убрав все формы, шаблоны оттуда, это первый этап, а на втором этапе, вероятно, некоторые части будут вообще переписаны на какой-нибудь Rust, а другие могут поменять способ хранения данных или ту же ORM (на SQLAlchemyCore, например, или что-нибудь ещё)
AO
вот асинхронная Django ORM тут бы пригодилась, чтобы в самом начале сразу на ней и делать прототип, чтобы сразу асинхронщина была, чтобы без channels и celery и прочих таких вещей для фоновых задач и работы с WebSockets/SSE, так же пригодилась бы популяризация GraphQL, чтобы прототипы на Django изначально были бы async Django ORM + GraphQL API
N
привет народ! можете посоветовать видео туториалс для джангорестапи
N
например простой юсер киэйшн
D
вот асинхронная Django ORM тут бы пригодилась, чтобы в самом начале сразу на ней и делать прототип, чтобы сразу асинхронщина была, чтобы без channels и celery и прочих таких вещей для фоновых задач и работы с WebSockets/SSE, так же пригодилась бы популяризация GraphQL, чтобы прототипы на Django изначально были бы async Django ORM + GraphQL API
а вот возможность асинхронной ОРМ пожалуй да, было бы супер. Но пожалуй не спешил бы в GraphQL
AO
будущее Django как системы для прототипирования я вижу как async Django ORM + GraphQL API, ASGI, который деплоится как serverless, будет ли такое - ну, не знаю
Е
вот асинхронная Django ORM тут бы пригодилась, чтобы в самом начале сразу на ней и делать прототип, чтобы сразу асинхронщина была, чтобы без channels и celery и прочих таких вещей для фоновых задач и работы с WebSockets/SSE, так же пригодилась бы популяризация GraphQL, чтобы прототипы на Django изначально были бы async Django ORM + GraphQL API
Создаем петицию на change.org?
D
например простой юсер киэйшн
там очень простая и понятная дока. Достаточно для начала разобрать сериалайзеры и generic Views. И уже напишите что хотите
AO
тут в идеале должен быть выбор Django ORM / SQLAlchemy / NoSQL, RESTful API / GraphQL API и варианты деплоя как serverless в AWS/Google Cloud/Azure или в Kubernetes