are mutations possible with Apollo Federation?

[squarewave24]

I am not clear if this is the right pattern, but i am using Apollo Geteway with my react app connecting to python api's using graphene.

all queries work fine, but when trying to use a mutation i git this generic error below.

the query works when i paste it into the endpoint graphql playground, but not from apollo geteway playground :(

query:

mutation review{
  review(my_date:"2020-06-02")
  {
    success
  }
}

error:

"error": {
    "errors": [
      {
        "message": "Schema is not configured for mutations.",
        "locations": [
          {
            "line": 1,
            "column": 1
          }
        ],
        "extensions": {
          "code": "INTERNAL_SERVER_ERROR",
          "exception": {
            "stacktrace": [
              "GraphQLError: Schema is not configured for mutations.",
              "    at Object.getOperationRootType (/Users/rafal.buch/dev/ground-control/node_modules/graphql/utilities/getOperationRootType.js:28:13)",
              "    at Object.buildQueryPlan (/Users/rafal.buch/dev/ground-control/node_modules/@apollo/gateway/src/buildQueryPlan.ts:80:20)",
              "    at Object.ApolloGateway.executor (/Users/rafal.buch/dev/ground-control/node_modules/@apollo/gateway/src/index.ts:659:19)",
              "    at processTicksAndRejections (internal/process/task_queues.js:97:5)"
            ]

versions:

"@apollo/gateway": "^0.16.2",
"apollo-server": "^2.14.1",
"apollo-server-express": "^2.14.1",

graphene==2.1.8

[EE1234EE]

@squarewave24 Have you found a solution? PUSH PUSH

[abernix]

Yes, they are supported. In the same/similar way that services/subgraphs should extend type Query to expose top-level entry-points into the API schema (that's exposed to the client), the subgraphs/services need to extend type Mutation with the fields they want to expose:

For example, following the example above, one of the subgraphs would:

type Result {
  success: Boolean
}

extend type Mutation {
  review(date: String review: String): Result
}

This would result in a review field being on the root-level Mutation gateway on the Gateway.

Looking at the error message in the original post, it appears that none of the services in the graph have utilized extend type Mutation therefore no Mutation type is present in the composed graph (types cannot have no fields), and therefore the schema is refusing to serve any mutations. Extending the Mutation type as I've suggested above should do the trick.

Hope this helps!

[khaledosman]

right but you can't extend the review mutation between multiple services.
i.e in case of a bidirectional relationship between a post and a comment

a createComment mutation needs to both

1. Update the commentService's DB with the new comment and store a reference to the postId incoming from the request.
2. Update the postService's DB to store a reference for the new commendId inside the related post document.

Currently only the first step is doable with federation, I think I need to use a message queue between the microservices or a Saga pattern to achieve that goal

[iamfotx]

Hi @khaledosman, I'm facing the exact same problem. Can you please lemme know, how did you end up solving the problem? Thanks

[khaledosman]

Hi @khaledosman, I'm facing the exact same problem. Can you please lemme know, how did you end up solving the problem? Thanks

I haven't yet I was just doing a POC, the simple solution would be to rely on a Saga architecture with a message broker between the services that handle entity updates to update the reference in the other service's db, however its also not ideal on a big scale when you have to do this for all entities at scale, think of rollback scenarios if the reference update failed in the db, etc.. but the other service already saved it, it feels like you'd be sending messages for each mutation that creates/updates/deletes an entity.. So the ideal solution seems to push me more towards CQRS & full Event sourcing architecture, however that comes with alot of complexity, risks and requires more effort and a completely different architecture. My only advice is to not rely on synchronous communication between your services such as (graphql, grpc or http) since its an anti-pattern in a microservice architecture.

Another solution is to maybe rely on data replication, i.e whenever the comment service db has changes, it publishes these changes to kafka or some message broker or whatever, and the listener service constructs its own version of the database from it in whatever data format it needs, that way the services are still loosely coupled, and have all the data they need, but then you need to think of how you would do the replication architecture in itself. microservices are hard.