Versioning your schema is a whole different beast!
AFAIK, GraphQL still maintains its stance on “don’t version, just deprecate certain fields”. So, if you have an
Animal object that you promote to an interface, you’d have to keep all the fields on the interface to not break client APIs. But, you’d mark fields like
Nah, I’d probably change the business logic so the client doesn’t request things that don’t exist, but again, depends on the app. For example, User A is on a team dashboard. User B removes her from the team. Use subscriptions to tell User A that she was removed & remove her from the dashboard since we know any request from there will fail.
Good question! Personally, I don’t have a single query that could fail due to user input. So if a query fails, it’s because a developer made an error, which means a friendly message isn’t required, so I don’t wrap em.
YMMV. For example, maybe a user can request a document that may or may not exist & if it doesn’t exist…
Oh the joys of tech debt :-)
Currently, we don’t use redux for any domain state, that’s 100% relay. I’ve also removed it from most of the local state management except for 2 areas: toast alerts & redux-form. I’d love to refactor those, but just haven’t had the time.
Apollo Engine caches query results, data-loader caches the lookups that compose the result.
For example, let’s say you’re building SliceLine and a customer orders a pizza with 5 toppings:
Oh man, that’s a difficult one that’s definitely client cache dependent. Since Relay’s compiler makes full use of babel, having a fragment that’s built at runtime is difficult. I can say that whenever I feel the urge to copy/paste a fragment, it means I haven’t colocated my data down to the correct child component or it’s even a smell that I need an…
You’re absolutely right, crazy how fast the ecosystem is growing! I currently use https://github.com/jimkyndemeyer/js-graphql-intellij-plugin & it does a fantastic job of statically analyzing my Relay queries. Pretty great stuff!
Only downside is that it must take in a single graphql json, so I still have to do a query introspection when it changes.
MDG did a really good job of breaking Apollo into sensible chunks. I’d use the client, but I need to manage the socket externally and I want the opId in the socket event, not payload; small stuff. I’ll trade simplicity for power, so I’m not their target demographic. I do use graphql-redis-subscriptions on the backend & it works well.