C
но graphql можно приготовить так что он будет работать +- как обычный rest
Size: a a a
2021 April 08
А
на сколько я понимаю в графе, он не позволяет делать сложных запросов, а делает много точечных
А
если это так, то такой же скорости как и обычный рест точно не добиться
C
ent с entgql решили эту проблему
C
они строят запрос в базу опираясь на сущности, которые клиент запросил
А
типа собирают все дерево сущностей, собирают +- сложный запрос если это возможно и потом раскидыавют по сущностям назад?
А
C
ну и dataloader-ы не первый год существуют
C
фб и инста уже сколько лет на графкл живут, и не развалились же :)
А
фейсбук со своими мощностями может себе это позволить )
AM
Привет, а есть ли какой-то гарантированный способ сделать defer в main? В случае, если паникует какая-то рутина, не обернутая в defer/recover, то вся апликуха валится мимо всех отложенных вызовов. А очень нужно почистить за собой, и пока что я вижу единственный способ - это писать обвязку, которая в случае падения основного приложения возьмет очистку на себя.
D
recover ?
AM
Вот тут если раскомментить запуск panicFunc, то recover не спасет
https://play.golang.org/p/n8Nh9eAC6B5
https://play.golang.org/p/n8Nh9eAC6B5
A
По хорошему надо бить того, кто вместо возврата ошибки паникует.
А
горутины сами по себе )
AM
Ну да, но вполне могут быть случаи, что заврапленные горутины вызовут другие горутины без всяких оберток :) Поэтому я пытаюсь найти концептуальное решение. Пока что, самое лучшее, что в голову пришло - это обертка над самим приложением. Правда, в каком-нибудь эрланге, это был бы супервизор в самом приложении😄
A
А кто паникует, если не секрет?
AM
Это хорошо и устойчиво, но не всегда применимо в реальной жизни