I’m wondering, what is the best way to test the gateway server.
Should I mock the downstream services responses to test my didReceiveResponse implementations (where headers transfer magic happens) to make sure that the newcomers did not break this sensitive part of my gateway? And vise-versa for willSendRequest.
Please share who did what on this topic, or maybe links to useful use-cases (apollo-server testing docs are not about gateway as I understand them).
From our experience, keeping the gateway as “dumb” as possible worked pretty well. You could add unit tests around the general server setup (header, config, etc) and keep the gateway as its own server. Onboarding new services should not require a change to the gateway if you are using managed federation.
For testing responses, each federated service should have its own Unit, Integration, and E2E tests for the queries it owns, and the E2E tests can be run against the gateway’s test/stage endpoint.
When it comes to making sure new services (or changes in existing services) don’t break existing schema, setup schema checks using Rover CLI. Rover commands for schema check and push should be integrated into each federated service’s CI pipeline so that breaking changes are not pushed to the registry. If you aren’t using managed federation, check out GraphQL Inspector.
Yes, this is helpful!
That is a great idea to keep the gateway as “dumb” as possible. But is there another way (without extending the RemoteGraphQLDatasource) to implement set-cookie headers transferring from federated services to the client?
I am not aware of other ways to set up a gateway other than extending the RemoteGraphQLDataSource if you want to customize the connection from the gateway to other federated services if you are using the Apollo Federation model.
One way you can test that your Gateway is adding the right headers to the response is, in your E2E test, (depending upon the framework you use), you can “get” the headers from the response and assert them against the expected header key-value pairs. Note that these E2E tests will be within a federated service’s codebase, the gateway itself doesn’t have to add any tests for these assertions.
