Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Urql: a GraphQL client library

formidable.com

Post reply on HN
Print view View original

21–30 of 79 posts

Re: Urql: a GraphQL client library

#21

Post by underbluewaters »

peggyrayzis wrote: post #16
yodon wrote: post #6

Excited to see some competition for Apollo. Apollo may do lots of things but exactly what and why and how remains a mystery to me. Apollo just feels needlessly large, opaque, and inadequately documented to me. Reading about urql, the combination of minimalist architecture with first class support for React hooks sounds like just what I'd been hoping would emerge.

Hi from Apollo! We appreciate your honest feedback. Part of my team (Developer Experience) is responsible for our documentation. What features are inadequately documented? We'd like to fix that for you if we can.

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.

Re: Urql: a GraphQL client library

#23

Post by svachalek »

peggyrayzis wrote: post #16
yodon wrote: post #6

Excited to see some competition for Apollo. Apollo may do lots of things but exactly what and why and how remains a mystery to me. Apollo just feels needlessly large, opaque, and inadequately documented to me. Reading about urql, the combination of minimalist architecture with first class support for React hooks sounds like just what I'd been hoping would emerge.

Hi from Apollo! We appreciate your honest feedback. Part of my team (Developer Experience) is responsible for our documentation. What features are inadequately documented? We'd like to fix that for you if we can.

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.

Re: Urql: a GraphQL client library

#24

Post by RossDM »

methyl wrote: post #11
helloguillecl wrote: post #4

Earlier quoted context omitted.

It does incrementally make a difference. You want all your libraries to stay under a certain budget if you don't want to hit your users with a 500 KB bundle size. It is not only about how long it takes to download, it is also about parsing that amount of code in low end phones.

> if you don't want to hit your users with a 500 KB bundle size. Still I do think if you are building a web application (and not a static site or a blog) it is expected it can take a second or two to load it for the first time. 500 KB bundle is nothing wrong in that case.

18% of the Alexa Top 10K sites grew by 1MB+ from July 2017 - July 18. (source: https://twitter.com/katiehempenius/status/113320912700037939...)

Ignoring the impact of libraries you send to the frontend will lead to death by a thousand cuts.

Re: Urql: a GraphQL client library

#26

Post by alexrage »

peggyrayzis wrote: post #17
alexrage wrote: post #7

This is refreshing upon first glance. The Apollo Client docs are such a mess.

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?

A more consistent documentation experience. A lot of code examples import various modules, but those modules have no documentation. For example: Docs > Client > Apollo Link mentions `graphql-tools` and schema stitching, with a link to read more. Clicking that link takes you to a page that says it's deprecated, and then links to a blog post about why.

Another example: Is `apollo-link-state` deprecated? The docs for `apollo-link-state` don't mention that, but the Local state management page in Apollo Client sure says it is.

Re: Urql: a GraphQL client library

#27

Post by methyl »

RossDM wrote: post #24
methyl wrote: post #11

Earlier quoted context omitted.

> if you don't want to hit your users with a 500 KB bundle size. Still I do think if you are building a web application (and not a static site or a blog) it is expected it can take a second or two to load it for the first time. 500 KB bundle is nothing wrong in that case.

18% of the Alexa Top 10K sites grew by 1MB+ from July 2017 - July 18. (source: https://twitter.com/katiehempenius/status/113320912700037939... ) Ignoring the impact of libraries you send to the frontend will lead to death by a thousand cuts.

How many of those Top 10k Alexa sites are full-blown web applications that need GraphQL in the first place?

Re: Urql: a GraphQL client library

#28

Post by yodon »

peggyrayzis wrote: post #16
yodon wrote: post #6

Excited to see some competition for Apollo. Apollo may do lots of things but exactly what and why and how remains a mystery to me. Apollo just feels needlessly large, opaque, and inadequately documented to me. Reading about urql, the combination of minimalist architecture with first class support for React hooks sounds like just what I'd been hoping would emerge.

Hi from Apollo! We appreciate your honest feedback. Part of my team (Developer Experience) is responsible for our documentation. What features are inadequately documented? We'd like to fix that for you if we can.

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.

Re: Urql: a GraphQL client library

#29

Post by itsangaris »

methyl wrote: post #3
mxstbr wrote: post #2

Have been playing around with urql on a project for a couple of months now, mainly due to the small bundle size. Urql is 7.5kB min+gzip, where Apollo and Relay add ~30kB min+gzip! Great to see Formidable investing further in it, I am very excited to see first class extensibility.

> 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?

When talking about a few kilobytes, it’s less the download time than the parse time that’s the main performance concern.

Re: Urql: a GraphQL client library

#30

Post by gorgonian »

peggyrayzis wrote: post #16
yodon wrote: post #6

Excited to see some competition for Apollo. Apollo may do lots of things but exactly what and why and how remains a mystery to me. Apollo just feels needlessly large, opaque, and inadequately documented to me. Reading about urql, the combination of minimalist architecture with first class support for React hooks sounds like just what I'd been hoping would emerge.

Hi from Apollo! We appreciate your honest feedback. Part of my team (Developer Experience) is responsible for our documentation. What features are inadequately documented? We'd like to fix that for you if we can.

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.

Post reply on HN