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

51–60 of 79 posts

Re: Urql: a GraphQL client library

#51

Post by jayd16 »

xiaomai wrote: 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…

What is GraphQL like in production at scale? It seems like a neat concept but how do traditional web technologies like edge caching work?

Re: Urql: a GraphQL client library

#52

Post by peggyrayzis »

oaxacaoaxaca wrote: post #50
peggyrayzis wrote: post #16

Earlier 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.

- The `Query.variables` prop. The docs don't explain very well when exactly the network call will be reinvoked, especially if the graphql query has variables with default values (there's an open issue about this with little activity: https://github.com/apollographql/react-apollo/issues/2715 ). - The `Query.skip` prop. I'd like to know all of the expected behavior for when this prop is used. For example, I've noticed…

Really appreciate your feedback. Let me pass it along to the team. I agree that we could do a better job of documenting when queries are reinvoked depending on what options and variables are set.

For skip, the behavior with refetchQueries sounds intentional since the refetching happens within the Mutation component. I don't think we pass information about whether the skip prop is set on the Query component to the refetchQueries array (https://github.com/apollographql/react-apollo/blob/master/sr...).

Re: Urql: a GraphQL client library

#53

Post by RussianCow »

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.

It might be expected, but I have to admit, there is a certain joy to using a website that loads instantaneously (like Hacker News). Whether or not that joy translates into additional revenue to justify the costs is another question entirely...

Re: Urql: a GraphQL client library

#54

Post by peggyrayzis »

yodon wrote: post #28
peggyrayzis wrote: post #16

Earlier 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.

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…

Thanks for the thoughtful response, this is all helpful feedback that I will share with the team.

It's been on my backlog for a while to rewrite the Apollo Client intro section to give developers the high level overview you're looking for. Now that Apollo Federation is out, I have some time on my calendar to do exactly that. :) Would you be open to reviewing the new section once it's done? If you're interested, send me an email at peggy [at] apollographql.com.

If it's still confusing after that, then we can chalk it up to a problem with the library. I suspect that it's a docs problem since the intro hasn't been overhauled since I joined the company almost 2 years ago.

Re: Urql: a GraphQL client library

#55

Post by DrFell »

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.

Re: Urql: a GraphQL client library

#56

Post by tdy_err »

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.

Re: Urql: a GraphQL client library

#57

Post by peggyrayzis »

true_religion wrote: post #40
yodon wrote: post #28

Earlier quoted context omitted.

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…

You can’t invalidate the cache in Apollo. You have to clear all items, or update a specific part to a new value. It’s not a simple key value cache, but a graph of values, which makes invalidation more complex but still in my opinion that is a huge oversight. Hopefully an Apollo dev can give us some insight here: why is the cache a requirement? Why is it threaded into every bit of code? I’ve seen so many bugs from the…

The normalized cache is the one of the main value props of Apollo Client. It optimizes reads, automatically updates queries without a refetch for some mutations, supports optimistic updates, and can also return partial data for large queries. If you don't need a cache, then you can use fetch, graphql-request, or even Apollo Link to fire off a simple GraphQL request. You also don't have to use our cache implementation (apollo-cache-inmemory) with Apollo Client. There are other implementations that make different tradeoffs.

For what it's worth, we are rearchitecting parts of the cache to support invalidation and garbage collection for Apollo Client 3.0. The only reason why we don't have it yet is because it's a tough problem to solve - one mutation could invalidate an infinite amount of queries. We're committed to solving this soon though because we know the community really wants it.

Re: Urql: a GraphQL client library

#58

Post by kromem »

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 .

It's clear from your comment you've not actually used the thing you are criticizing.

Nothing about the spec necessitates duplicating your DB schema.

In terms of the data models, you only need to spec out models based on what you want returned.

It's perfectly fine to have limited data models for only what's being requested in a specific use case.

Re: Urql: a GraphQL client library

#59

Post by priceytomato292 »

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 single interface (and break your monolith into microservices transparently).

If you're API is a todo list CRUD, then yes, you prob don't need GraphQL.

Re: Urql: a GraphQL client library

#60

Post by dang »

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 .

Don't be snarky.

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

Post reply on HN