I've used GraphQL and Hasura extensively for my project (https://pagewatch.dev) and it has been a huge timesaver to get a realtime service up and running. BUT, I'm still using REST for mutations (The POST/PUT part really).
At least for my use case I find that almost every time you are modifying data there is some other component also involved (eg starting a background task), so it might as well be a REST server endpoint. (Also I find the mutations language of GraphQL is really the weakest/hardest to really understand part)
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.
You can put your REST API endpoints into Hasura through Actions. All you have to do is define an input and output GraphQL type for them, and give it the endpoint URL.
Then you get the benefit of a single, unified GraphQL API and can use Hasura's authorization model + connect the output fields back to the rest of the graph if you need.
Comments
I've used GraphQL and Hasura extensively for my project (https://pagewatch.dev) and it has been a huge timesaver to get a realtime service up and running. BUT, I'm still using REST for mutations (The POST/PUT part really). At least for my use case I find that almost every time you are modifying data there is some other component also involved (eg starting a background task), so it might as well be a REST server endpoint. (Also I find the mutations language of GraphQL is really the weakest/hardest to really understand part)
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...
You can put your REST API endpoints into Hasura through Actions. All you have to do is define an input and output GraphQL type for them, and give it the endpoint URL.
Then you get the benefit of a single, unified GraphQL API and can use Hasura's authorization model + connect the output fields back to the rest of the graph if you need.
https://hasura.io/docs/1.0/graphql/manual/actions/index.html
https://hasura.io/blog/introducing-actions/