Glorious
Urql: a GraphQL client library
71–79 of 79 posts
Re: Urql: a GraphQL client library
#72Does it typecheck queries for you based on the schema, and generate a response type for TypeScript?
No, but you can do something like this: https://formidable.com/blog/2019/strong-typing/
Oh cool, they have a package for urql: https://graphql-code-generator.com/docs/plugins/typescript-u...
I might try it out once it supports the new hooks.
Re: Urql: a GraphQL client library
#73Earlier quoted context omitted.
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 s…
> If an ID is required for all queries the docs should say so.
they absolutely should. It's not really needed every time, but when you have a queries with IDs and without-that's when the cache blows up. They even a have a snapshot test for this unfortunate behavior: https://github.com/apollographql/apollo-client/blob/master/p...
Re: Urql: a GraphQL client library
#74Excited 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.
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.
Re: Urql: a GraphQL client library
#75I really like the simplicity of the core library and this approach of starting from a simple core and building on top of it with the same primitive for extensibility as the one you offer to users. Apollo has also been moving in this direction with composable links, but in a zig-zaggy way since it's still got some baggage from its days as a monolithic library, and recent decisions to move local state management into c…
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
Re: Urql: a GraphQL client library
#76Earlier 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?
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), mobil…
Not using moment will give you back 60k almost three times the savings: 22k
Re: Urql: a GraphQL client library
#77GraphQL 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…
What is GraphQL like in production at scale? It seems like a neat concept but how do traditional web technologies like edge caching work?
It's fantastic at scale for web applications (far better than the REST apis it has replaced since over-fetching isn't a concern). I don't work on content sites or anything where edge caching applies though, so YMMV. (All our static content is served via CDN but API content is not generally cachable).
Re: Urql: a GraphQL client library
#78GraphQL 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…
What is GraphQL like in production at scale? It seems like a neat concept but how do traditional web technologies like edge caching work?
It tips it all on it's head. It's generally a POST request and so doesn't cache at alls (you can configure it with a long GET request). All caching is done client side but at object level, including not requesting fields that you might have already requested previously on other calls.
Re: Urql: a GraphQL client library
#79Earlier quoted context omitted.
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…
Will definitely try it when it comes out.
Quick update: We've just published v1.1 with server-side rendering support! https://github.com/FormidableLabs/urql/releases/tag/v1.1.0