menu

Apollo

A community of developers, designers and others who love Apollo and GraphQL. 🚀

Channels
# All channels
view-forward
# General
view-forward
# Apollo Angular
view-forward
# Announcements
view-forward
# Apollo Android
view-forward
# Apollo Client
view-forward
# Apollo iOS
view-forward
# Apollo Link
view-forward
# Apollo Link Rest
view-forward
# Local State
view-forward
# Apollo Platform
view-forward
# Apollo Server
view-forward
# Apollo Tooling
view-forward
# Contributing
view-forward
# Docs
view-forward
# Events
view-forward
# GraphQL Tools
view-forward
# Jobs
view-forward
# Random
view-forward
# React Apollo
view-forward
# Showcase
view-forward
# Subscriptions
view-forward
# Testing
view-forward
# Vue Apollo
view-forward
Team

Using buildFederatedSchema without gateway

August 29, 2019 at 10:55am

Using buildFederatedSchema without gateway

August 29, 2019 at 10:55am
Hi, I am wondering if it's possible to use buildFederatedSchema simply to split huge schema files to some subtypes with own files like this: const schema =buildFederatedSchema([ { typeDefs, resolvers, }, { typeDefs: someOtherDefs, resolvers: someOtherResolvers } ]);
and then use it in ApolloServer({schema}).
It might be tricky to split deployment into multiple microservices (also it looks apollo-federation is on early stage), but at least having smaller schema file would help me. Is it recommended? Can it cause some side effects?
My use case is - I have a lot of custom Enum defined because of business logic we are implementing, so I want to extract those enum definitions into separate directory. Currently it's all in one huge schema which is hardly readable.

August 29, 2019 at 1:42pm
LocalGraphQLDataSource looked interesting
Looks like you could build a gateway passing it GraphQLSchema objects
  • reply
  • like
Not sure what do you mean. I am just passing buildFederatedSchema result to ApolloServer and it seems to be working but I am worried about possible side effects.
  • reply
  • like
https://github.com/rajeshdavidbabu/federation-demo-local-services/
...
const gateway = new ApolloGateway({
localServiceList: [accounts, inventory, products, reviews],
buildService: service => {
return new LocalGraphQLDataSource(buildFederatedSchema([service]));
},
});
...
Then each service is a separate folder of schema/resolvers
  • reply
  • like
What's the difference between this and simply passing it to ApolloServer constructor, just like mentioned here: https://github.com/apollographql/apollo-server/blob/442cedb743c63260f7a6ddd4d1076f9f1cde7494/docs/source/api/apollo-federation.mdx ?
  • reply
  • like
Well you create the server, then you take the server and bind it to an express (or whatever you use) endpoint. const server = new ApolloServer ... you would need to do that for every schema
It looks like LocalGraphQLDataSource skips the gateway -> POST /graphql part
Edited
  • reply
  • like
What do you mean by " you would need to do that for every schema" ? You can combine all (sub)schemas using buildFederatedSchema, and then pass it to constructor once. Also, most important - all both approaches correct? Anyone?
Edited
  • reply
  • like

September 4, 2019 at 7:02am
Any updates on this? what solution did you end up using?
  • reply
  • like

October 1, 2019 at 2:06am
https://github.com/rajeshdavidbabu/federation-demo-local-services/
...
const gateway = new ApolloGateway({
localServiceList: [accounts, inventory, products, reviews],
buildService: service => {
return new LocalGraphQLDataSource(buildFederatedSchema([service]));
},
});
...
Then each service is a separate folder of schema/resolvers
This solution works very well if ALL schema/resolvers are local. What if one of the services, say, reviews, is remote. Do you know how I should go about creating a RemoteGraphQLDataSource? It seems like you can't mix localServiceList with serviceList.
Edited
  • reply
  • like

December 30, 2019 at 3:50pm
I've been using the same solution I originally proposed. Didn't got any reason why to use local services.
  • reply
  • like

March 17, 2020 at 7:21am
I did the same approach, thinking about refactoring. Is there any news to this subject, is it an accepted approach, does it come with any side effects?
from reading this https://www.apollographql.com/docs/apollo-server/api/apollo-federation/ and this post

Correct way to merge schemas with buildFederatedSchema for a single federated sub-service.

thumbsup
2
message-simple
3
here on spectrum. I felt that it was accepted to do so? looking deeper into federation in seems to be some what stricted for micoservices tho ?
  • reply
  • like
It's absolutely not necessary to use federation if all you need to do is modularize your schema. You can pass an array of typeDefs to ApolloServer's constructor instead of a single source. Since the resolver map is just an object, it can be split into smaller objects as well. If you want to split up individual type definitions, like your Query or Mutation or definition, you can use type extension syntax. Using federation or schema stitching just to split up your schema adds unnecessary complexity and overhead to your application.
like-fill
2
  • reply
  • like
There's also libraries out there like this one and this one that can make merging typeDefs and resolvers easier. I think just using type extension syntax is sufficient though. YMMV.
  • reply
  • like

March 18, 2020 at 7:19am
thanks Daniel. I am glad that you pointed out the facts on complexity and overhead! I had a hinch about that so ended up having refactored the code already by now, it out came pretty much exactly what your referring to actually :) In build step I was creating a schema.json file for generating types for typescripting which used buildFederatedSchema in order to do so, for that part I replace buildFederatedSchema with makeExecutableSchema from 'graphql-tools'.
I think it might be pretty easy reading the documentation and fall into this pit using buildFederatedSchema for pure modularization, atleast speaking for me as a total graphql newbie. Personally I went reading > https://www.apollographql.com/docs/graphql-tools/schema-stitching/, realized it was deprecated and thought thats not good. From there I went > https://www.apollographql.com/docs/apollo-server/api/apollo-federation/, which just seemed at the time exactly what I was looking for coming from above.
To me it was not very clear that buildFederatedSchema was not meant to be used for this purpose, only later the doubts came rumbling when getting deeper on federation meanwhile the application started to growing.
Anyway, thanks a bunch! You made me confident about having taken the right approach now!
Edited
  • reply
  • like