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

господа, можете взглянуть на мой API? Мне кажется, я делаю хрень, но не уверен, что после переписывания будет не хрень.

сейчас есть такая тупая и топорная реализация простого GRPC API:

service Fabex {
    rpc GetByTxId(Entry) returns (stream Entry);
    rpc GetByBlocknum(Entry) returns (stream Entry);
    rpc GetBlockInfoByPayload(Entry) returns (stream Entry);
}

message Entry {
    string channelid = 1;
    string txid = 2;
    string hash = 3;
    string previoushash = 4;
    uint64 blocknum = 5;
    string payload = 6;
    int64  time = 7;
}

Везде, как видно, используется одно и то же сообщение  Entry, но когда мы вызываем GetByTxId, то заполняем только поле txid (GetByTxId(pb.Entry{Txid:"b10e65732"})), когда вызываем GetByBlocknum, то заполняем поле Blocknum соответственно. Не очень умно, да?

Но если я сделаю микро-месседжи для каждой функции, будет тоже как-то не очень:

service Fabex {
    rpc Explore(RequestRange) returns (stream Entry);
    rpc GetByTxId(TxID) returns (stream Entry);
    rpc GetByBlocknum(Blocknum) returns (stream Entry);
    rpc GetBlockInfoByPayload(Payload) returns (stream Entry);
}

message RequestRange {
    int64 startblock = 1;
    int64 endblock = 2;
}

message Entry {
    string channelid = 1;
    string txid = 2;
    string hash = 3;
    string previoushash = 4;
    uint64 blocknum = 5;
    string payload = 6;
    int64  time = 7;
}
message TxID {
    string value = 1;
}

message Blocknum {
    string value = 1;
}

message Payload {
    string payload = 1;
}

А ведь API будет расширяться, и количество таких микро-месседжей будет множиться.

Какой вариант считаете лучше?

Второй, он будет гибким

service Fabex {
    rpc GetByTxId(Entry) returns (stream Entry);
    rpc GetByBlocknum(Entry) returns (stream Entry);
    rpc GetBlockInfoByPayload(Entry) returns (stream Entry);
}

message Entry {
    string channelid = 1;
    string txid = 2;
    string hash = 3;
    string previoushash = 4;
    uint64 blocknum = 5;
    string payload = 6;
    int64  time = 7;
}

service Fabex {
    rpc Explore(RequestRange) returns (stream Entry);
    rpc GetByTxId(TxID) returns (stream Entry);
    rpc GetByBlocknum(Blocknum) returns (stream Entry);
    rpc GetBlockInfoByPayload(Payload) returns (stream Entry);
}

message RequestRange {
    int64 startblock = 1;
    int64 endblock = 2;
}

message Entry {
    string channelid = 1;
    string txid = 2;
    string hash = 3;
    string previoushash = 4;
    uint64 blocknum = 5;
    string payload = 6;
    int64  time = 7;
}
message TxID {
    string value = 1;
}

message Blocknum {
    string value = 1;
}

message Payload {
    string payload = 1;
}

сразу падает в глазa singular getter. Я обычно в случае API делают plural getter, потому-что их можно оптимизировать batch’ами

И масштабируемее

ничего не гуглится, но, я так понимаю, лучше сделать одну функцию с фильтром?

всмсл фильтром?

singular getter = Get(ID) Object
plural getter = Get([]ID) []Object

rpc Get(Entry) returns (stream Entry);
где в первом Entry заполняются только те поля, по которым нужно отфильтровать возвращаемый стрим

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

tradeoff гибкость vs предсказуемость нагрузки

я привык так делать потому-что если нам нужно несколько - а на бэке условный SQL
то нежели вызывать метод несколько раз и делать несколько SELECT WHERE id = “x”
можно вызвать один раз и одним запросом получить все SELECT WHERE id IN […]

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

чуть сложнее написать, но это правда удобнее, конечно

signular getter конечно можно оптимизировать dataloader’ом (который будет собирать batch’и и выполнять их)
но мне кажется когда на API plural getter - есть информация какому запросу были нужны какие пакеты данных одним разом, плюс сетевая нагрузка чуток будет ниже

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

docker exec domains-keeper_kafka_1 kafka-console-producer.sh --broker-list localhost:9092 --topic domains-keeper

Коллеги, есть рекомендации по выбору базы данных для хранения комментариев? Бизнес требует бесконечные ветки комментариев с возможностью ответа на ответы. Ресерч зашел в тупик. Постгри, со связью многие к одному, через ключ parent_id, не может больше это выносить.

а какие требования?

Фронт просит пост и к нему комментарии. Комментарии отрисовываются вплоть до последнего уровня глубины сразу все. Как у редита, приблизительно.

dgraph.io ?