Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Apollo Client 1.0: A flexible, community-focused JavaScript GraphQL client

dev-blog.apollodata.com

Post reply on HN
Print view View original

21–30 of 81 posts

Re: Apollo Client 1.0: A flexible, community-focused JavaScript GraphQL client

#21

Post by jbradleybarnes »

I love graphQL and Apollo's React work flow that mimics Redux's HOCs. The addition of it probably increased the maintanablity of my apps 5x. Added bonus, I found a backend as a service that that works perfectly with Apollo. Graphcool has increased the maintainability of my app ten fold. I no longer mess with writing my own reducers for the backend. The Graphcool community is also great; they are very helpful on slack and put out a ton of content on top of there great docs.

Watch this video; if you already use graphQL you'll be hooked on Graphcool:

https://m.youtube.com/watch?v=5uxq8Om-AZQ

Here's the code:

https://github.com/graphcool-examples/react-apollo-auth0-exa...

Re: Apollo Client 1.0: A flexible, community-focused JavaScript GraphQL client

#22

Post by brentvatne »

We use Apollo for the http://expo.io/ client and have found it to be extremely pleasant to use. I love how flexible it is too -- you can use it for weird things like building an ORM layer for SQLite. For example: https://github.com/brentvatne/apollo-sqlite-experiment/blob/... -- the queries here go through a custom NetworkInterface which use a pretty simple graphql resolver (https://github.com/brentvatne/apollo-sqlite-experiment/blob/...) built on graphql-anywhere to pull the data out of the DB.

Re: Apollo Client 1.0: A flexible, community-focused JavaScript GraphQL client

#28

Post by strken »

treve wrote: post #9
jfaucett wrote: post #4

I've just started working on a graphql project now and from the frontend perspective its phenomenally better than a rest api. The backend side of things is also pretty simple so I'm really enjoying it. With Rest APIs there's always the problem (with numerous solutions) of how you select the particular fields and how you nest and or do not nest the resources in the api. With GraphQL this is more or less a non-issue -…

I'm kind of hoping that nesting resources becomes a non-issue in the future once HTTP/2 is widespread. Ideally you don't ever nest resources. With HTTP/2 the overhead of additional requests can be significantly lower, and you get the benefit of using client cache. This becomes pretty powerful once cache digests land, so a HTTP/2 REST service can just proactively push only the resources to the client that it has an (u…

HTTP/2 doesn't fix the problem of loading data dependencies over a connection with a noticeable round trip latency. Even with server push, you need some way of defining what is to be pushed.

As a very contrived example, one page might show users who have access to servers in availability zones in aws regions. With an unnested rest api doing nothing intelligent with server push over a 250ms round trip, you're looking at a second of overhead just for sending ids back and forth.

Of course, there are ways of defining inclusion that are closer to restful than graphql is.

Re: Apollo Client 1.0: A flexible, community-focused JavaScript GraphQL client

#29

Post by pedalpete »

I'm about to start re-writing an api as GraphQL, I'm looking at the comments of support for Apollo, and looking at their webpage, but I'm failing to see what the real benefit is.

What is the problem with GraphQL that they are addressing?

Re: Apollo Client 1.0: A flexible, community-focused JavaScript GraphQL client

#30

Post by eloff »

treve wrote: post #9
jfaucett wrote: post #4

I've just started working on a graphql project now and from the frontend perspective its phenomenally better than a rest api. The backend side of things is also pretty simple so I'm really enjoying it. With Rest APIs there's always the problem (with numerous solutions) of how you select the particular fields and how you nest and or do not nest the resources in the api. With GraphQL this is more or less a non-issue -…

I'm kind of hoping that nesting resources becomes a non-issue in the future once HTTP/2 is widespread. Ideally you don't ever nest resources. With HTTP/2 the overhead of additional requests can be significantly lower, and you get the benefit of using client cache. This becomes pretty powerful once cache digests land, so a HTTP/2 REST service can just proactively push only the resources to the client that it has an (u…

GraphQL has a lot more to offer than just batching requests. I think that's one of the less important features actually. A common way to declare exactly what objects and attributes you want is more important, you can invent something like that for REST but you'd be reinventing the wheel for every endpoint.
Post reply on HN