нет, если тебе нужны кубики - то тебе фласк, а не джанга

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

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

согласен :)

но, по моему опыту, орм джанги, например - неловкая поделка на фоне SQLAlchemy

а движок шаблонов - говно по сравнению с jinja2

это CRUD, где урлы - идентификаторы записей

а во-вторых, rest - это всегда медленно.

и если уж нужна SQLAlchemy - я бы выбрал Pyramid, а не Flask

а во-вторых, rest - это всегда медленно.

rest^Whttp

и если уж нужна SQLAlchemy - я бы выбрал Pyramid, а не Flask

это на здоровье, у flask просто инфраструктура получше

rest^Whttp

http1, http2 относительно быстро парсится ибо бинарный

я с этим не согласен но пофиг) ладно, давай на другую тему, не будите во мне Чистякова))

валидировать - jsonschema или wtforms

Rest это не json. И не данные из форм

http1, http2 относительно быстро парсится ибо бинарный

да, spdy как-то sosnool

Rest это не json. И не данные из форм

это просто структурированное представление объекта, пофиг в каком формате

но на практике чаще всего json

rest^Whttp

нет, дело не в http даже

это просто структурированное представление объекта, пофиг в каком формате

Ты утверждаешь, что jsonschema валидирует любой формат, так?

http1, http2 относительно быстро парсится ибо бинарный

ну, http2 чуть ситуацию улучшает, да. но на линках с пакетлоссом там всё будет хуже даже.

Ты утверждаешь, что jsonschema валидирует любой формат, так?

нет, разумеется

но ты на практике вряд ли будешь не-json использовать, верно?

хоть REST сам и не о JSON конкретно

но ты на практике вряд ли будешь не-json использовать, верно?

я в 90% случаев не буду использовать json

мне кажется если сейчас делать API для клинетов не умеющих gRPC — то лучше делать это через https://github.com/grpc-ecosystem/grpc-gateway

но ты на практике вряд ли будешь не-json использовать, верно?

Ты инструмент под задачу выбираешь, или задачу под инструмент?

мне кажется если сейчас делать API для клинетов не умеющих gRPC — то лучше делать это через https://github.com/grpc-ecosystem/grpc-gateway

ну, это для инвалидов )))

Ты инструмент под задачу выбираешь, или задачу под инструмент?

инструмент под задачу, разумеется. Но мне сложно представить задачу реальную сейчас, где мне надо будет что-то, что не JSON или XML

ну, http2 чуть ситуацию улучшает, да. но на линках с пакетлоссом там всё будет хуже даже.

начитались тут презенташек от Fastly. Это далеко не полная правда. Их суждение было что h2 из-за того, что у него HOL-blocking хуже работает на lossy линках, потому, что CUBIC на них медленный. Тот же тест с TCP NV или TCP BBR даст совсем другие результаты. Не стоит доверять чужим данным не проверяя их.

ну, это для инвалидов )))

а есть варианты лучше?

проблема rest в том, что хер там сделаешь батчинг. а если его сделать, то всё сводится к одному эндпоинту и уже никакой это не рест )

начитались тут презенташек от Fastly. Это далеко не полная правда. Их суждение было что h2 из-за того, что у него HOL-blocking хуже работает на lossy линках, потому, что CUBIC на них медленный. Тот же тест с TCP NV или TCP BBR даст совсем другие результаты. Не стоит доверять чужим данным не проверяя их.

да причём тут чужие презенташки? очевидно, что tcp - это bytestream и данные извлекаются последовательно. http2 реализует свой фрейминг поверх этого bytestream.

проблема rest в том, что хер там сделаешь батчинг. а если его сделать, то всё сводится к одному эндпоинту и уже никакой это не рест )

в смысле? коллекция объектов - такой же объект

в чем проблема?

инструмент под задачу, разумеется. Но мне сложно представить задачу реальную сейчас, где мне надо будет что-то, что не JSON или XML

Держи YAML, например

Держи YAML, например

держу, но я ни разу не видел REST на YAML’е в жизни

и да, JSON - это тоже YAML

начитались тут презенташек от Fastly. Это далеко не полная правда. Их суждение было что h2 из-за того, что у него HOL-blocking хуже работает на lossy линках, потому, что CUBIC на них медленный. Тот же тест с TCP NV или TCP BBR даст совсем другие результаты. Не стоит доверять чужим данным не проверяя их.

т.е. этот фрейминг реализует те же самые дейтаграммы что в ip, только с гарантиями доставки и очередности + сильная зависимость от соседних потоков.

т.е. этот фрейминг реализует те же самые дейтаграммы что в ip, только с гарантиями доставки и очередности + сильная зависимость от соседних потоков.

не сильная. из-за наличия SACK и fast-retransmit, оно в большинстве случаев добавляет не больше одного rtt в случае даже сильного packetloss'а.

в смысле? коллекция объектов - такой же объект

мм... смотри. я пример этот уже приводил и просто повторюсь: надо послать и убедиться в доставке 10к смс-сообщений через сервис, который умеет послать смс(вернув message id) и по этому message id сказать статус(доставлено/нет).

мм... смотри. я пример этот уже приводил и просто повторюсь: надо послать и убедиться в доставке 10к смс-сообщений через сервис, который умеет послать смс(вернув message id) и по этому message id сказать статус(доставлено/нет).

окей, и в чем проблема? это легко разложить на REST

т.е. этот фрейминг реализует те же самые дейтаграммы что в ip, только с гарантиями доставки и очередности + сильная зависимость от соседних потоков.

если же ты про buffer bloat, то BQL, TSQ, FQ и pacing эти проблемы решают

не сильная. из-за наличия SACK и fast-retransmit, оно в большинстве случаев добавляет не больше одного rtt в случае даже сильного packetloss'а.

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

ты берешь и сабмитишь коллекцию из 10 объектов PUT или POST запросом на урл, тебе в ответ приходит 10 тех же объектов с привязанными к ним тасками, у которых обновляется статус

если же ты про buffer bloat, то BQL, TSQ, FQ и pacing эти проблемы решают

это только linux.

ты берешь и сабмитишь коллекцию из 10 объектов PUT или POST запросом на урл, тебе в ответ приходит 10 тех же объектов с привязанными к ним тасками, у которых обновляется статус

ну вот. осталось саму операцию слать в самом запросе и рест становится не нужен.

опять же, я не говорю что мультиплексировать вещи внури tcp — это праям охуенная идея, я лишь говорю, что большинство этих проблем было решено командами из Гугла 5 лет назад. Когда они доготовят QUIC, то grpc наверняка плавно перейдёт на него

ну вот. осталось саму операцию слать в самом запросе и рест становится не нужен.

да, так тоже делают, json-rpc, например

если же ты про buffer bloat, то BQL, TSQ, FQ и pacing эти проблемы решают

ну и на всякие промежуточные устройства ты не сильно повлияешь. rtt в 10 секунд можно запросто словить в мобильной сети в момент перегруза.

но это из задачи надо исходить, опять же

если у тебя больше разных типов объектов и действий с ними - тогда REST есть REST

это только linux.

на серверсайде всегда линукс, а с повсеместным андройдом, половина high packetloss клинетских девайсов тоже под ним

ну и на всякие промежуточные устройства ты не сильно повлияешь. rtt в 10 секунд можно запросто словить в мобильной сети в момент перегруза.

с этим и не-h2 не справится нормально. от 10с даже FEC не спасёт

опять же, я не говорю что мультиплексировать вещи внури tcp — это праям охуенная идея, я лишь говорю, что большинство этих проблем было решено командами из Гугла 5 лет назад. Когда они доготовят QUIC, то grpc наверняка плавно перейдёт на него

основная беда в том, что tcp крайне херово реагирует на потери, воспринимая её как перегрузку.

основная беда в том, что tcp крайне херово реагирует на потери, воспринимая её как перегрузку.

это не правда

это CUBIC так делает

основная беда в том, что tcp крайне херово реагирует на потери, воспринимая её как перегрузку.

это ты откуда такое взял?

это не правда, для BBR, CDG, и New Vegas

это CUBIC так делает

reno тоже

да, многие так делают, но это не свойство протокола

это свойство конкретных имплементаций

это не правда, для BBR, CDG, и New Vegas

дадада. но cdg крайне странно себя повёл, когда я его включил на наших серверах.

потому что его нельзя в продакшн, ибо он написан PhD для PhD. Его CUBIC задавит в интернете.

потому что его нельзя в продакшн, ибо он написан PhD для PhD. Его CUBIC задавит в интернете.

ну, проблема с fairness - это мелочи по сравнению с тем, что многие клиенты просто тупо отвалились

скатились к каким-то жутким нескольким кб/с

это крайний случай не-fairness - starvation

держу, но я ни разу не видел REST на YAML’е в жизни

Допустим, YAML не потребуется парсить. А как ты будешь парсить XML с помощью jsonschema?

Допустим, YAML не потребуется парсить. А как ты будешь парсить XML с помощью jsonschema?

я не буду, я возьму какой-нибудь готовый xml-валидатор

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

а что тебе не нравится?

Для валидатора потребуется еще раз описать правила?

а что тебе не нравится?

Первый типичный кейс, а уже надо ставить какой-нибудь валидатор xml

я не буду, я возьму какой-нибудь готовый xml-валидатор

xml дичайше расточителен.

Дальше я бы тебя спросил про кеширование, про etag, про интеграцию с sqlalchemy

это крайний случай не-fairness - starvation

так там не было дефицита полосы. и это странно.

Люди, одумайтесь, не пишите вы это говно в ручную, возьмите ваш внутренний типизированный бинарный RPC, и генерите автоматом стабы для api-gateway'я который вам будет преобразовывать входящий JSON обратно в thrift/protobuf/etc и дальше отсылать по вашему внутреннему RPC. Нафиг вам 2 разные системы? Вот простой пример прямо от GCP: https://cloud.google.com/service-management/reference/rpc/google.api#http

Люди, одумайтесь, не пишите вы это говно в ручную, возьмите ваш внутренний типизированный бинарный RPC, и генерите автоматом стабы для api-gateway'я который вам будет преобразовывать входящий JSON обратно в thrift/protobuf/etc и дальше отсылать по вашему внутреннему RPC. Нафиг вам 2 разные системы? Вот простой пример прямо от GCP: https://cloud.google.com/service-management/reference/rpc/google.api#http

дададад.

так там не было дефицита полосы. и это странно.

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

Люди, одумайтесь, не пишите вы это говно в ручную, возьмите ваш внутренний типизированный бинарный RPC, и генерите автоматом стабы для api-gateway'я который вам будет преобразовывать входящий JSON обратно в thrift/protobuf/etc и дальше отсылать по вашему внутреннему RPC. Нафиг вам 2 разные системы? Вот простой пример прямо от GCP: https://cloud.google.com/service-management/reference/rpc/google.api#http

давайте все писать на Scala + Finagle + Finch + Circe

там все такие вещи проверяет еще компилятор

в Go/C++/Rust у нас тоже эти вещи проверяет компилятор, в Python protobuf stub'ы аннотированы mypy. Это не спицифично для какого либо языка, это можно сделать везде.

Ну если внутри сети, балансировку делать когда ты контролируешь всех клиентов и серверов, то DNS ничем не хуже чего-то другово. У нашего **внутреннего** Service Dicovery очень DNS-like API сейчас. Большинство SD ещё имею DNS-bridge для third party software, например тот же консул.

Речь про внешнюю была вроде :)

Речь про внешнюю была вроде :)

Для внешней балансировки DNS — это пиздец. У нас был случай когда какие-то принтеры резолвили dropbox.com только на старте. Пришлось год ждать пока они все поребутаются, чтобы выкинуть старый IP. Да что далеко ходить, куча провайдеров по миру имеют говноадминов, которые настроили bind игнорировать любой TTL меньше месяца. Мы так на www месяц ждали чтобы со старого IP безопастно уехать.

(про DDoS я вообще молчу, если у вас есть куча "слабых" unicast IP'шников - заддоить очень просто)

Люди, одумайтесь, не пишите вы это говно в ручную, возьмите ваш внутренний типизированный бинарный RPC, и генерите автоматом стабы для api-gateway'я который вам будет преобразовывать входящий JSON обратно в thrift/protobuf/etc и дальше отсылать по вашему внутреннему RPC. Нафиг вам 2 разные системы? Вот простой пример прямо от GCP: https://cloud.google.com/service-management/reference/rpc/google.api#http

Хорошая попытка, но нет. Что тут нового, это все и без гугла было, и даже больше. Например, тот же flask и webargs

Хорошая попытка, но нет. Что тут нового, это все и без гугла было, и даже больше. Например, тот же flask и webargs

ты похоже не понимаешь, что такое RPC и rpc stub'ы.

Сформулируй, что хотел сказать-то

Леголас фигню пороть не будет

https://arxiv.org/pdf/1611.05428.pdf

инструмент под задачу, разумеется. Но мне сложно представить задачу реальную сейчас, где мне надо будет что-то, что не JSON или XML

Вы сейчас через эту реальную задачу общаетесь)

Вы сейчас через эту реальную задачу общаетесь)

ты хочешь сказать, что внутри телеграма REST?

Но бинарный полиморфный язык телеграма это уже слегка перебор, конечно

не, бинарных протоколов много разных

мы именно про REST

мы именно про REST

Я уже писал: рест очень быстро вырождается в единственный эндпоинт

Я уже писал: рест очень быстро вырождается в единственный эндпоинт

зависит от задачи

когда вырождается, когда нет

для CRUD - REST, для запуска удаленных процедур - RPC, на деле обычно комбинация из обоих подходов

для CRUD - REST, для запуска удаленных процедур - RPC, на деле обычно комбинация из обоих подходов

Ну так ещё вопрос в оверхеде

для CRUD - REST, для запуска удаленных процедур - RPC, на деле обычно комбинация из обоих подходов

Или вот надо тебе поллить 10к обьектов

Ну так ещё вопрос в оверхеде

оверхеда так или иначе не избежать

Или вот надо тебе поллить 10к обьектов

и? делаешь коллекцию из 10к объектов объектом с таской с 10к статусов