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
<h2id="migration-and-clean-up-script">Migration and Clean-Up Script</h2>
220
220
221
-
<p><codeclass="language-plaintext highlighter-rouge">graphql_migrate_execution</code> is a command-line development tool that can automate many common GraphQL-Ruby field resolver patterns. Check out its docs and try out: https://rmosolgo.github.io/graphql_migrate_execution/</p>
221
+
<p><codeclass="language-plaintext highlighter-rouge">graphql_migrate_execution</code> is a command-line development tool that can automate many common GraphQL-Ruby field resolver patterns.</p>
222
+
223
+
<p>Check out its docs and try out: <ahref="https://rmosolgo.github.io/graphql_migrate_execution/">https://rmosolgo.github.io/graphql_migrate_execution/</a></p>
<p>Performance improvements in batching execution come at the cost of removing support for many “nice-to-have” features in GraphQL-Ruby by default. Those features are addressed here.</p>
319
+
<p><codeclass="language-plaintext highlighter-rouge">Execution::Next</code>’s new structure means that some GraphQL-Ruby features behave differently (or aren’t supported at all, at least not yet). They are discussed one-by-one below.</p>
318
320
319
321
<h3id="implicit-field-resolution">Implicit Field Resolution</h3>
<p>GraphQL-Ruby brings these breadth-first design principles to the open-source community with several novel techniques for implementing GraphQL:</p>
175
175
176
176
<ul>
177
-
<li>Fields are resolved breadth-first using implicitly batched resolvers (no DataLoader). These run longer and hotter on application logic with no execution overhead.</li>
177
+
<li>Fields are resolved breadth-first using implicitly batched resolvers. These run longer and hotter on application logic with no execution overhead.</li>
178
178
<li>Batched resolvers may bind entire load sets to a single lazy promise to dramatically reduce promise bloat.</li>
179
179
<li>Error handling is optimized into a second pass that only runs when errors actually occur.</li>
180
180
<li>Stack profiling becomes much more organized with a linear flow and aggregate field spans, rather than fields getting split up across subtree repetitions.</li>
<p>Breadth-first patterns can produce dramatic results in responses with a high degree of repetition: it’s not uncommon to see breadth batching run <strong>15x</strong> faster and use <strong>75% less</strong> memory than classic GraphQL Ruby execution. However – gains are relative. A flat tree with no lists will see little difference. A list of 2 resolving one field each will see a small gain, while a list of 100 resolving ten fields each will likely see dramatic results.</p>
185
185
186
-
<p>The downside is that many of GraphQL-Ruby’s “bonus features” – beyond the behavior described in the GraphQL Specification – add non-trivial latency when used. So, the task ahead is to “lift the ceiling” of performance in GraphQL-Ruby while retaining as much compatibility as possible and supporting a gradual transition to this new runtime engine.</p>
186
+
<p>The downside is that many of GraphQL-Ruby’s “bonus features” – those that go beyond the behavior described in the GraphQL Specification – add non-trivial overhead when used. So, the task ahead is to “lift the ceiling” of performance in GraphQL-Ruby while retaining as much compatibility as possible and supporting a gradual transition to this new runtime engine.</p>
0 commit comments