VS
ты пишешь метод "makeMySlowSelectFastAgain"
а, т.е. если что-то медленно то фолбэчимся на rpc?
Size: a a a
2020 March 16
A
а, т.е. если что-то медленно то фолбэчимся на rpc?
ну строго говоря, если внимательно посмотреть, то graphql и есть RPC
A
у тебя есть точка входа - RootOperation и дальше всё, даже fields, может иметь параметры, т.е. являются метода по факту
A
* точки входа, 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
}Д
а я не могу решать задачи фильтрации(ок условно могу, но как думай сам), сортировки и тд, вместо языка запросов я вижу язык проекций
ну так тебе в ресте придёт просьба с фильтрацией и ты ровно также в свой квери билдер или ормку отправишь этот фильтр
R
вешаешь на game комплексити который ты считаешь подходящим для 5 джойнов
ты понимаешь, что здесь это будет 5 джойнов, а в другом месте 2, а где-то еще 10? И чтобы это знать, надо знать, как устроена база?
И какой тогда смысл делать динамическую схему запросов, если все равно надо знать, как устроена статическая схема базы, и постоянно делать на это поправку?
И какой тогда смысл делать динамическую схему запросов, если все равно надо знать, как устроена статическая схема базы, и постоянно делать на это поправку?
R
инженерная сложность предоставления иерархических запросов поверх реста невообразимо выше, чем аналогично в графкуэле.
в ресте нет динамической схемы запросов же. Один раз посчитал, выставил АПИ, которое не насилует базу, и на этом все. Где сложность?
Д
ты понимаешь, что здесь это будет 5 джойнов, а в другом месте 2, а где-то еще 10? И чтобы это знать, надо знать, как устроена база?
И какой тогда смысл делать динамическую схему запросов, если все равно надо знать, как устроена статическая схема базы, и постоянно делать на это поправку?
И какой тогда смысл делать динамическую схему запросов, если все равно надо знать, как устроена статическая схема базы, и постоянно делать на это поправку?
чтобы тебе не пришлось на каждый чих делать новый метод
A
в ресте нет динамической схемы запросов же. Один раз посчитал, выставил АПИ, которое не насилует базу, и на этом все. Где сложность?
сложность в том, что приходят клиенты и говорят "нам, чтобы показать 1 экран, надо сделать 60 запросов, пофиксите ваше рестговно"
A
и база всё равно насилуется, но другим способом
R
сложность в том, что приходят клиенты и говорят "нам, чтобы показать 1 экран, надо сделать 60 запросов, пофиксите ваше рестговно"
эта же сложность есть и в графкуле
Д
нет, клиент забирает те данные которые ему нужны
R
нет, клиент забирает те данные которые ему нужны
блять, но базу-то он кладет раком
Д
нет, ты же комплексити считаешь
R
да ебтвою
A
эта же сложность есть и в графкуле
нет, сложности ТАКОЙ нет, это приносит другую сложность
A
клиент, заметь, не жалуется на скорость
A
он жалуется на другое - нужных ему данных нет в апи, собрать их - это стопицот коллов и куча говнокода
R
нет, ты же комплексити считаешь
если ему надо данные, которые требуют 60 джойнов, то все, соси. Ну посчитал ты комплексити, и по комплексити не прошел запрос. А клиент потом приходит, и говорит, что все равно надо. Хули ты будешь делать тогда?