Urql: a GraphQL client library
formidable.com
Urql: a GraphQL client library
1–10 of 79 posts
Re: Urql: a GraphQL client library
#2Have 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.
Re: Urql: a GraphQL client library
#3Have 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?
Re: Urql: a GraphQL client library
#4Have 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?
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.
Re: Urql: a GraphQL client library
#5We use Urql and are loving it at Thread. Nice and lightweight, easy to use, easy to build our own infrastructure around.
Re: Urql: a GraphQL client library
#6Excited 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.
Re: Urql: a GraphQL client library
#7This is refreshing upon first glance. The Apollo Client docs are such a mess.
Re: Urql: a GraphQL client library
#8GraphQL 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'll definitely give it a spin.
Re: Urql: a GraphQL client library
#9I _really like_ the implementation with hooks. I experimented with a similar pattern on top of Apollo on a side project. Going to play with urql today! Thank you!
Re: Urql: a GraphQL client library
#10Have 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?
From recent bundle audits of e-commerce sites built with React, less than 20% of the code was actual custom site code and the remaining 80% was from dependencies.
If the bundle size is 550kb min/gzipped, that's 110kb of app code, and 440kb of dependencies. Some of the largest dependencies in a recent audit were: moment (60kb), swiper (32kb), lodash (24kb), react-select (26kb), raven.js (12kb), polyfills (25kb), mobile-detect (15kb), and then a bunch of smaller dependencies that made up the remaining 300kb.
Using this performance budget calculator you can quickly see how each 25kb of JS adds ~.3s to your TTI on a mobile phone:
https://perf-budget-calculator.firebaseapp.com/
If developers shop around for smaller alternatives of each dependency, then they can cut their load times pretty drastically.