на каждый чих и необходимо написать гибкий метод, к примеру, FetchUsers(query). В query хочется передавать многосоставные условия, но с кондачка в голову хороших идей не приходит.
Посмотрите в сторону graphql
У меня есть примеры что подобные методы потом приходится переписывать Сложно отследить нагрузку, на приложение валятся кучей не оптимизированные запросы
Что собственно и свойственно для graphql который выше советуют) время сэкономленное на запросах потом надо потратить на оптимизации)
Но и про gql тоже согласен Универсальное не значит оптимально
А зачем такой гибкий метод? Можно ли его заменить на несколько менее гибких методов? Можно ли такой гибкий метод вообще не делать?
Есть сервис, которому нужно запрашивать (предположим пользователей) по разным критериям, коннектиться на прямую в БД кажется не правильным, когда есть ответственный для этого сервис, который может дать к примеру gRPC API. Можно нагородить методов в духе FetchByBlahBlah(), FetchByNotBlahAndSomeBlah(), поэтому подумал сделать гибкий метод. Но раз тут все против подобного, видимо надо обдумать.
а проблема то в чем передавать какой-то список параметров для выборки в один метод Fetch - он возвращает данные.
message FetchUsersRequest { repeated SearchScope scope = 1; message SearchScope { oneof condition { ByBlah by_blah= 1; ByBlahBlah by_blah_blah = 2; } message ByBlah { string blah = 1; } message ByBlahBlah { int blah_blah = 1; } } }
(правда, не понимаю, зачем это делать на grpc)
не проще тогда использовать json rpc?
Обсуждают сегодня