@apollo/gateway 0.43.1 → 2.0.0-alpha.1

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (39) hide show
  1. package/CHANGELOG.md +2 -4
  2. package/LICENSE +95 -0
  3. package/dist/executeQueryPlan.d.ts +2 -3
  4. package/dist/executeQueryPlan.d.ts.map +1 -1
  5. package/dist/executeQueryPlan.js +2 -27
  6. package/dist/executeQueryPlan.js.map +1 -1
  7. package/dist/index.d.ts +2 -2
  8. package/dist/index.d.ts.map +1 -1
  9. package/dist/index.js +22 -41
  10. package/dist/index.js.map +1 -1
  11. package/package.json +7 -5
  12. package/src/__tests__/build-query-plan.feature +34 -24
  13. package/src/__tests__/buildQueryPlan.test.ts +76 -840
  14. package/src/__tests__/executeQueryPlan.test.ts +543 -537
  15. package/src/__tests__/execution-utils.ts +20 -26
  16. package/src/__tests__/gateway/lifecycle-hooks.test.ts +26 -4
  17. package/src/__tests__/gateway/reporting.test.ts +0 -14
  18. package/src/__tests__/integration/abstract-types.test.ts +40 -52
  19. package/src/__tests__/integration/boolean.test.ts +3 -1
  20. package/src/__tests__/integration/complex-key.test.ts +40 -55
  21. package/src/__tests__/integration/configuration.test.ts +5 -5
  22. package/src/__tests__/integration/custom-directives.test.ts +8 -2
  23. package/src/__tests__/integration/multiple-key.test.ts +10 -11
  24. package/src/__tests__/integration/requires.test.ts +2 -2
  25. package/src/__tests__/integration/scope.test.ts +19 -30
  26. package/src/__tests__/integration/value-types.test.ts +31 -31
  27. package/src/__tests__/loadSupergraphSdlFromStorage.test.ts +217 -142
  28. package/src/__tests__/queryPlanCucumber.test.ts +4 -18
  29. package/src/core/__tests__/core.test.ts +1 -0
  30. package/src/executeQueryPlan.ts +1 -32
  31. package/src/index.ts +39 -80
  32. package/src/utilities/__tests__/cleanErrorOfInaccessibleElements.test.ts +4 -4
  33. package/LICENSE.md +0 -21
  34. package/dist/core/index.d.ts +0 -13
  35. package/dist/core/index.d.ts.map +0 -1
  36. package/dist/core/index.js +0 -43
  37. package/dist/core/index.js.map +0 -1
  38. package/src/__tests__/build-query-plan-fragmentization.feature +0 -282
  39. package/src/core/index.ts +0 -51
package/src/__tests__/build-query-plan.feature CHANGED
@@ -37,7 +37,9 @@ Scenario: should use a single fetch when requesting a root field from one servic
37
37
  """
38
38
  query {
39
39
  me {
40
- name
40
+ name {
41
+ first
42
+ }
41
43
  }
42
44
  }
43
45
  """
@@ -49,7 +51,7 @@ Scenario: should use a single fetch when requesting a root field from one servic
49
51
  "kind": "Fetch",
50
52
  "serviceName": "accounts",
51
53
  "variableUsages": [],
52
- "operation": "{me{name}}"
54
+ "operation": "{me{name{first}}}"
53
55
  }
54
56
  }
55
57
  """
@@ -59,7 +61,9 @@ Scenario: should use two independent fetches when requesting root fields from tw
59
61
  """
60
62
  query {
61
63
  me {
62
- name
64
+ name {
65
+ first
66
+ }
63
67
  }
64
68
  topProducts {
65
69
  name
@@ -77,7 +81,7 @@ Scenario: should use two independent fetches when requesting root fields from tw
77
81
  "kind": "Fetch",
78
82
  "serviceName": "accounts",
79
83
  "variableUsages": [],
80
- "operation": "{me{name}}"
84
+ "operation": "{me{name{first}}}"
81
85
  },
82
86
  {
83
87
  "kind": "Sequence",
@@ -105,7 +109,7 @@ Scenario: should use two independent fetches when requesting root fields from tw
105
109
  }
106
110
  ],
107
111
  "variableUsages": [],
108
- "operation": "query($representations:[_Any!]!){_entities(representations:$representations){...on Book{__typename isbn title year}}}"
112
+ "operation": "query($representations:[_Any!]!){_entities(representations:$representations){...on Book{title year}}}"
109
113
  }
110
114
  },
111
115
  {
@@ -120,9 +124,9 @@ Scenario: should use two independent fetches when requesting root fields from tw
120
124
  "typeCondition": "Book",
121
125
  "selections": [
122
126
  { "kind": "Field", "name": "__typename" },
123
- { "kind": "Field", "name": "isbn" },
124
127
  { "kind": "Field", "name": "title" },
125
- { "kind": "Field", "name": "year" }
128
+ { "kind": "Field", "name": "year" },
129
+ { "kind": "Field", "name": "isbn" }
126
130
  ]
127
131
  }
128
132
  ],
@@ -185,7 +189,7 @@ Scenario: should use a single fetch when requesting multiple root fields from th
185
189
  }
186
190
  ],
187
191
  "variableUsages": [],
188
- "operation": "query($representations:[_Any!]!){_entities(representations:$representations){...on Book{__typename isbn title year}}}"
192
+ "operation": "query($representations:[_Any!]!){_entities(representations:$representations){...on Book{title year}}}"
189
193
  }
190
194
  },
191
195
  {
@@ -200,9 +204,9 @@ Scenario: should use a single fetch when requesting multiple root fields from th
200
204
  "typeCondition": "Book",
201
205
  "selections": [
202
206
  { "kind": "Field", "name": "__typename" },
203
- { "kind": "Field", "name": "isbn" },
204
207
  { "kind": "Field", "name": "title" },
205
- { "kind": "Field", "name": "year" }
208
+ { "kind": "Field", "name": "year" },
209
+ { "kind": "Field", "name": "isbn" }
206
210
  ]
207
211
  }
208
212
  ],
@@ -232,7 +236,7 @@ Scenario: should use a single fetch when requesting multiple root fields from th
232
236
  }
233
237
  ],
234
238
  "variableUsages": [],
235
- "operation": "query($representations:[_Any!]!){_entities(representations:$representations){...on Book{__typename isbn title year}}}"
239
+ "operation": "query($representations:[_Any!]!){_entities(representations:$representations){...on Book{title year}}}"
236
240
  }
237
241
  },
238
242
  {
@@ -247,9 +251,9 @@ Scenario: should use a single fetch when requesting multiple root fields from th
247
251
  "typeCondition": "Book",
248
252
  "selections": [
249
253
  { "kind": "Field", "name": "__typename" },
250
- { "kind": "Field", "name": "isbn" },
251
254
  { "kind": "Field", "name": "title" },
252
- { "kind": "Field", "name": "year" }
255
+ { "kind": "Field", "name": "year" },
256
+ { "kind": "Field", "name": "isbn" }
253
257
  ]
254
258
  }
255
259
  ],
@@ -326,7 +330,9 @@ Scenario: when requesting an extension field from another service, it should add
326
330
  """
327
331
  query {
328
332
  me {
329
- name
333
+ name {
334
+ first
335
+ }
330
336
  reviews {
331
337
  body
332
338
  }
@@ -344,7 +350,7 @@ Scenario: when requesting an extension field from another service, it should add
344
350
  "kind": "Fetch",
345
351
  "serviceName": "accounts",
346
352
  "variableUsages": [],
347
- "operation": "{me{name __typename id}}"
353
+ "operation": "{me{__typename id name{first}}}"
348
354
  },
349
355
  {
350
356
  "kind": "Flatten",
@@ -477,7 +483,9 @@ Scenario: when requesting a composite field with subfields from another service,
477
483
  topReviews {
478
484
  body
479
485
  author {
480
- name
486
+ name {
487
+ first
488
+ }
481
489
  }
482
490
  }
483
491
  }
@@ -512,7 +520,7 @@ Scenario: when requesting a composite field with subfields from another service,
512
520
  }
513
521
  ],
514
522
  "variableUsages": [],
515
- "operation": "query($representations:[_Any!]!){_entities(representations:$representations){...on User{name}}}"
523
+ "operation": "query($representations:[_Any!]!){_entities(representations:$representations){...on User{name{first}}}}"
516
524
  }
517
525
  }
518
526
  ]
@@ -574,7 +582,9 @@ Scenario: when requesting a composite field with subfields from another service,
574
582
  query {
575
583
  topReviews {
576
584
  author {
577
- name
585
+ name {
586
+ first
587
+ }
578
588
  }
579
589
  }
580
590
  }
@@ -609,7 +619,7 @@ Scenario: when requesting a composite field with subfields from another service,
609
619
  }
610
620
  ],
611
621
  "variableUsages": [],
612
- "operation": "query($representations:[_Any!]!){_entities(representations:$representations){...on User{name}}}"
622
+ "operation": "query($representations:[_Any!]!){_entities(representations:$representations){...on User{name{first}}}}"
613
623
  }
614
624
  }
615
625
  ]
@@ -683,7 +693,7 @@ Scenario: for abstract types, it should add __typename when fetching objects of
683
693
  "kind": "Fetch",
684
694
  "serviceName": "product",
685
695
  "variableUsages": [],
686
- "operation": "{topProducts{__typename ...on Book{price}...on Furniture{price}}}"
696
+ "operation": "{topProducts{__typename price}}"
687
697
  }
688
698
  }
689
699
  """
@@ -711,7 +721,7 @@ Scenario: should break up when traversing an extension field on an interface typ
711
721
  "kind": "Fetch",
712
722
  "serviceName": "product",
713
723
  "variableUsages": [],
714
- "operation": "{topProducts{__typename ...on Book{price __typename isbn}...on Furniture{price __typename upc}}}"
724
+ "operation": "{topProducts{__typename price ...on Book{__typename isbn}...on Furniture{__typename upc}}}"
715
725
  },
716
726
  {
717
727
  "kind": "Flatten",
@@ -819,7 +829,7 @@ Scenario: interface inside interface should expand into possible types only
819
829
  "kind": "Fetch",
820
830
  "serviceName": "product",
821
831
  "variableUsages": [],
822
- "operation": "{product(upc:\"\"){__typename ...on Book{details{country}}...on Furniture{details{country}}}}"
832
+ "operation": "{product(upc:\"\"){__typename details{__typename country}}}"
823
833
  }
824
834
  }
825
835
  """
@@ -870,7 +880,7 @@ Scenario: deduplicates fields / selections regardless of adjacency and type cond
870
880
  """
871
881
  query {
872
882
  body {
873
- ... on Image {
883
+ ... on NamedObject {
874
884
  ... on Text {
875
885
  attributes {
876
886
  bold
@@ -919,7 +929,7 @@ Scenario: deduplicates fields / selections regardless of adjacency and type cond
919
929
 
920
930
  query {
921
931
  body {
922
- ... on Image {
932
+ ... on NamedObject {
923
933
  ...TextFragment
924
934
  }
925
935
  ... on Body {