возвращаясь к теме: если кто-то может сказать, как правильно приготовить graphql python-2-python, было бы здорово послушать.

Я уверен, что Python to Python не нужен никакой graphql.

И тем более отрывистый HTTP

а как?

RPC :(

Поднять сокет, впилить прямой RPC на cbor

Ну т.е. вот нужен нам RPC. Мы знаем, что с обеих сторон Python.

Т.е. мы уверены, что можем обойтись без лишних прослоек

Тут, конечно, хотелось бы уточнить как используется клиент. Может он за мобильной сетью или еще что

Там вроде сервисы между собой общаются. Thrift будет оверхеден имхо ...

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

и перформанс не проблема совсем. ну в общем @sysradium в курсе специфики задачи, мы с ним сегодня пробовали запроектировать

идея была в обернуть бд сервисом graphql, чтобы все в него ходили, и фронт и внутренние

но если что было бы круто услышать от тебя как на самом деле, Рома :)

вот ниже как раз @lig11 всё рассказал.

просто многие пишут про REST, но толком объяснить что это не могут.

и для более-менее массовых операций REST становится болью

Что такое массовая операция?

Что такое массовая операция?

вот у тебя есть список на 10к получателей и rest-сервис, позволяющий смс/узнать её статус. и вот тебе каждому надо свою смс и потом мониторить статусы.

т.е. для rest тебе надо будет сделать 10k запросов, а потом ещё минимум 10к сверху для статусов.

Никто не будет это делать пулингом

И в данной задаче это не требуется. Общаются два сервиса, а не один из 10к

Никто не будет это делать пулингом

оке, а как делать? )

И в данной задаче это не требуется. Общаются два сервиса, а не один из 10к

какие два?

Мне не кажется что HTTP rest like здесь не подойдёт

Мне не кажется что HTTP rest like здесь не подойдёт

тут можно http, но будет не rest.

всё что надо - это возможность послать пачку операций

тот же батчинг, что есть в jsonrpc

послали вектор - получили вектор.

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

Какой пойнт :)

Тем более я в предпосылках не вижу ничего про массивный адский батчинг.

Я всё равно не понимаю этого хипстерского желания херачить http между двумя питоновскими сервисами.

То что ты предлагаешь имхо затранее по разработке, поддержке и отладке и просто тут не нужно

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

HTTP это решение влоб, имхо достаточное.

Я всё равно не понимаю этого хипстерского желания херачить http между двумя питоновскими сервисами.

да не обязательно питон.

Ну ок, давайте впаяем gRPC :)

Это будет стильно, модно, молодежно :)

народ, что думаете о https://www.bigchaindb.com/whitepaper/bigchaindb-whitepaper.pdf ?

да не обязательно питон.

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

@lig11 к чему ты клонишь? К import socket? :)

HTTP это решение влоб, имхо достаточное.

Ок. Когда достаточно, тогда спорить не о чем

Какой пойнт :)

поинт в том, что когда ты делаешь сервис на 3.5 запроса весь этот хипстерский rest имеет смысл. когда у тебя возникают массовые операции ты внезапно скатываешься к одному единственному ендпоинту, который принимает вектор вида [ [op, args], [op, args]...]

@lig11 к чему ты клонишь? К import socket? :)

Ну, он же всё равно есть в хттп:)

Я к тому, что ты считаешь, что лучше написать протокол руками?

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

хттп и правда неудобен

jsonRPC - ну ок, только по-моему оно не сильно прекраснее :)

Я к тому, что ты считаешь, что лучше написать протокол руками?

нет. берем и делаем спеку и гоняем потом поверх обычного tcp

@lig11 к чему ты клонишь? К import socket? :)

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

jsonRPC - ну ок, только по-моему оно не сильно прекраснее :)

не обязательно именно Json. можно взять msgpack.

нет. берем и делаем спеку и гоняем потом поверх обычного tcp

Да да да:)

Мне кажется вы любите боль

Причем больше чем я с HTTP

не обязательно именно Json. можно взять msgpack.

CBOR клевый:)

Вы пострадаете больше :)

Ну он бинарный

Как это tcpdump-ить

Вообще ужас же :)

Ну он бинарный

И это великолепно

CBOR клевый:)

да, согласен. а в нем свои типы можно ведь плодить?

да, согласен. а в нем свои типы можно ведь плодить?

Да:) шаришь

Ну он бинарный

это прекрасно. особенно ты это ощутишь на медленном инете

Он расширяемый. Т.е. можно

Нет, я понимаю что он быстрее

Да:) шаришь

а, ну огонь. как в asn.1

Просто если это быстро нам не надо и при этом его наличие усложняет дебаг, то надо ли оно? :)

Нет, я понимаю что он быстрее

дело не только в скорости, но и в размере сериализованного сообщения.

Просто если это быстро нам не надо и при этом его наличие усложняет дебаг, то надо ли оно? :)

чем усложняет?

ERROR: S client not available

Ну в случае с gRPC можно только втыкать в export GRPC_TRACE=all

Просто если это быстро нам не надо и при этом его наличие усложняет дебаг, то надо ли оно? :)

Не хер его дебажить на уровне формата. Там все сделано до нас. А свои данные ты до него можешь видеть прекрасно

Тут я полагаю больших пространств для дебага особых нет.

Чем заменить httpie? :)

Чем заменить httpie? :)

Его же клиентом

CBOR-овским

Ну, короче. Когда вам достаточно, повторю, спор ни о чем

Типа echo -n 'hello world' | coap post coap://localhost/message? Ну ок, ладно )

Может быть я немного олдфаг.

В CBOR же нет кодогенерации?

Может быть я немного олдфаг.

Каким местом?

Тем что тянет в HTTP

Тем что тянет в HTTP

Это хипсторство чистой воды

До хттп был уже smpp

И есть

И он прекрасен

Вообще, текстовые протоколы придумали для телнета, когда можно было себе позволить на отправку письма потратить час, хотя ты и принес его с собой на 10" дискете. Потому что этого часа у терминала ты все равно ждал в очереди в лучшем случае два дня

Были же времена...

До хттп был уже smpp

Хотя, не уверен, что он был до

А, кстати, может вам бы Gopher подошёл. Олдфажить, так по полной

Там типов маловато :)

ээ, цель наоборот ньюфажить

какой олдфажить, вы куда

А вообще, не надо вам с graphql заморачиваться, есть же soap

ужс

Чем заменить httpie? :)

и тут внезапно на сцену выходить hpack

Кстати, а ведь никто не мешает graphql в cbor завернуть...

А это простите что? Hpack

Кстати, а ведь никто не мешает graphql в cbor завернуть...

Это может быть даже интересно

Там что-то про хаскель гуглится. Нам не надо так упарываться

А это простите что? Hpack

это кусочек http2.0

А чем нам помогает сжатие?..