Live data from Hacker News

Urql: a GraphQL client library

formidable.com

11–20 of 79 posts

Re: Urql: a GraphQL client library

#11
post #3

Earlier quoted context omitted.

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

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.

Re: Urql: a GraphQL client library

#12
urql's great, and the maintainers are super helpful and friendly. I've been using it on a project for a couple months now. Very straightforward and plays well with TypeScript. My one criticism is that it doesn't quite do enough in some cases, but I haven't spent the time to learn much about exchanges. As the ecosystem grows, I see this problem going away.

Re: Urql: a GraphQL client library

#14
post #8

GraphQL is amazing. Building an API and then playing around with it in GraphiQl is really a exciting experience. I've played with Relay (relay-modern looks great, but when I needed to pick a graphql client it hadn't been released yet). Apollo is frustrating: it's big and complicated and obsessed with stuff that I don't want (link-state and a bunch of product up-sells). I'm glad urql is getting some more attention and…

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!

Re: Urql: a GraphQL client library

#16
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.

Re: Urql: a GraphQL client library

#19
post #8

GraphQL is amazing. Building an API and then playing around with it in GraphiQl is really a exciting experience. I've played with Relay (relay-modern looks great, but when I needed to pick a graphql client it hadn't been released yet). Apollo is frustrating: it's big and complicated and obsessed with stuff that I don't want (link-state and a bunch of product up-sells). I'm glad urql is getting some more attention and…

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!

Yes, we're already working on SSR support! https://github.com/FormidableLabs/urql/issues/218

Since we didn't want to go down the same road as some other libraries that use renderToStaticMarkup and a promise-queue, we've already built a supporting package so that we can implement SSR-support using suspense. (At least the unstable API of suspense; which is as simple for us as adding throwing promises to our components and hooks) https://github.com/FormidableLabs/react-ssr-prepass

Re: Urql: a GraphQL client library

#20
post #11

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.

> it is expected

It's also expected that my train is going to be late, but we can lament this condition, instead of resigning ourselves to it.

Post reply on HN