orval
orval copied to clipboard
anymaniax
Integration with normalizr for normalized caching
Copying much of my comment from a react-query discussion:
Many teams choose between GraphQL+Apollo or REST+react-query for their server/client architecture. One of the biggest selling points of graphql+apollo is the normalized caching.
For example, if you update your profile or name, the change should be reflected everywhere in the app without refetching, even if the data is nested within other api resources. When the app doesn't automatically update everywhere to reflect new information, it looks broken to the user.
To get that benefit with REST today, you have to do a lot of complicated and ugly manual stuff with redux/mobx – very bug-prone in my experience.
Context
When I worked at Stripe, I helped build a solution that made REST at least as nice to use as GraphQL. It autogenerated a function for each operation in our internal openapi spec, complete with types for params and responses, and a normalizr schema for the relations within our app for automatic normalized caching.
Having the cache work in a consistent/automated way kept the system relatively predictable, and each use of a query/mutation had to specify whether it should use the cache, which was a simple solution to the general problem of dealing with caching bugs.
In other words, we built an internal react-query+orval (they didn't exist yet) and it included this feature, which proved to be an extremely useful feature.
Motivation
Once you can get autogenerated and auto-caching query functions for all your backend methods, there will be very few advantages of GraphQL over REST for browser development; it would be a big selling point for teams choosing how to build their API.
How
For orval to do this, I think it would need to generate a normalizr schema for the openapi spec, and then add a caching version of each hook, which runs normalize() over each response and queryCache.setQueryData as described here.
Users may need to augment their openapi specs to indicate field relations; at Stripe, sub-resources generally referred to full components, which made it easy.
Hello @rattrayalex, it's a cool idea but I will need more context and your help to do it. I saw the example in the react-query discussion but that's not really complete. They only take the users entity what would you do if there is more than one entity. Could you maybe do a more complex example. It will help us to a discussion about the possibility and the way to do it.
Going to close this as no updates in 2 years. Will reopen if discussion is restarted.
