
Apollo Client 1.0: A flexible, community-focused JavaScript GraphQL client - djmashko2
https://dev-blog.apollodata.com/apollo-client-1-0-a-flexible-community-focused-javascript-graphql-client-2253b90e6c84
======
brentvatne
We use Apollo for the [http://expo.io/](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/...](https://github.com/brentvatne/apollo-sqlite-
experiment/blob/master/src/App.js) \-- the queries here go through a custom
NetworkInterface which use a pretty simple graphql resolver
([https://github.com/brentvatne/apollo-sqlite-
experiment/blob/...](https://github.com/brentvatne/apollo-sqlite-
experiment/blob/master/src/resolver.js)) built on graphql-anywhere to pull the
data out of the DB.

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

~~~
koko775
Works fine for me. Check your computer for viruses.

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

------
rattray
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...](https://github.com/rattrayalex/isomorphic-react-relay-router-
koa/blob/master/frontend/server.js) 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...](https://github.com/rattrayalex/django-graphql-
react-ssr/blob/master/frontend/koa-apollo-redux-react-ssr/index.js) – meant to
open-source it as a simple SSR lib.

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

~~~
crucialfelix
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

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

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

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

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

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

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

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

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

------
schickling
Huge congrats to the amazing team at Apollo! :)

We at Graphcool ([https://www.graph.cool](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/](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](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/](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!

------
djmashko2
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/](http://jobs.meteor.com/)

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

------
tcsf
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-...](https://www.heavybit.com/library/podcasts/jamstack-
radio/ep-11-exploring-graphql-through-apollo/)

------
mparis
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](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.

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

~~~
bostonvaulter2
Absinthe is pretty nice, I wish their docs were a tad bit more full-featured
(more examples, perhaps?)

------
scanr
Have really enjoyed using Apollo Client with React, Redux and Redux Saga. It
plays very well with TypeScript too.

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

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

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

~~~
irrigator
Interesting. I'm considering building a graphql service using Absinthe. Could
you give more information on your experience? Any difficulties?

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

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

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

~~~
jives
Apollo Client doesn't solve problems _with_ GraphQL, it provides a client
_for_ GraphQL.

~~~
pedalpete
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?

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

~~~
crucialfelix
[https://chrome.google.com/webstore/detail/apollo-client-
deve...](https://chrome.google.com/webstore/detail/apollo-client-
developer-t/jdkknkkbebbapilgoeccciglkfbmbnfm)

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

------
yoyo44
I've used Apollo with [http://graph.cool](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.

------
zth_
I'm using Apollo with [https://www.graph.cool](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!

------
emilrmoeller
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](http://graph.cool) which just rocks! I hope the community
will grow with people who use angular with apollo-angular as well.

------
Siyfion
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!

------
cstrat
How awesome is the expo example on
[http://dev.apollodata.com/](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.

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

~~~
linkmotif
+1. If anyone has tried both, please share your experience!

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

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

------
buduguru
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](https://github.com/alexedev/scz)

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

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

------
charters
I recently started making an app with the combination of Apollo Client and
Scaphold ([http://scaphold.io](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.

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

~~~
jangerhofer
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?

------
Raphael
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...](https://github.com/RisingStack/graphql-
server/blob/master/src/server/schema.js)

~~~
pbgodwin
The Apollo team also provides some superb GraphQL server tooling:

[http://dev.apollodata.com/tools/](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.

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

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

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

------
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](https://m.youtube.com/watch?v=5uxq8Om-AZQ)

Here's the code:

[https://github.com/graphcool-examples/react-apollo-
auth0-exa...](https://github.com/graphcool-examples/react-apollo-
auth0-example)

~~~
bostonvaulter2
This almost sounds like an advertisement.

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

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

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

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

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

------
mulyoved
using graph.cool ([https://www.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

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

------
pmalynin
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...](https://itunes.apple.com/ca/app/nelo-shop-tv-fashion-and-dress-like-a-
star/id1139675415?mt=8)

