Re:GraphQL is quickly moving to one of my least favorite tec...
by soulchild77 on Saturday July 30, 2022 @02:17AM
(#32284710)
We're happy users of react-query[1]. Its stale-while-revalidate approach makes Redux and Co. unneccessary for most use-cases.
If you have an OpenAPI spec of your REST API you can auto-generate a react-query based frontend client with Orval[2]. Works pretty well, but probably takes a bit more time to set up.
Re:GraphQL is quickly moving to one of my least favorite tec...
by ishjoh on Monday August 01, 2022 @11:04AM
(#32306980)
Thank you, react-query is one of the solutions we were looking into, glad to hear there are happy users of it.
One thing I like about the apollo client is that it handles a lot of the cache invalidation for you, where as react-query it seems to be a bit more of a manual process, how are you and your team handling cache invalidation?
Re:GraphQL is quickly moving to one of my least favorite tec...
by soulchild77 on Tuesday August 02, 2022 @09:16AM
(#32318089)
react-query indeed doesn't automatically take care of this. We manually invalidate its caches (based on the query key, so you only ever invalidate what has changed) after a mutation happens. It's not as bad as it sounds because most of the time it's just one line of code.
On the BE it's not great, harder to reason about than REST and harder to manage. It's also harder to monitor than traditional REST, since REST makes use of a full range of http header codes (the graphql server we used only used http header 200 by default, we have modified this).
What I recently learned is that the apollo client has support for REST APIs, this is a path that seems interesting to me. We've also been looking at FE libraries for REST that have similar interfaces to the apollo client, if you have suggestions please let me know.