I'm used to refetching graphql fragments on Relay and was wondering when it would make sense to refetch its root query instead. This may be graphql client-agnostic but I'm not familiar with any other clients. Thank you.
Related
I have a GraphQL api implemented with Nexus-graphql and Prisma + Postgres.
Prisma has a nice solution for N+1 issue with query batching when it comes to GraphQL but seems to be working on 2 levels of nesting, e.g. User -> Posts, but when we need multiple levels of GraphQL nesting (User -> Posts -> Comments -> Likes -> Users) it seems to execute hundreds of queries.
What are the general best practices for doing query optimization in such cases?
I have 2 ideas but maybe there are more:
Using prisma's "include" option. Construct a map of prisma relations based on the received graphql query (from "info" field) and query all the relations at once in a single query.
Using a dataloader, query all necessary data and save to dataloader and within the resolvers load models from dataloder.
Does the GraphQL spec say something about mutating data in a GraphQL subscription or are there any best practices/pros/cons about this topic? (same applies to data mutations in query resolvers...)
With graphene-django when documenting e.g. GraphQL object type classes the docstrings are usually used to autogenerate documentation which is visible in GraphiQL. This should also work with plain graphene-python and all graphene-python based implementations like graphene and graphene-mongo as well. But the docstrings used for resolver functions of queries is not used to autodocument Queries. How can I document queries with docstrings?
I want my React web app to receive messages using AWS AppSync subscriptions for mutations that are computed asynchronously, based on mutations to types other than the type the client originally submitted a request to mutate. For example, if a user casts a "vote", I want the server to respond immediately, but the server should also send clients the aggregations of the overall database that might take extra time to compute or can be computed at a slower rate.
I assume AppSync will notify clients if they make a Graphql subscription, lets say, to the type "Aggregation".
Q1. Will a web client receive a message for the Aggregation subscription if I write a server-side client that writes the Aggregation mutation to the AppSync API EVEN after the client received a response from the original vote request?
I assume I will need to make a server-side Graphql client to write the aggregation mutation. I guess this is as simple as a http client.
Q2. How can I trigger the code that computes the aggregation when at least one user has submitted a mutation (vote)? My best guess is that I need to use a Lambda Function to handle the original mutation (vote), but before responding to the web client, it will start another process (maybe a different Lambda Fn) which will eventually mutate the aggregation.
I have not yet integrated the Apollo client so I'd like to keep the web client side code simple for now.
If I understand your question you want to something to kick off the aggregation process and then get a subscription message when there's a new aggregate. To kick off the aggregation you could use any number of things depending on where you're storing your data. For example, if you're using DynamoDB you could use DynamoDB streams to kick off an aggregation when there's a change to vote. Or, like you said, you could kick off a lambda or another process in response to the subscription message to vote. Any of these solutions would need to make a mutation to write the aggregate which will result in a subscription message to clients subscribed to Aggregation.
What is the recommended way to check for username / email availability? Should I use mutation or query?
According to the official definition of Mutation.
If you have an API endpoint that alters data, like inserting data into a database or altering data already in a database, you should make this endpoint a Mutation rather than a Query.
In the case of checking for availability it does not change or create any data, so it should be a Query.