Apollo Client 1.0: A flexible, community-focused JavaScript GraphQL client | Hacker News Reader

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

dev-blog.apollodata.com

354 pointsdjmashko278 comments

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.

What is the expo.io client? The site you linked has a broken certificate and then just replies "default backend - 404".

Works fine for me. Check your computer for viruses.

This comment is an interesting instance of Poe's law.

Sorry about that, the site was down for about 6 minutes around when you visited it.

It'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 open-source it as a simple SSR lib.

Interesting. I haven't used Apollo in production. Are there specific things (apart from mutations!) that it makes easier?

Mutations are much simpler. Cache updating is flexible and easily customised. They have subscriptions and polling. Fetch More for pagination. Generally clear and flexible to work with

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 - the client just requests want he wants and gets it back if he's allowed access to it.

I know GraphQL has been around for a while but this has been my first full go with it and I could easily forsee it doing to REST what REST did to SOAP - at least for the use case of building frontend clients that consume some api.

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 (up-to-date) copy of.

Nesting resources is a bit of an anti-pattern imho, and the solution looks bad because it's a poor fit in the protocol.

Of course, all of this is a bit of a moot point if you don't believe in addressable/linkable resources as a good solution. If you're not doing/believing in hypermedia in REST, you're much better off with something like GraphQL because it provides a very complete solution. You just need a ton of domain knowledge to be successful at proper REST.

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.

It's hard but solvable. If the data comes mainly from one database (although you can do some cools stuff with FDW in Postgres) then each graphql query can be translated to a single SQL query and it works quite efficiently, only one trip to the db (https://subzero.cloud/)

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.

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.

That solves the problem of data normalization, not of determining what to fetch. Falcor solves the second problem with paths, but that's still a custom abstraction that the API has to understand.

Relay and GraphQL aren't the same beast. One of the reasons to choose Apollo is to avoid the extra complications which Relay adds.

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.

Exactly. For the first time you have a common language to talk to your RDBS, NoSQL db, cache system and API, or a mix of all of them transparently, from anywhere in your architecture, including remote microservices and the browser.

HTTP/2 won't save you round-trips as you follow REST hypermedia links.

sure it will. client requests a resource, server sends back the response with some links to further requests. it can also send the results of those requests with zero intervention from the client. when the client requests them, they're already en route or cached locally

this assumes you have high confidence the client will actually request those links (or you can afford to send them even with low confidence) but you can use media types or query parameters to mitigate that

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!

This is not a knock on Apollo in particular, but I am wholly underwhelmed by what gets hyped up in this industry. There isn't anything novel here. A new generation of programmers rediscovers Remote Procedure Call (they call them mutations), schemas (NoSQL was so last year), and various older concepts and rehashes it while putting down a strawman they claim is Representational State Transfer (which if they read the thesis, they would realize that their concerns are nitty gritty details which are only tangentially related to the architecture described).

Also the community-focused angle is disingenuous. It's backed by venture capital of the Meteor Development Group and based upon a single vendor specification, GraphQL by Facebook.

Many great open source products have huge commercial backers--the important thing is that there is a community, which is in fact very true with Apollo.

I get what you're saying and I'm sure there is lots of truth to it--that doesn't make what's going on now the best to ever do it (i.e. the fastest way to produce the most meaningful user experiences). If it wasn't the case, we'd be doing remote procedure calls in C or whatever.

Bottom line: ur point is one that should be heard, but there's a way more value could be added in how you present it.

GraphQL and Apollo literally saved our app. Before we made the switch, we were plagued with issues from other providers such as technology stack compatibility issues, queries making issues and more.

We actually made the decision to switch to GraphQL 1.5 weeks prior to deadline and was able to get configuration and queries going in almost no time at all. I know I sound like a commercial right now but it seriously was very easy to setup and the querying learning curve was minimal.

The console is easy to use and the combination of the Playground with Mutation Callbacks helped me to setup and test my first AWS Lambda function of which I was able to do within 2 days and the AWS learning curve is not so easy to absorb.

Aside from all of this, the Graphcool team was very helpful and right there when we needed them whether on chat in the console or on Slack.

Huge congrats to the amazing team at Apollo! :)

We at Graphcool (https://www.graph.cool) are super excited about this release as the majority of our customers are building their apps with Apollo Client.

A few months back we launched Learn Apollo (https://www.learnapollo.com/) here on Hackernews which so far has helped thousands of developers to get started with Apollo. (HN Link: https://news.ycombinator.com/item?id=13187431)

For people just starting out with Apollo: With tools like graphql-up (https://www.graph.cool/graphql-up/) it's super easy to get a GraphQL API for your Apollo apps. We're looking forward to contribute more to Apollo and its ecosystem going forward!

Hey, Sashko from the Apollo team here - we're excited to keep improving Apollo Client and build more awesome tools for GraphQL development! If you're excited about this space and want to work on open source and also commercial products for GraphQL, we're actively hiring for a variety of positions: http://jobs.meteor.com/

Hi Sashko. I have been working a few years ago on a visual query builder for SPARQL. (Cf datao.net) May be you can find some inspiration for visual tools on top of graph query languages.

Cheers...

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

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

I 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?)

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

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

I'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?

Not GP, but I've been using it for the last several months and overall its been incredibly pleasant to work with. Bruce Williams and Ben Wilson have done a fantastic job with the API, and they are incredibly helpful on the slack channel. Its basically replaced Phoenix for most of my needs, which isn't a design goal of theirs—it just works out that way.

There's a few areas the guides are a little sparse, but the API docs are pretty solid. That will improve over a little more time. There are some areas like returning errors to the client that are sort of roll-your-own in the graphql community at large, but those kinds of things for me have come down to just finding a practice that works for me and going with it. I haven't had a chance yet to upgrade to the latest version, which supports middleware and subscriptions, along with stuff I _think_ was already supported like transport-level batching.

My advice if you're thinking about using it is to build out a basic set of features with it and expand your usage—you'll find out pretty quick if you like that modality, and apollo makes a great combo with it if you do.

After much time wrestling with Apollo, I found it was much easier to use Fetch API than use Apollo client. It took me an afternoon to roll my own client with Fetch after several days trying to figure out why Apollo wasn't doing what I wanted. Note we were using a .Net implementation of GraphQL on backend.

Now working with GraphQL in production, I would NOT recommend using it, especially if security is a concern. We're now implementing persisted queries, which means we call a query ID and return a predefined query/mutation. This essentially turns GraphQL into something like a Rest endpoint.

GraphQL was fun to use in the building stage and did make things easier to me as a front end developer. But as we made iterations on our schema and application, I think GraphQL added more work because there were so many more details to manage in the queries.

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?

Apollo Client doesn't solve problems with GraphQL, it provides a client for GraphQL.

Thanks Jives, but that still doesn't really help, does it? GraphQL from a client side are just json requests/responses, right? Am I missing something else?

My favorites are the collection of functions offered by the graphql-tools package. Like composing your schema from strings instead of the verbose JSON definition. The mocking is also neat.

Apollo is really just a tool-box of a lot neat little things that you can put together or omit. Check out their other packages beside apollo-client.

From what I can tell, Relay and Apollo serve as an implementation of functions you'd need to write to organize the fetching of your data on the client side. It turns things like "oh, in componentDidMount I need to fetch a route and update that data inside the store I'm using" into "Hey Relay this component needs this data before it loads".

Relay I think is a more opinionated and heavier weight option, with the benefit provided being that it intelligently aggregates queries based off fragments and allegedly handles caching (minus invalidation, so you could argue that it doesn't really handle it ;) )

Fwiw in the project I'm working on now we judged that the extra complexity of a data fetching layer like Relay or Apollo wasn't worth it for us. We may have come to a different conclusion with a different project. Ymmv

The Apollo extension for Chrome is also awesome. It needs to display errors better but it is already very essential.

https://chrome.google.com/webstore/detail/apollo-client-deve...

I tried integrating Apollo with my Redux app a few weeks ago but found it very confusing, so I just made my Redux app work with my GraphQL Rails backend without Apollo.

I've used Apollo with http://graph.cool and it's been pretty good so far. The folks at graph.cool are very responsive and have good documentation - filling in holes where Apollo has been lacking. Often times if you run into a gap or a mystery with Apollo - the graph.cool guys will answer the question while the stackoverflow question will languish a bit.

I'm using Apollo with https://www.graph.cool, and for me as mainly a frontend developer, it has been absolutely great so far. I've used both Relay and Apollo quite extensively in the past, and while both have their pros and cons, I do enjoy working with Apollo right now. Apollo had the added benefit of existing for several platforms in roughly the same way, so I've had the pleasure of using Apollo with both React and Angular 2. Great work!

I just got to plug graph.cool too for people interested in GraphQL and Apollo. I've been using it for quite a while, and the platform has been working great. I've been chatting quite a lot with their support (hey Nilan if you see this ;)) and they've been very helpful both in matters concerning the platform, but also for my app and GraphQL in general. I really recommend trying it out!

I'm in total love with Apollo Client! I'm using it at work with a custom graphql backend and on personal projects using http://graph.cool which just rocks! I hope the community will grow with people who use angular with apollo-angular as well.

I'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!

How awesome is the expo example on http://dev.apollodata.com/ ... I just tried it on my iPhone. Freaking amazing how well it works. Mobile app development has come leaps and bounds from where it was a year ago.

Can anyone compare use of Relay + Apollo? I've used Relay extensively but never tried Apollo.

+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 since it was first open-sourced around 18 months ago), but given that it's going to be changing quite a bit in the near future, I think newcomers to GraphQL are going to be better off with Apollo for now.

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.

A nice birds-eye view comparison can be found here: https://stackshare.io/stackups/apollo-vs-relay

I tried Apollo on my new personal project (in combo with Next.js as backend framework and Graph.cool as a graphql server(because I'm lazy to set up my own and of some additional featues)) - so far it is the best stack for me. you can check the repo here https://github.com/alexedev/scz

Can we use Apollo with Meteor seamlessly now. Meaning is it production-ready to use? I like Meteor's reactivity so so much.

I am wondering the same thing. I believe they wanted to appeal to the broader JS community first, then build in reactivity to Meteor. That is the only reason why I haven't picked it up yet.

Apollo works fine with Meteor. It works like any other node module.

I recently started making an app with the combination of Apollo Client and Scaphold (http://scaphold.io), and I can't get over how easy it is to rapidly built an app.

The combo has taken all the pain of backend development out of the picture. Awesome to see GraphQL take off.

I'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?

Hopefully a GraphQL server can't be far behind.

Edit: I guess you do something like this: https://github.com/RisingStack/graphql-server/blob/master/sr...

The Apollo team also provides some superb GraphQL server tooling:

http://dev.apollodata.com/tools/

The ability to express your schema in GraphQL instead of JS is especially nice. The server+client Apollo experience is really nice if you give it a try, and judging by the roadmap laid out in the blog post there are a lot of benefits to come.

Love 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?

The amount comments from 1 day old accounts in this thread advertising graph.cool is silly.

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.

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

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.

It'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?

I've started on programming early this year as a new year resolution, the tutorials on apollo and the help from Graph.Cool comunity alowes me to learn so much... really excited for whats to come...

Off topic, but I noted the coincidence of releasing Apollo Client 1.0 a few weeks after the 50th anniversary of the Apollo 1 accident... I'll read that as a tribute...

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.

using graph.cool (https://www.graph.cool/) it save me the need to write backend, this is not just code writing but also API design which is hard and changing, so I can iterate on the client code and redesign and I don't need to iterate on the server the server is just there and I know it is ready to whatever I need on the client, graph.cool integration with Algolia and Auth0 also work fine for me and allow me to complete my MVP along a development happy path, all high-quality component I grab into my stack with minimal integration effort

Using Angular 4 + Apollo + Graphcool has been the easiest alternative so far to use Graphql with Angular.

Awesome,

Shameless plug we just released our app today that would not be possible if it weren't for Apollo.

If you're interested in exploring fashion, check out Nelo on the app store:

https://itunes.apple.com/ca/app/nelo-shop-tv-fashion-and-dre...

Reply on news.ycombinator.com