mercurius: Federated schema is not merging Queries and Mutations

Hello,

trying to define federated schema like this, but only last service Queries and Mutations are show in final schema. If I change order of services, it will always generate only last one (Types get merged though). Any ideas what can be wrong? I am using apollo federation and it is merging correctly, I would love to move to fastify-gql as you guys are supporting subscriptions and it seems like there should be performance boost.

Another thing, is there a way to define different route for http://…/graphql and websockets ws:/…/ ?

const Fastify = require('fastify')
import GQL from 'fastify-gql'

const gateway = Fastify()
gateway.register(GQL, {
  graphiql: 'playground',
  subscription: true,
  gateway: {
    services: [
      { name: 'user', url: 'http://localhost:5020/graphql' },
      { name: 'contest', url: 'http://localhost:5000/graphql' },
      { name: 'event', url: 'http://localhost:5010/graphql' }
    ]
  }
})

gateway.listen(4001, '0.0.0.0').then((d) => {
  console.log(`Server listen on ${d}`)
})

About this issue

Original URL
State: closed
Created 4 years ago
Comments: 28 (1 by maintainers)

Most upvoted comments

@voslartomas I haven’t seen that error before, it might be interesting to see what’s the concrete error here (coming from the concrete service), can you log the full data object here, please: https://github.com/mcollina/fastify-gql/blob/master/lib/subscription-client.js#L165

Also, in regards to Apollo Engine (or whatever it is called today), this is actually one of the reasons we’re moving away from Apollo. It’s more a philosophical view, than a pure technical one & I’m not in a position to judge some of the decision taken in Apollo in regards to implementations in apollo-server.

Once you’re trying to do Federation “seriously”, you might run into some problems that get increasingly harder to solve with the current direction Apollo is heading in. F.e. changing a schema at runtime, starting the federation with one of the Federated service not being available at startup & then joining the federation later, not using HTTP/WS based communication between services, not to mention subscriptions… etc.

We’re currently jumping through lots of burning rings to make this work with Apollo, need to throw a lot of (self written/maintained) boilerplate code at it to make it work & most of the time, it feels like fighting the framework which is supposed to help us with those things. We can’t use Apollo-Engine due to security contraints of our corp & a lot of those features within Apollo are build to work with Apollo Engine exclusively.

I do understand that Apollo is a company & that providing that Saas platform is their way of generating money, which then also is used to fund the work on their libraries. All fine, just not a model that works for us.

I’m currently working on a self-hosted solution for schema management, which should work with fastify-gql (not released & not ready for primetime yet) & partly solves the same issues as Apollo-Engine does. Also one of the reasons why our transition from Apollo to Fastify takes some time.

asciidisco on Jul 17, 2020

@paolochiodi

1.) If you apply the “fix” (or workaround, what you prefer to call it) mentioned here it should work. So yes, it’s a known bug & afaik. due to the reasons discussed in #184 there’s no PR for it yet. Basically waiting for more information to not release a fix which could have some unforseen implications.

asciidisco on Jul 17, 2020

Unfortunately I don’t have any idea how fastify or this plugin works, I just randomly find that this might be another solution instead of using apollo server.

voslartomas on Jul 17, 2020