You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At XING we are using the Sangria implementation of GraphQL. The implementation of the OverlappingFieldsCanBeMerged validation in Sangria follows the one in this reference implementation. We experienced performance problems with it related to the number of fragments. After we invested some time to solve it, I came up with a better algorithm, that we are using now.
The proposal would be to use this algorithm in the reference implementation. Below is an example benchmark graph showing the performance improvement for multiple fragments in the same selection set.
The text was updated successfully, but these errors were encountered:
@SimonAdameit Thanks a lot for sharing 👍 Its super useful ATM we preparing for TS conversion so we in a feature freeze state but it would be at the top queue after conversion is finished.
Also, I think we need to use this opportunity and address edge cases raised in #1497 at the same time.
but it would be at the top queue after conversion is finished.
Also, I think we need to use this opportunity and address edge cases raised in #1497 at the same time.
with TS conversion finished, this should be in the news!
At XING we are using the Sangria implementation of GraphQL. The implementation of the OverlappingFieldsCanBeMerged validation in Sangria follows the one in this reference implementation. We experienced performance problems with it related to the number of fragments. After we invested some time to solve it, I came up with a better algorithm, that we are using now.
The proposal would be to use this algorithm in the reference implementation. Below is an example benchmark graph showing the performance improvement for multiple fragments in the same selection set.
The text was updated successfully, but these errors were encountered: