Creating large data graphs is great but as you add more services to the data graph you may not want to expose some of this data externally. Being able to mask schema fields and have various gateways can be a powerful way to manage data access.

Data shields

Using data shields you can limit the role/user level access for resolvers but this still exposes the existence of these fields externally. It would also be good to limit their visibility. Using custom directives we can mark the fields in a federated schema so it can hold information about the field visibility.

directive @internal on FIELD_DEFINITION

type Review {
    starRating: Int
    authorName: String @internal
    title: String
}

Registry field visibility

We have a custom registry that has been enhanced to compose schemas based on the gateway profile provided. For example a field can be marked so it should only be visible to an internal gateway. Now when the external gateway requests the schema from the registry these internal fields have been ommitted.

GET https://www.schema-regsitry.org/schema/compose/schema?gateway=external

Conclusions

Limiting visibility and access to specific parts of a data graph is a necessary feature to allow a single schema for the company. This is very powerful tool to allow quick access to all parts of the company’s data graph. Multiple gateways providing a filtered view of this schema is much better than multiple schemas.

Follow me on twitter @andyianriley
or see andyianriley @ linkedin.