Child service data access to other services

[brettski]

We've been using Apollo federation for about 1.5 years as our main api. Behind the federation gateway are 6 child services which are all combined at the gateway. This configuration is really excellent when you have a result set of data where you want to hang one data type off of another. For example a list of orders off of a member record.

One place we have experience this breaking down is when a pre-set of data is needed which is already defined in another resolver/path. There is no way (that has been discovered by us) to query the federation from a child to get a federated set of data for use by a resolver to other work with that data.

One crazy thought which came up today is setup a apollo-datasource-rest dataSource which calls into our gateway to make a federated query which then that set of data can be acted on by the calling resolver to do whatever. So yes a child service would make a call into the graph gateway endpoint to query data for it's use, utilizing all the beauty which is Apollo Federation stitching all those different types together.

Is this a really bad idea? Is it a plausible idea? Has anyone tried something like this before?

What we are trying to avoid is having a repeated set of queries in child services to get details which are already available in other services.

Thank you for your time and consideration.

[glasser]

Can you give a more precise example? What you're asking for sounds close to what @requires is for, although perhaps you are running into its limitations.

[brettski]

I am not familiar with @requires, looking at the doc now

[brettski]

Does @requires have to be added to an extended type? My understanding is that you can't get data from an extended type from a resolver in that same project, it is only fetched through/from the Gateway. So if I am understanding this correctly this still is only available from a query through the gateway and not from a resolver in a child service.

[brettski]

Example of a federated query. In this query, event, allocatedTo, purchasedBy, and product are all types in other services. event is an Event type, allocatedTo and purchasedBy are a Profile type, and product is a Product type. This query provides me with all the data I would use to say, send an email notification to the people in the result set. Though to get this data from a resolver in a mutation to queue up those emails means I need to make many queries and align all the data through code myself instead of using the Gateway/federation which does this already.

query getRegisteredUsers($eventId: ID!) {
  communications {
    event(eventId: $eventId) {
      registered {
        event {
          name
        }
        isAllocated,
        hasCheckedIn,
        lastUpdatedAt,
        allocatedTo {
          firstName
          lastName
          email
        }
        purchasedBy {
          firstName
        }
        product {
          __typename
          ...on Ticket {
            id
            name
          }
        }
      }
    }
  }
}

[glasser]

OK, so we're talking mutations here. I take it you mean a top-level field like Mutation.doSomething? @requires won't work exactly like that, but you can do different structures.

For example, if your schema worked like

type Mutation {
  eventMutation(eventId: ID): EventMutation
}
type EventMutation
  event: Event
  doSomething(...): SomeResult @requires(fields: "event { registered { event { name } } }")
}

If you need your resolver to get information that isn't from "itself" (or pass on arguments, etc) then that's not supported by today's federation model and you'll probably want to do something like run another GraphQL query against your gateway from your subgraph, yeah.

[brettski]

If you need your resolver to get information that isn't from "itself" (or pass on arguments, etc) then that's not supported by today's federation model and you'll probably want to do something like run another GraphQL query against your gateway from your subgraph, yeah.

Okay, so that tracks with my initial question if it makes sense to run a GraphQL query against my gateway from within a resolver of one of the children services to get data. I am guessing based on your response it isn't a completely crazy idea. 😉

Thanks I wanted to check to make sure I wasn't doing something which shouldn't be done. I figure we need to watch out for cyclical resolver references, though this shouldn't be difficult.

@glasser Thanks for your time with this, we appreciate it.