We've been working a lot with Graph.cool recently in conjunction with Apollo. It's a powerful combination and each day we are learning of powerful ways of working with our data. Our data is going to be heavily dependent on the relationships we build between each model. All very exciting. Easier now to build apps on both web and native that share their data.
Apollo Client 1.0: A flexible, community-focused JavaScript GraphQL client
11–20 of 81 posts
Re: Apollo Client 1.0: A flexible, community-focused JavaScript GraphQL client
#12I've been using Apollo now for the last month or so, in production and I have to say that it's been a fantastic tool to work with. The community and the team behind it are also second to none out there; hugely friendly and incredibly helpful. Check out their Slack channel if you run into any issues!
Re: Apollo Client 1.0: A flexible, community-focused JavaScript GraphQL client
#13Sashko and Jonas from the Apollo team were guests on JAMstack Radio this week, it's a great primer if you're just getting into Apollo+GraphQL https://www.heavybit.com/library/podcasts/jamstack-radio/ep-...
Re: Apollo Client 1.0: A flexible, community-focused JavaScript GraphQL client
#14Have really enjoyed using Apollo Client with React, Redux and Redux Saga. It plays very well with TypeScript too.
Interesting I'll need to look into how well the Apollo Client plays with Redux and Redux Saga since I'm using them in my stack. I had assumed that it was more "apollo-focused" and thus wouldn't play nice.
Re: Apollo Client 1.0: A flexible, community-focused JavaScript GraphQL client
#15I just started diving into using Apollo client the an Elixir backend (using Absinthe). It's an amazing combo! I look forward to more releases from the Apollo team.
Absinthe is pretty nice, I wish their docs were a tad bit more full-featured (more examples, perhaps?)
Re: Apollo Client 1.0: A flexible, community-focused JavaScript GraphQL client
#16I'll second Jonas in being amazed and humbled by the GraphQL community. There is just so much great stuff going on right now. Apollo is doing great work and we use the Apollo Client for most of our examples at Graphcool. I'm happy to answer any questions about the GraphQL ecosystem as well as how it might fit for your specific use case.
First, a huge congratulations to the Apollo team! You have more than delivered on the original promise of the Meteor group.
I am really excited about the proliferation of GraphQL APIs as they replace standard REST endpoints! When I heard that GitHub released a beta of their API with a GQL endpoint, I immediately wanted to try it out.
I learned, however, that it is extraordinarily difficult to connect to multiple GQL endpoints with a single Apollo client. I cannot even imagine how that would work. Should a single GraphQL endpoint have "clients" of its own, through which it could proxy requests to other endpoints? Should the front-end application have multiple clients, each with its own endpoint? There are a lot of easy, inelegant solutions which come to mind.
Several GitHub issues reference similar ideas, but there is no clear solution. Do you have any thoughts about how an application can conceptually replicate the simplicity of REST requests to multiple & diverse endpoints, when the endpoints are GraphQL-structured?
Re: Apollo Client 1.0: A flexible, community-focused JavaScript GraphQL client
#17Can we use Apollo with Meteor seamlessly now. Meaning is it production-ready to use? I like Meteor's reactivity so so much.
Re: Apollo Client 1.0: A flexible, community-focused JavaScript GraphQL client
#18Using apollo with react native has been a great experience. works well with react navigation and graph.cool as well. Only thing I would improve is the subscription features. Feels kind like theres a lot missing in subscription to customize depending on application. Like applyMiddleware and other hooks .
Re: Apollo Client 1.0: A flexible, community-focused JavaScript GraphQL client
#19I'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…
But you're still going to make lots of requests which result in inefficient data access on the server unless you batch them up. So you just end up moving batching from the client where it is easy, to the server where it is hard.
Re: Apollo Client 1.0: A flexible, community-focused JavaScript GraphQL client
#20It's been a bit, but I found the ergonomics and flexibility of Apollo to be miles ahead of Relay. I also found it fairly straightforward to set up Server Side Rendering (SSR). My example is at https://github.com/rattrayalex/isomorphic-react-relay-router... if it helps anyone, though it's a year out of date. EDIT: A more up-to-date example at https://github.com/rattrayalex/django-graphql-react-ssr/blob... – meant to o…
Interesting. I haven't used Apollo in production. Are there specific things (apart from mutations!) that it makes easier?