This workspace demonstrates the usage of Apollo Federation within a Folio system. It consists of an Apollo Gateway and separate Apollo GraphQL servers for each module that wants to support GraphQL. Those modules can either offer new queries and types, or transparently extend existing types in the graph.
- Log into https://folio-snapshot.dev.folio.org and copy the x-okapi-token into
okapi-token.js. This demo uses folio-snapshot as the backing store of modules. To do so, it overridesx-okapi-urlheaders with the Snapshot Okapi's URL. You technically do not need to copy the token intookapi-token.js- specifying it via anx-okapi-tokenheader in your queries like normal is fine. This is just a time-saving convenience for this demo and enables the samplequery-extended-userscript to work. - Start Okapi:
cd okapi && mvn install -DskipTests && mvn exec:exec - Start Apollo Gateway:
cd mod-apollo-federation-gateway && npm install && npm start - Start mod-users-graphql:
cd mod-users/graphql && npm install && npm start - Start mod-permissions-graphql:
cd mod-permissions/graphql && npm install && npm start - Add modules to Okapi:
./startup.sh - To test everything works, run a sample query:
./query-extended-user
This workspace consists of an Apollo Federation Gateway (mod-apollo-federation-gateway) and two Apollo Federation Services (mod-permissions-graphql and mod-users-graphql). For an overview of how Apollo Federation works, see its docs. Federated service discovery is the novel bit of work here. Essentially, what we're doing is providing the core feature of Apollo Studio within the Folio architecture: providing a way for the gateway server to dynamically update its list of Federation services.
mod-apollo-federation-gateway provides the apollo-federation-gateway interface. This interface has endpoints to support CRUD operations on the list of Federation services that the Gateway is handling. Whenever the service list is updated, the gateway reboots and rebuilds the composite schema from the federated services. These endpoints are used by services such as mod-users-graphql when they are enabled for a tenant, so that they can notify the gateway of their existence via a POST to that endpoint.
mod-users-graphql and mod-permissions-graphql provide the apollo-federation-service interface, which is a multiple interface type. When it's enabled for a tenant, the gateway queries Okapi (using the provide query param) to determine which already-installed modules implement the apollo-federation-service interface and add them to its service list. Subsequent GraphQL requests from the gateway to the service are routed using the module ID which was either provided by the module when it was added to the tenant, or discovered by the gateway itself when querying Okapi.
When they're not handling a request, the modules basically do nothing. After all, they basically only proxy requests. Here's an indication of their been-running-for-a-while-and-just-served-a-few-requests-and-maybe-haven't-GC'd-everything-yet footprint.
[ 2:54PM] ~/dev/apollo-fed ps aux | grep nodemon | grep -v grep
PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND
12934 0.0 0.2 4623592 27252 s001 S+ 11:41AM 0:00.43 node ./mod-apollo-federation-gateway/node_modules/.bin/nodemon src/index.js
12930 0.0 0.2 4623536 26000 s005 S+ 11:41AM 0:00.40 node ./mod-users/graphql/node_modules/.bin/nodemon index.js
12926 0.0 0.2 4623328 26152 s002 S+ 11:41AM 0:00.41 node ./mod-permissions/graphql/node_modules/.bin/nodemon index.js