@apollo/query-planner - npm Package Compare versions

Comparing version 2.1.0-alpha.1 to 2.1.0-alpha.2

dist/config.d.ts

 export interface QueryPlannerConfig {
     exposeDocumentNodeInFetchNode?: boolean;
+    reuseQueryFragments?: boolean;
 }
 //# sourceMappingURL=config.d.ts.map

dist/index.d.ts

@@ -7,2 +7,3 @@ export { queryPlanSerializer, astSerializer } from './snapshotSerializers';
 import { QueryPlannerConfig } from './config';
+export { QueryPlannerConfig } from './config';
 export declare class QueryPlanner {
@@ -9,0 +10,0 @@ readonly supergraphSchema: Schema;

package.json

 {
   "name": "@apollo/query-planner",
-  "version": "2.1.0-alpha.1",
+  "version": "2.1.0-alpha.2",
   "description": "Apollo Query Planner",
@@ -28,4 +28,4 @@ "author": "Apollo <[e-mail]>",
   "dependencies": {
-    "@apollo/federation-internals": "^2.1.0-alpha.1",
-    "@apollo/query-graphs": "^2.1.0-alpha.1",
+    "@apollo/federation-internals": "^2.1.0-alpha.2",
+    "@apollo/query-graphs": "^2.1.0-alpha.2",
     "chalk": "^4.1.0",
@@ -38,3 +38,3 @@ "deep-equal": "^2.0.5",
   },
-  "gitHead": "d8df6aecd716a9e2dc1f1596b0f114d0ef57fe74"
+  "gitHead": "cd07551ceaf9223fe6cda3ee29e30dee97d3573e"
 }

src/config.ts

 export interface QueryPlannerConfig {
-  exposeDocumentNodeInFetchNode?: boolean;
+  exposeDocumentNodeInFetchNode?: boolean,
+
+  /**
+   * Whether the query planner should try to reused the named fragments of the planned query in subgraph fetches.
+   *
+   * This is often a good idea as it can prevent very large subgraph queries in some cases (named fragments can
+   * make some relatively small queries (using said fragments) expand to a very large query if all the spreads
+   * are inline). However, due to architecture of the query planner, this optimization is done as an additional
+   * pass on the subgraph queries of the generated plan and can thus increase the latency of building a plan.
+   * As long as query plans are sufficiently cached, this should not be a problem, which is why this option is
+   * enabled by default, but if the distribution of inbound queries prevents efficient caching of query plans,
+   * this may become an undesirable trade-off and cand be disabled in that case.
+   *
+   * Defaults to true.
+   */
+  reuseQueryFragments?: boolean,
 }

src/index.ts

@@ -12,9 +12,4 @@ export { queryPlanSerializer, astSerializer } from './snapshotSerializers';
 
-// There isn't much in this class yet, and I didn't want to make too many
-// changes at once, but since we were already storing a pointer to a
-// Rust query planner instance in the gateway, I think it makes sense to retain
-// that structure. I suspect having a class instead of a stand-alone function
-// will come in handy to encapsulate schema-derived data that is used during
-// planning but isn't operation specific. The next step is likely to be to
-// convert `buildQueryPlan` into a method.
+export { QueryPlannerConfig } from './config'; 
+
 export class QueryPlanner {
@@ -21,0 +16,0 @@ private readonly config: QueryPlannerConfig;

New alerts

License Policy Violation

License

This package is not allowed per your license policy. Review the package's license to ensure compliance.

Found 1 instance in 1 package

Fixed alerts

License Policy Violation

License

This package is not allowed per your license policy. Review the package's license to ensure compliance.

Found 1 instance in 1 package

Improved metrics

Total package byte prevSize

552998

increased by2.74%

Lines of code

8354

increased by6.12%

Dependency changes

• Updated@apollo/federation-internals@^2.1.0-alpha.2

• Updated@apollo/query-graphs@^2.1.0-alpha.2