Skip to content

Commit

Permalink
Merge branch 'release-0.26.0' into typescript-redux
Browse files Browse the repository at this point in the history
  • Loading branch information
trevor-scheer committed Mar 31, 2021
2 parents 5b30ba8 + 72841bd commit 6abb7d4
Show file tree
Hide file tree
Showing 21 changed files with 1,335 additions and 559 deletions.
8 changes: 0 additions & 8 deletions .github/dependabot.yml

This file was deleted.

983 changes: 600 additions & 383 deletions docs/package-lock.json

Large diffs are not rendered by default.

4 changes: 2 additions & 2 deletions docs/package.json
Original file line number Diff line number Diff line change
Expand Up @@ -10,9 +10,9 @@
"serve": "gatsby serve"
},
"dependencies": {
"gatsby": "2.32.9",
"gatsby": "2.32.11",
"gatsby-theme-apollo-docs": "4.7.1",
"react": "17.0.1",
"react": "17.0.2",
"react-dom": "17.0.1"
}
}
82 changes: 31 additions & 51 deletions docs/source/value-types.md
Original file line number Diff line number Diff line change
@@ -1,71 +1,51 @@
---
title: Value types
sidebar_title: Reusing types (value types)
description: Define the exact same type in multiple services
---

A natural overlap among identical types between services is not uncommon. Rather than having a single service "own" those types, all services that use them are expected to share ownership. This form of type "duplication" across services is supported for Scalars, Objects, Interfaces, Enums, Unions, and Inputs. The rule of thumb for any of these value types is that the types **must be identical** in name and contents.
It's common to reuse a GraphQL type across multiple [implementing services](./implementing-services/). For example, you might define a generic `Error` interface and an `ErrorCode` enum:

## Objects, Interfaces, and Inputs
For types with field definitions, all fields _and their types_ must be identical.
```graphql
interface Error {
code: ErrorCode!
message: String!
}

## Scalars
For Scalar values, it's important that services **share the same serialization and parsing logic**, since there is no way to validate that logic from the schema level by federation tooling.
enum ErrorCode {
UNKNOWN_ERROR
NETWORK_ERROR
AUTHENTICATION_ERROR
SERVER_ERROR
}
```

## Enums
For Enum types, all values must match across services. **Even if a service doesn't use all values in an Enum, they still must be defined in the schema**. Failure to include all enum values in all services that use the Enum will result in a validation error when building the federated schema.
These **value types** don't "originate" in a particular service. Instead, _all_ of the services that define a value type share ownership.

## Unions
Union types must share the same types in the union, even if not all types are used by a service.
Most importantly, a value type must be defined **identically** in every service that defines it. Otherwise, your federated schema will fail composition. Not every service needs to define a particular value type.

In the following example, the Product and User services both use the same `ProductCategory` enum, `Date` scalar, `Error` type, and `ProductOrError` union.
Any of the following can be a value type:

```graphql
# Product Service
scalar Date
* Scalars
* Objects
* Interfaces
* Inputs
* Enums
* Unions

union ProductOrError = Product | Error

type Error {
code: Int!
message: String!
}
Considerations for each of these are listed below.

type Product @key(fields: "sku"){
sku: ID!
category: ProductCategory
dateCreated: Date
}
## Scalars

enum ProductCategory {
FURNITURE
BOOK
DIGITAL_DOWNLOAD
}
If you define a [custom scalar](https://www.apollographql.com/docs/apollo-server/schema/custom-scalars/) as a value type, make sure all of your implementing services use the exact same serialization and parsing logic for it. The schema composition process _does not_ verify this.

# User Service
scalar Date
## Objects, interfaces, and inputs

union ProductOrError = Product | Error
For types with field definitions, all fields _and their types_ must be identical (including nullability).

type Error {
code: Int!
message: String!
}
If an object type is an [entity](./entities/), it _cannot_ be a value type.

type User @key(fields: "id"){
id: ID!
dateCreated: Date
favoriteCategory: ProductCategory
favoriteProducts: [Product!]
}
## Enums and unions

enum ProductCategory {
FURNITURE
BOOK
DIGITAL_DOWNLOAD
}

extend type Product @key(fields: "sku"){
sku: ID! @external
}
```
For enums and unions, **all possible values must match across all defining services**. Even if a particular service doesn't use a particular value, that value still must be defined in the schema. Otherwise, your federated schema will fail composition.
2 changes: 1 addition & 1 deletion federation-integration-testsuite-js/package.json
Original file line number Diff line number Diff line change
@@ -1,7 +1,7 @@
{
"name": "apollo-federation-integration-testsuite",
"private": true,
"version": "0.22.0",
"version": "0.22.1",
"description": "Apollo Federation Integrations / Test Fixtures",
"main": "dist/index.js",
"types": "dist/index.d.ts",
Expand Down
12 changes: 10 additions & 2 deletions gateway-js/CHANGELOG.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,8 +4,16 @@

> The changes noted within this `vNEXT` section have not been released yet. New PRs and commits which introduce changes should include an entry in this `vNEXT` section as part of their development. When a release is being prepared, a new header will be (manually) created below and the appropriate changes within that release will be moved into the new section.
- Enable gateway to fetch CSDL / cloud config in managed mode. This feature is currently opt-in only and should have no effect for existing use cases. After some testing, this behavior will become the default (and should be nearly transparent / non-breaking for users when we do so). It's unintended for users to start using this feature for now unless instructed by Apollo to do so. [PR #458](https://github.com/apollographql/federation/pull/458)
- __FIX__: followup to #458. Fix typings of `getDefaultFetcher` - `make-fetch-happen` types were not being included in the gateway's compiled `index.d.ts` file. [PR #585](https://github.com/apollographql/federation/pull/585)
- _Nothing yet! Stay tuned!_

## v0.25.1

- Improved query plan execution by pruning entities which are `undefined` or didn't match specified type conditions after a prior `FetchNode` execution. After pruning, only the remaining entities will be fetched in the dependent `FetchNode` execution. If NO entities remain, the request will not be made. [PR #612](https://github.com/apollographql/federation/pull/612)

## v0.25.0

- Add support for an upcoming mechanism for fetching a graph's schema and configuration when using managed federation. In this release, the new mechanism is opt-in, and users shouldn't use enable it unless instructed by Apollo to do so. [PR #458](https://github.com/apollographql/federation/pull/458) [PR #585](https://github.com/apollographql/federation/pull/585)
- Provide `context` as a fourth, optional argument to `RemoteGraphQLDataSource.didEncounterError`. This is a non-breaking change which allows implementors to read and modify the `context` object which is already similarly available in other hooks. [PR #600](https://github.com/apollographql/federation/pull/600)

## v0.24.4

Expand Down
6 changes: 3 additions & 3 deletions gateway-js/package.json
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
{
"name": "@apollo/gateway",
"version": "0.24.4",
"version": "0.25.1",
"description": "Apollo Gateway",
"author": "Apollo <opensource@apollographql.com>",
"main": "dist/index.js",
Expand Down Expand Up @@ -30,11 +30,11 @@
"@types/node-fetch": "2.5.8",
"apollo-graphql": "^0.6.0",
"apollo-reporting-protobuf": "^0.6.0",
"apollo-server-caching": "^0.5.3",
"apollo-server-caching": "^0.6.0",
"apollo-server-core": "^2.21.0",
"apollo-server-env": "^3.0.0",
"apollo-server-errors": "^2.4.2",
"apollo-server-types": "^0.6.3",
"apollo-server-types": "^0.7.0",
"loglevel": "^1.6.1",
"make-fetch-happen": "^8.0.0",
"pretty-format": "^26.0.0"
Expand Down

0 comments on commit 6abb7d4

Please sign in to comment.