I have been working on a project using Apollo and React for both web and native and it has been a real pleasure. Apollo + graphql has made so many things that would have been a huge mess with redux and a rest api so much easier and cleaner.
Apollo Client 1.0: A flexible, community-focused JavaScript GraphQL client
41–50 of 81 posts
Re: Apollo Client 1.0: A flexible, community-focused JavaScript GraphQL client
#42Love the momentum of graphql.
Anyone use graphql with fire base? I'm curious on the use cases.
I did a test project in react native with fire base and it felt like early days of Meteor. Apollo's architecture may or may not conflict with firebase in an app. Anyone have some insights?
Re: Apollo Client 1.0: A flexible, community-focused JavaScript GraphQL client
#43Congrats to the Apollo Team and contributors for all the awesome work that went into this release. The majority of our customers at Scaphold (https://scaphold.io) are using Apollo to power their applications with amazing results.
We're excited to keep working to push the limits of GraphQL by supporting awesome features like subscriptions, persisted queries, and much more!
If you're in SF come to meteor tonight for the GraphQL meetup and let's talk about what's coming next.
Re: Apollo Client 1.0: A flexible, community-focused JavaScript GraphQL client
#44Earlier quoted context omitted.
+1. If anyone has tried both, please share your experience!
Relay has some nicer ergonomics when it comes to composing queries from fragments for different components, and the mutation behaviour is a bit more "magic", but both of these benefits come with some serious restrictions on what you can do. The next version of Relay looks like it'll do away with this approach, bringing it closer in line with how Apollo does things right now. I'm a heavy user of Relay (been using it s…
Thanks. Yes I too am using soon-to-be classic Relay. I've enjoyed transitioning to Relay.GraphQLMutation and can't say I miss the fat query. So Relay "modern" will be like Apollo... interesting.
Re: Apollo Client 1.0: A flexible, community-focused JavaScript GraphQL client
#45Earlier quoted context omitted.
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…
Falcor sort of solves this by allowing you to communicate "references" in the graph. For example, it might inform you that users.52.friends.1 is actually users.45, so the client will cache it at that location instead.
This is less complicated than GraphQL's solution of using the Relay Node interface.
Re: Apollo Client 1.0: A flexible, community-focused JavaScript GraphQL client
#46I 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…
This almost sounds like an advertisement.
I'd like to see more of the comments in here actually discussing an honest assessment of the trade-offs when compared to other approaches.
Re: Apollo Client 1.0: A flexible, community-focused JavaScript GraphQL client
#47Can we use Apollo with Meteor seamlessly now. Meaning is it production-ready to use? I like Meteor's reactivity so so much.
Apollo works fine with Meteor. It works like any other node module.
Re: Apollo Client 1.0: A flexible, community-focused JavaScript GraphQL client
#48I've been using GraphQL with Apollo and Absinthe/Phoenix for a civic data gerrymandering project. Fantastic combo and everything plays well together. Certainly looking forward to using this stack on something big and bad in the near future.
Interesting. I'm considering building a graphql service using Absinthe. Could you give more information on your experience? Any difficulties?
Re: Apollo Client 1.0: A flexible, community-focused JavaScript GraphQL client
#49It's sad that we have to start asking this again of open source software, and I'm glad to see a normal MIT licence on the Apollo code itself, but is this in any way encumbered by Facebook's unpleasant PATENTS file?
Re: Apollo Client 1.0: A flexible, community-focused JavaScript GraphQL client
#50I'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…
Let's look at an analogy: Amazon Prime delivers in a day by now. With the customer info, Amazon can also send stuff directly/monthly. That's HTTP2.
The user chooses several products in one order. When you add the product in the basket, Amazon suggests some products that are often ordered at the same time, like extra supply or accessories. That's GraphQL.
GraphQL assumes shipping something cost money, and forces the client to declare what it wants explicitely and in detail. Like SQL without SELECT *. Hope that helps!