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

61–70 of 79 posts

Re: Urql: a GraphQL client library

#61

Post by dang »

priceytomato292 wrote: post #59
DrFell wrote: post #55

GraphQL is a technology only a frontend webdev could love. You really want the burden of understanding the database schema and building the JS framework app? You really want ad-hoc data models written in some weird 'query language' littered throughout your frontend code? Building an API is actually easy, if you bother. 'No! GraphQL is lit!' OK kid, have fun snicker .

That's just moronic, I would even go as far that GraphQL is something only backend dev could love, the only benefits frontend dev gain using GraphQL is not having to wait on backend dev to change some random endpoint response. From a backend dev perspective GraphQL completely removes that chunk of work, solves the issue of over-fetching/under-fetching, and more importantly allows you to map your REST APIs into a sing…

When disagreeing, please reply to the argument instead of calling names. "That is idiotic; 1 + 1 is 2, not 3" can be shortened to "1 + 1 is 2, not 3."

https://news.ycombinator.com/newsguidelines.html

Re: Urql: a GraphQL client library

#62

Post by huy-nguyen »

philplckthun wrote: post #19
helloguillecl wrote: post #14

Earlier quoted context omitted.

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…

Will definitely try it when it comes out.

Re: Urql: a GraphQL client library

#63

Post by huy-nguyen »

scyclow wrote: post #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.

I’m also interested in exploring exchanges.

Re: Urql: a GraphQL client library

#64

Post by lewisl9029 »

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.

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.

Re: Urql: a GraphQL client library

#65

Post by DrFell »

priceytomato292 wrote: post #59
DrFell wrote: post #55

GraphQL is a technology only a frontend webdev could love. You really want the burden of understanding the database schema and building the JS framework app? You really want ad-hoc data models written in some weird 'query language' littered throughout your frontend code? Building an API is actually easy, if you bother. 'No! GraphQL is lit!' OK kid, have fun snicker .

That's just moronic, I would even go as far that GraphQL is something only backend dev could love, the only benefits frontend dev gain using GraphQL is not having to wait on backend dev to change some random endpoint response. From a backend dev perspective GraphQL completely removes that chunk of work, solves the issue of over-fetching/under-fetching, and more importantly allows you to map your REST APIs into a sing…

If you're a backend dev that makes APIs, you probably won't like GraphQL (I am not one of those, BTW). If you have a big project with a team split into API devs and app devs, and you have to wait, then that is poor planing. Plus, just wait, jeez. Don't blame the separation of the work into roles for your problems, it is usually good, and often necessary. Then again, if you're full-stack developer, you can just go fix the endpoint yourself.

I know the argument about over-fetching with an API is that you have to make one call, than loop through and make secondary calls, but you can mitigate that, it is rare, and is actually fine. Ad-hoc data modeling encourages over-fetching in it's own way. You always make in-situ calls for exactly the model shape you need right there. "That model is not quite the shape I want, I will do another query." Plus, with pre-defined data models you can save them, in like a state object, they are more reusable. You can even use them in a totally different program.

Re: Urql: a GraphQL client library

#66

Post by DrFell »

tdy_err wrote: post #56
DrFell wrote: post #55

GraphQL is a technology only a frontend webdev could love. You really want the burden of understanding the database schema and building the JS framework app? You really want ad-hoc data models written in some weird 'query language' littered throughout your frontend code? Building an API is actually easy, if you bother. 'No! GraphQL is lit!' OK kid, have fun snicker .

No, I prefer writing an API endpoint and controller method for every resource I need to use on the client.

It is just as easy as lots of things we take for granted, line making a new app route, or component. That is a non issue.

Re: Urql: a GraphQL client library

#67

Post by Capaj »

true_religion wrote: post #41
gorgonian wrote: post #30

Earlier quoted context omitted.

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…

Deduplication shouldn’t work on mutations at all! There has got to be something else wrong. If I were to guess, it’s probably an issue with the Apollo React interface. Also IDs aren’t required for cache updates, only the typename.

> Also IDs aren’t required for cache updates, only the typename.

this is very inacurate. The problem happens when an items is cached with an ID and then another GraphQL request tries to cache it without and ID or vice versa. This is where the apollo-cache-inmemory blows up with an error like this: https://api.media.atlassian.com/file/f82c0ee8-2412-4f1b-8027...

There's even a test for this unfortunate behavior: https://github.com/apollographql/apollo-client/blob/master/p...

Re: Urql: a GraphQL client library

#68

Post by underwater »

brianmathews wrote: post #10
methyl wrote: 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?

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…

Fixating on package size alone is missing the forest for the trees. A good library can massively reduce your application size and pay for itself many times over.

For example, Relay removes the need for a lot of Flux and network request boilerplate. Going beyond that, it can collapse serial network fetches down into one request, massively speeding up page loads.

(This doesn't apply to moment, that library is just designed in a brain dead way).

Re: Urql: a GraphQL client library

#69

Post by underwater »

helloguillecl wrote: post #4
methyl wrote: 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.

Most apps need to do two core things: render UI and manage data. Setting a sub 30kb budget for something so core is madness.

Re: Urql: a GraphQL client library

#70

Post by lewisl9029 »

I 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 core seems to be backtracking from that effort somewhat, so it's great to see some competition in this area that really approaches extensibility as a first class citizen rather than an afterthought.

With that said, I'd love to see an officially supported normalizing cache implementation as well, in addition to the simple document cache Urql currently provides as a default:

https://formidable.com/open-source/urql/docs/basics/#code-cl...

Apollo and Relay's normalizing cache helps ensure a single source of truth for every piece of server data, which is incredibly valuable for non-trivial apps that have the same pieces of data fetched in multiple places that would otherwise have to be manually kept in sync, which anyone who has ever tried to do so can tell you is generally extremely tedious, error prone, and likely a frequent contributor to user-facing bugs. That to me is by far the most compelling value prop of GraphQL clients like Apollo and Relay. It'd be great if I didn't have to choose between automatic normalization and a more flexible extensibility model (fwiw, I'd choose the former).

Post reply on HN