apollographql / apollographql/federation
feat(federation): Subgraph SDL validations
- Dominant language
- TypeScript
- Stars
- 727
- Forks
- 276
- Avg merge
- 1h 47m
- Merged PRs (30d)
- 1
Description
Inspiration / additional context: #882
We can do a better job during composition of assuring that subgraphs are (mostly) valid and reporting graphql-js validation errors as part of the composition step. There are a couple rules we have to omit, but otherwise there's no reason we should n't be running these.
This may be a breaking change for users, though our current composition validations likely enforce that there would be very few breaks - there are almost certainly some edge cases that have slipped through cracks, so to speak.
Capturing this snippet from investigation today during work on https://github.com/apollographql/federation/pull/882
```ts
import { federationDirectives } from '../../../directives';
import { specifiedSDLRules } from 'graphql/validation/specifiedRules';
import { validateSDL } from 'graphql/validation/validate';
import { ServiceDefinition } from '../../types';
const rulesToExclude = ['KnownTypeNamesRule', 'PossibleTypeExtensionsRule'];
const errorsToFilter = federationDirectives.map(directive => directive.name);
/**
* If there are tag usages in the service definition, check that the tag directive
* definition is included and correct.
*/
export const graphqlValidations = ({
name: _serviceName,
typeDefs,
}: ServiceDefinition) => {
const filteredRules = specifiedSDLRules.filter((rule) =>
!rulesToExclude.includes(rule.name),
);
const errors = validateSDL(typeDefs, undefined, filteredRules);
return errors.filter(({ message }) => {
return !errorsToFilter.some(keyWord => message.includes(keyWord));
});
};
```
This is just inspiration. We should probably perform the directive validations completely separately and filter the errors happening only there, since they are expected and we're handling them as a special case.
Contributor guide
Assessment
This issue has not been assessed yet.