/planets?version=playstation GET /planets?partial=minimal GET /planets?fields=name,population GET /planets?fields=reinventaquerylanguage Accept Header ...
} type Film { name: String! characters: [Character!]! } type Query { character(id: ID!): Character } type Character { name: String! films: [Film!]! } FILM SERVICE CHARACTER SERVICE
} type Film { name: String! characters: [Character!]! } type Query { character(id: ID!): Character } type Character { name: String! films: [Film!]! } FILM SERVICE CHARACTER SERVICE ? ?
} type Film { name: String! characters: [Character!]! } type Query { character(id: ID!): Character } type Character { name: String! films: [Film!]! } FILM SERVICE CHARACTER SERVICE ? ?
filmsById(ids: [ID!]!: [Film!]! } type Film { name: String! characterIDs: [ID!]! } type Query { characters(ids: [ID!]): [Character!]! } type Character { name: String! filmIDs: [ID!]! } FILM SERVICE CHARACTER SERVICE
feature is how we can expand relationships within a single query, we've lost that ability because every query requires `ids` to have been fetched before. • To avoid many round trips, schemas that use this approach will try to load as many things as possible using the ID of a certain resource. • Our schema design is affected by the fact our schema is separated in multiple services. Ideally we'd like our clients not be affected by the technical decision of using a distributed architecture.
} type Film { name: String! characters: [Character!]! } type Query { character(id: ID!): Character } type Character { name: String! films: [Film!]! } FILM SERVICE CHARACTER SERVICE ? ?
character(id: ID!): Character } type Film { name: String! } type Character { name: String! } extend Film { characters: [Character!]! } extend Character { films: [Film!]! }
Service & Schema Character Service & Schema Adding new functionality Add a new type to the character schema Add a link to "plug in" the new feature with the rest of the schema
require a two step process (Add new functionality to the right schema, extend at gateway to allow for relationships) • We end up with something still quite centralized because of where the relationships are formed and the final schema is built • It's not very clear where new schema use cases go. We risk that a lot of domain logic will leak into the gateway, making our GraphQL gateway a monolithic API, the thing we wanted to avoid in the first place using this solution.
logic and process orchestration implemented in middleware, especially where it requires expert skills and tooling while creating single points of scaling and control. Vendors in the highly competitive API gateway market are continuing this trend by adding features through which they attempt to differentiate their products. This results in OVERAMBITIOUS API GATEWAY products whose functionality — on top of what is essentially a reverse proxy — encourages designs that continue to be difficult to test and deploy." HTTPS://WWW.THOUGHTWORKS.COM/RADAR/PLATFORMS/OVERAMBITIOUS-API-GATEWAYS
} type Film { name: String! } extend Character { films: [Film!]! } type Query { character(id: ID!): Character } type Character { name: String! } extend Film { characters: [Character!]! } FILM SERVICE CHARACTER SERVICE