Mutations don't have the really clear advantages that queries do (compared to their REST counterparts), but the one thing that I think does make them worthwhile is that you get the cache updates/re-renders based on the mutation result (instead of needing to re-fetch data or whatever to get your UI to update).
True, but then I'm using the subscriptions model that Hasura provides, so in my case the UI update is actually automatic, its just initiated by Postgres triggers instead of cache (so a bit slower, but still fast enough)
How have you found the performance / resource usage of widespread usage of Hasura subscriptions. We're using them in a few key places, but have been reluctant to rely on them too widely because it seems that they are actually based on the polling the query every second.
Comments
Mutations don't have the really clear advantages that queries do (compared to their REST counterparts), but the one thing that I think does make them worthwhile is that you get the cache updates/re-renders based on the mutation result (instead of needing to re-fetch data or whatever to get your UI to update).
True, but then I'm using the subscriptions model that Hasura provides, so in my case the UI update is actually automatic, its just initiated by Postgres triggers instead of cache (so a bit slower, but still fast enough)
How have you found the performance / resource usage of widespread usage of Hasura subscriptions. We're using them in a few key places, but have been reluctant to rely on them too widely because it seems that they are actually based on the polling the query every second.
Traffic for my service is too low to say for sure yet, but the hasura docs seems to indicate that it could be quite scalable: https://github.com/hasura/graphql-engine/blob/master/archite...