Monitoring the uptime of a GraphQL application can't be done by just checking status codes. Asserted lets you write sophisticated uptime tests and even lets you use your client of choice if you prefer.
Example on GitHub
If you are unfamiliar with GraphQL, or just need a refresher on it, I strongly recommend reading through this blog post series. It provides a suitably complicated example to demonstrate most of the features of GraphQL and how you would build a production application with it. I also used modified versions of the code from that post in my example below.
Example Server
The full example GraphQL server (even the simplified version for this example) is too large and complicated to be completely shown here. I recommend cloning the repo to take a look at the code, but I'll include snippets where I can.
The core of this example is a books model that has associated authors and publishers. The book-related type definitions can be seen below.
These are handled by the book resolvers.
And the resolvers connect to the book service, which is too large to include here.
The server itself is just a straightforward ApolloServer. I did not include any authentication in this example in the interests of simplicity, but you can see that in the Node API post.
Routine Configuration
As with the Node API example, the GraphQL routine doesn't require any special dependencies, so just the fixed dependencies are used.
If you wanted to include an Apollo client in the tests, or some other GraphQL specific libraries, you would need to upgrade to a paid plan to use the custom dependencies.
Continuous Integration Tests
In these tests we do not have any special environment variables that we need to load, and we're just using the got client to execute our requests.
We create a unique book name at the beginning of the test, just to ensure we don't conflict with other books that may already exist in our theoretical production system.
All of the tests we wrote can be seen here, but I'll list a few specific examples.
This test uses a more sophisticated query to get all of the other books written by a specific author.
By being able to write arbitrarily sophisticated queries, you can deeply test all of the resolvers in your API.
Beyond just queries, we can create, update, and remove books as well.
By adding before and after hooks, we could further ensure that anything created during the test is wiped from production before the test exits.
Next Steps
While the example shown here can be cloned and run locally without an account, you'll need to do a few extra steps if you want to create your own Asserted routine to integration test your API in production.
Top comments (0)