Apollo Federation entity specification

I could have sworn that someone mentioned at some point that Apollo Federation compatibility was being considered. Perhaps that was in slack?

To be clear, you technically can, but it involves delegating the entire schema into another server, which is wasteful.

I didn’t see any new news on Slack, and nothing here, so I thought I would post it.

Why it doesn’t work

Apollo says:

Federated services will need to implement the following additions to the schema to allow the gateway to use the service for execution:

scalar _Any
scalar _FieldSet

# a union of all types that use the @key directive
union _Entity

type _Service {
  sdl: String
}

extend type Query {
  _entities(representations: [_Any!]!): [_Entity]!
  _service: _Service!
}

directive @external on FIELD_DEFINITION
directive @requires(fields: _FieldSet!) on FIELD_DEFINITION
directive @provides(fields: _FieldSet!) on FIELD_DEFINITION
directive @key(fields: _FieldSet!) on OBJECT | INTERFACE

# this is an optional directive discussed below
directive @extends on OBJECT | INTERFACE

Fauna does not permit any types that start with _, unions, and I am pretty sure custom directives.

workarounds

Schema delegating works fine and Schema Stitching, too. But Schema Stitching is deprecated in favor of Federation.

You can also create your own GraphQL server from scratch and provide resolvers for everything to make it Federation compatible.

Apollo Federation was (and still is) being considered. Unfortunately, other priorities have pushed that work back. I can’t promise that we’ll ever support Apollo Federation, but we haven’t abandoned the idea.

The Apollo Federation 2 spec is now GA. Is there any plan to support Apollo Federation 2?

An Apollo Federation server can still include a Fauna GraphQL API as a subgraph, just as it can any GraphQL API. That is demonstrated in this recent blog. However, you cannot extend types or “entities” in other parts of the graph, which we understand is an important part of many use cases.

Ewan’s last comment is still accurate: Adding full support is absolutely on our list, but we have prioritized other updates and features.

@rcausey do you have a use case where you would want to extend a federated graph with Fauna data? Could you provide an example of how you might use Fauna in a federated schema, assuming Fauna met all of the spec (_entities, directives, etc.)?

TL:DR

  • Ease of use of adding Fauna GQL into an existing federated architecture

@ptpaterson the use case lies in anyone having a desire to build a service oriented architecture. Let’s assume there is a service domain for managing Users, using Auth0 and some other back-end storage system for sake of example. With full federation 2 support, it would then be possible for me to stand up a new billing service domain and extend that User entity within the supergraph with a Fauna based Invoice entity. So something like:

# User service domain subgraph schema not using Fauna
type User @key(fields: "id") {
  id: ID!
  username: String! @shareable
}

# Billing service domain subgraph schema in Fauna
type Invoice {
  id: ID!
  balance: String
  # More fields here...
}

type User @key(fields: "id") {
  id: ID!
  invoices: [Invoice]
}

# Simplified composed supergraph schema
type Invoice {
  id: ID!
  balance: String
  # More fields here...
}

type User {
  id: ID!
  username: String!
  invoices: [Invoice]
}

There may be an argument for “why not just put everything in one Fauna database?”. There could be multiple answers as to why this isn’t possible:

  • big bang migrations are hard, and not being able to federate does not allow incremental migration
  • maybe there are other benefits of the service oriented architecture that negate the benefits of one central fauna database for everything.

Regardless, the utility to me is essentially a Developer Experience thing. Since in Fauna I cannot hold open a transaction while my code does some calculations and then adds more operations to the open transaction, this necessitates moving all of that transactional logic into FQL. This naturally lends itself to using UDFs which, were it not for the lack of federation 2 support, could eliminate the need for any service back-end code outside of Fauna entirely. As of now, since federation 2 is not supported, this requires writing a wrapper layer of back end code to implement custom GQL resolvers to handle the federation 2 requirements.

1 Like