Cheers! I'm happy to say that a normalising cache is indeed in progress and we're planning to finish it soon https://github.com/kitten/urql exchange-graphcache

We've got the cache itself done but are just figuring out the API for its customisability in terms of cache resolvers and such

> Urql is 7.5kB min+gzip, where Apollo and Relay add ~30kB min+gzip!

How is that 22.5kB making any difference? Unless you are working on a project that will be used on very slow connections I see no point in choosing a library basing on such small difference in size. And if you really are targeting those slow connections then maybe going SPA is not the best choice?

> this project closes the gap between GraphQL and mobx-state-tree as state management solutions. GraphQL is very transport oriented, while MST is great for client side state management. GraphQL clients like apollo do support some form of client-side state, but that is still quite cumbersome compared to the full model driven power unlocked by MST, where local actions, reactive views, and MobX optimized rendering model be used.

MST and GraphQL together does sound like a pretty serious win

I was just looking for a smaller/simpler graphQL client. But I cannot try this yet as I need SSR (I'd need to remove SSR from my app in order to implement this library)

I hope SSR support is included soon!

What is GraphQL like in production at scale? It seems like a neat concept but how do traditional web technologies like edge caching work?

I’m also interested in exploring exchanges.

Hi from Apollo! My team (Developer Experience) is responsible for making sure you can find what you need in the docs. What improvements would you like to see?

No, but you can do something like this: https://formidable.com/blog/2019/strong-typing/

I clicked the article link just because I was expecting to see this guy: https://en.wikipedia.org/wiki/Steve_Urkel#/media/File:Steve_...

Yes.

we've been using apollo with vue.js (and typescript!) with a django-graphene backend and we've been having zero problems.

honestly, it's my favorite stack nowadays.

> Can I use urql with Vue.js

Would like to know this also.

The issue is not that there is a simple feature that's inadequately documented. It's that I have no high level understanding of what all the pieces are and how they fit together. Tell me exactly what I'm getting from Apollo that I don't get from fetch. Tell me what caching does, when, how, and how to invalidate it. Tell me about links and middleware. This is a very complex batteries included technology. I don't even feel like I understand where the batteries go, much less what they are doing for me, I'm just copying and pasting code that others have used into my projects and hoping I have about the right amount of stuff included.

Your customer didn't write all the Apollo code. The docs feel like they are written with the assumption that we understand the architecture and goals as well as you do and we just want to do some simple task with it to get started. I fear however that this is fundamentally not a docs problem. It feels like a problem where the Apollo devs didn't start by asking "how can I build something that will be easy for 3rd party devs to use and understand", they started with "oooh that would be cool". Urql feels like it started with a very simple and clear conceptual foundation that provides a clear roadmap for how and where more complex features get attached.

If you can reduce Apollo down to a clear and simple framework in the docs that actually covers everything that it does, then you're golden. I suspect however that the underlying architectural simplicity that would be required for you to do this doesn't actually exist. If it does, you face a docs problem, if it doesn't, then docs are just a bandaid.

https://www.apollographql.com/docs/react/api/apollo-client/ is pretty terrible all around.

As a trivial example look at the documentation of client.query(), the most fundamental function. It lists the options for `errorPolicy` and `fetchPolicy` but doesn't explain them. The links lead nowhere (that's true for at least half the links on that page). You have to remember where to find that the Apollo React documentation instead. `fetchResults` is described like something that sounds like a boolean, but for some reason it has the type any. `metadata` is described so vaguely that I have no clue what it does. `query` is unhelpfully described as being of type `DocumentNode`. I'm left to guess that a gql string propably results in a DocumentNode, but I'm not sure everyone makes that deduction. `variables` is pretty much the only decently described parameter.

And that's for the simplest function. Just below that the `subscribe` function has a fetchPolicy parameter without giving any idea how fetchPolicies interact with subscriptions (how does a "cache-only" subscriptions work???). And I really hope I never want to directly use an ObservableQuery class, 7 of 11 members don't even have a description.

The documentation for the react stuff is mostly fine, but once you have to go beyond that you are on your own and end up reading source code to figure anything out.

I am enjoying using apollo, it's hard to explain but at the beginning the language of the docs seems foreign (think apollo link) and the site feels huge, it's not a particular problem just more a matter of the feeling /impression it gives. Uninviting and intimidating is the words that come up.

Vue's documentation is a good example of the opposite, it feels friendly an accesible, it has a nice flow to it. Apollo has the opposite feeling even though everything seems to be documented and everything is explained.

Probable more an organization and presentation issue than a content issue.

Just my 2c.

I've often found the react-apollo docs in particular confusing. They often rely on opaque type definitions to describe argument formats. For example, it took me a long time to understand what to pass to the `refetchQueries` argument of a Mutation component. A set of examples for common scenarios would be helpful.

I agree with other commenters that Apollo is too big and too opaque to easily understand. The docs don’t have enough examples and are out of date in some places (see link-state). I’ve had a lot of confusion while trying to implement Apollo in my current react project.

I’ve also seen some erratic behavior from Apollo. While testing I found that Apollo deduplicates queries too aggressively. I made some mutations with slightly different inputs (think naming a new item “a” and another one “b”) and several of them would not get sent. In my example it would have resulted in two new items on the server but instead only one was created, because the second mutation wasn’t sent.

I also found that using the `called` flag in a mutation function child was basically useless because sometimes it would be false even if the mutation went through. I switched to using the onCompleted prop in the component and that’s worked.

Another thing I ran in to is that Apollo sometimes can’t update the store because I sent a query without an ID field. It throws an error. If an ID is required for all queries the docs should say so.

Also I don’t think the docs say that you should return any fields you update in a mutation, to make sure the store is current. I think I found that out on stack overflow.

- The `Query.variables` prop. The docs don't explain very well when exactly the network call will be reinvoked, especially if the graphql query has variables with default values (there's an open issue about this with little activity: https://github.com/apollographql/react-apollo/issues/2715).

- The `Query.skip` prop. I'd like to know all of the expected behavior for when this prop is used. For example, I've noticed that when skip is true then the render prop function's `data` object is always undefined, even though the data is there! Also when skip is true and you manually trigger a refetch elsewhere (for example when running a mutation with `refetchQueries` specified), the `onCompleted` prop doesn't get called, even though the query was in fact refetched and completed.

Those are just recent things I've noticed. Also for the record I don't mean to sound like I'm throwing shade. I appreciate all open source work and the Apollo projects are massive open source contributions, so thank you :)

I've also recently started using Apollo client. The basic usage was pretty straightforward (although either I don't understand something about the loading flag or it just doesn't work very well). But in dealing with the loading flag issue I ended up writing middleware and there's a whole lot of types involved, links and middleware and afterware that seem needlessly complicated (why is middleware and afterware different, why does it seem like it's reinventing either Rx or Promises instead of just using one), compared to Redux middleware which is trivial to understand, write, and use and does basically the same thing as far as I can tell.

Possibly this is just a doc issue but it seems like the API could benefit from some streamlining.

Hi, I'd love to see an example for links that showcases how links could interact with React state/props.

For instance, in the 401 logout example (https://www.apollographql.com/docs/react/advanced/network-la...), it imports a logout function from a separate module to call on 401, but I'd like to ideally have 401s trigger a change in some React state instead (possibly by passing through a state changing function as a prop to Apollo's Provider component?), and it's not entirely obvious to me from the docs how one would accomplish that.

At work, we are a fairly established company with an existing codebase. We don’t use Apollo React, simply the client and Apollo explorerer. I would like better documentation for the vanilla client.

Personally, I have no trouble with it’s usage since I have been dealing with it for 2 years, and I keep up with the GitHub changesets but new devs have a harder time on boarding since all the links on the site seem to lead to a framework specific documentation.