@fsharp_flood - страница 2081

query notifications($page: Int, $per_page: Int) { notifications(page: $page, per_page: $per_page, unviewed: true) { data { id text is_viewed created_at } total total_unviewed current_page last_page per_page has_more_pages } }

Диёр

вот ещё один запрос

Romɑn

нет, это graphql запрос

да, но внутри вот эти min_count ты мне самому предлагаешь реализовывавать?

Anatoly

я, например, котирую пагинацию только на курсорах

Romɑn

я не против, пусть это в спеку войдет

Диёр

да, но внутри вот эти min_count ты мне самому предлагаешь реализовывавать?

от реализации твоего gql зависит

Anatoly

все эти take/skip/minCount в жопу, они не нужны

Диёр

моя либа имеет интеграцию с ормкой и по базе сама разруливает и n+1 тоже

Romɑn

все эти take/skip/minCount в жопу, они не нужны

живи без них

Romɑn

мне нужны

Romɑn

я не хочу каждый раз базовые вещи реализовывать

Anatoly

живи без них

ну я считаю, что курсоры надо в спеку языка, а не take/skip/minCount

Romɑn

ну я считаю, что курсоры надо в спеку языка, а не take/skip/minCount

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

Anatoly

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

и рест тебе никак в этом не помогает

Anatoly

там тоже нет описания пагинации в спеке

Romɑn

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

Romɑn

так что это не QL а PL

Anatoly

вотэва, на эту тему я спорить не буду

Диёр

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

а это, например, не из запроса, а из схемы referral_codes_configurations(orderBy: [OrderByClause!] = [{field: "created_at", order: DESC}] @orderBy): [ReferralCodesConfiguration!]! @all(model: "App\\Models\\Bonus\\ReferralCodesConfiguration") @middleware(checks: ["auth:api", "roles:admin,support"])

Vladimir

ты пишешь метод "makeMySlowSelectFastAgain"

а, т.е. если что-то медленно то фолбэчимся на rpc?

Anatoly

а, т.е. если что-то медленно то фолбэчимся на rpc?

ну строго говоря, если внимательно посмотреть, то graphql и есть RPC

Anatoly

у тебя есть точка входа - RootOperation и дальше всё, даже fields, может иметь параметры, т.е. являются метода по факту

Anatoly

* точки входа, RootOperations может быть несколько

Диёр

query packages { packages(min_count: 50, max_count: 100, order_by: [price]) { id game { id title } count price is_active most_popular top_pack } }

вот кстати тип пакета: type Package { id: ID! game: Game! @belongsTo(relation: "game") count: Int! price: Float! is_active: Boolean! top_pack: Boolean! most_popular: Boolean! package_with_bonus(bonus_code: String): PackageWithBonus @method(name: "packageWithBonusResolver") serial_number: Int }

Диёр

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

ну так тебе в ресте придёт просьба с фильтрацией и ты ровно также в свой квери билдер или ормку отправишь этот фильтр

Roman

вешаешь на game комплексити который ты считаешь подходящим для 5 джойнов

ты понимаешь, что здесь это будет 5 джойнов, а в другом месте 2, а где-то еще 10? И чтобы это знать, надо знать, как устроена база? И какой тогда смысл делать динамическую схему запросов, если все равно надо знать, как устроена статическая схема базы, и постоянно делать на это поправку?

Roman

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

в ресте нет динамической схемы запросов же. Один раз посчитал, выставил АПИ, которое не насилует базу, и на этом все. Где сложность?

Диёр

ты понимаешь, что здесь это будет 5 джойнов, а в другом месте 2, а где-то еще 10? И чтобы это знать, надо знать, как устроена база? И какой тогда смысл делать динамическую схему запросов, если все равно надо знать, как устроена статическая схема базы, и постоянно делать на это поправку?

чтобы тебе не пришлось на каждый чих делать новый метод

Anatoly

в ресте нет динамической схемы запросов же. Один раз посчитал, выставил АПИ, которое не насилует базу, и на этом все. Где сложность?

сложность в том, что приходят клиенты и говорят "нам, чтобы показать 1 экран, надо сделать 60 запросов, пофиксите ваше рестговно"

Anatoly

и база всё равно насилуется, но другим способом

Roman

сложность в том, что приходят клиенты и говорят "нам, чтобы показать 1 экран, надо сделать 60 запросов, пофиксите ваше рестговно"

эта же сложность есть и в графкуле

Диёр

нет, клиент забирает те данные которые ему нужны

Roman

нет, клиент забирает те данные которые ему нужны

блять, но базу-то он кладет раком

Диёр

нет, ты же комплексити считаешь

Roman

да ебтвою

Anatoly

эта же сложность есть и в графкуле

нет, сложности ТАКОЙ нет, это приносит другую сложность

Anatoly

клиент, заметь, не жалуется на скорость

Anatoly

он жалуется на другое - нужных ему данных нет в апи, собрать их - это стопицот коллов и куча говнокода

Roman

нет, ты же комплексити считаешь

если ему надо данные, которые требуют 60 джойнов, то все, соси. Ну посчитал ты комплексити, и по комплексити не прошел запрос. А клиент потом приходит, и говорит, что все равно надо. Хули ты будешь делать тогда?

Anatoly

если ему надо данные, которые требуют 60 джойнов, то все, соси. Ну посчитал ты комплексити, и по комплексити не прошел запрос. А клиент потом приходит, и говорит, что все равно надо. Хули ты будешь делать тогда?

тогда ты берёшь и выделяешь спецметод под задачу

Roman

тогда ты берёшь и выделяешь спецметод под задачу

как и в ресте

Anatoly

как и в ресте

даёптваю (тм)

Диёр

если ему надо данные, которые требуют 60 джойнов, то все, соси. Ну посчитал ты комплексити, и по комплексити не прошел запрос. А клиент потом приходит, и говорит, что все равно надо. Хули ты будешь делать тогда?

ну если он в графкуле превысил комплексити, то он и в ресте все твои сервисы повесит