KN
они заправшиваются последовательно всё равно
Size: a a a
2018 November 06
KN
если посмотреть логи подписок
KN
там id + запрос
P@
Я про простой кверик
KN
аааа, ну в транзакцию каждый персист обернуть и всё
P@
Нах подписки, с ними на порядок сложнее надо городить архитектуру. И к графу там меньше всего вопросов.
KN
а вот нифига)
KN
ну т.е. мне удалось почти норм реализовать это дело
KN
в резолверах надо просто возвращать не результат, а корутину и всё
KN
в ответ на корутину прилетит обсервер, который можно в любой момент "нотифицировать"
MM
ну т.е. мне удалось почти норм реализовать это дело
Даже с фильтрацией полей? чтобы клиенту не прилетали ненужные fields
Даже с точечным обновлением данных? если подписка на курсор из 50 больших объектов, чтобы все заново не вытаскивалось из бд?
Даже с точечным обновлением данных? если подписка на курсор из 50 больших объектов, чтобы все заново не вытаскивалось из бд?
KN
Даже с фильтрацией полей? чтобы клиенту не прилетали ненужные fields
Даже с точечным обновлением данных? если подписка на курсор из 50 больших объектов, чтобы все заново не вытаскивалось из бд?
Даже с точечным обновлением данных? если подписка на курсор из 50 больших объектов, чтобы все заново не вытаскивалось из бд?
да, конечно
P@
А здесь именно чтоб при выполнении сложного графкуэль запроса сразу паралельно отпрпвлялись запросы. В ноде это через евентлупы решается. И время ответа грубо говоря зависит от самого долгого запроса. А в пыхе у тебя получается время ответа складывается?
KN
с горячим и холодным кешем даже)
MM
ну т.е. мне удалось почти норм реализовать это дело
почему почти?
P@
Воооо, короутина значит в пыхе
KN
почему почти?
потому что грёбанные резолверы
P@
Понял. Пасиб 👍
KN
короче, как я сделал:
KN
1) Есть пул соединений
2) У каждого соединения есть пул данных (запрос + ответ)
2) У каждого соединения есть пул данных (запрос + ответ)