
Learn Apollo: Build GraphQL Apps with React, React Native or Exponent - debergalis
https://www.learnapollo.com/
======
kabes
All these GraphQL solutions seem to focus on the frontend and assume there's a
magical GraphQL server somewhere. But GraphQL Just shifts the hard work from
the client to the server and I haven't seen any good solution towards security
(except storing all the possible queries a user may access, which kind of
defeats the purpose of GraphQL in the first place) and performance (a large
query is usually resolved to thousands of database fetches, instead of 1
optimized one) on the server side.

What we really need is a decent GraphQL server. The client isn't difficult
anyway.

~~~
danr4
In addition to graph.cool, there's scaphold.io. has any body used these two
and can share their experience?

(I'm not affiliated with either of them. Just wanna know)

~~~
fredfogerty
Hey there, I've used both Scaphold and Graph.cool and I would thoroughly
recommend Graph.cool.

To understand why, I recommend you have a play with them yourself. It is
immediately clear, in my opinion, that Graph.cool is a much better designed
product in every aspect. Graph.cool's UX exudes refinement and quality that
Scaphold's does not.

An example of this is the fact they invite you to their Slack team
automatically when you sign up (i.e. use the email you sign up with to invite
you, you don't have to do anything). They really care about their customers,
and the Slack community around Graph.cool is much more active than Scaphold's.
In fact, it's mostly the community that is buzzing around on Slack, and it's
about people learning GraphQL, not necessarily learning how to use Graph.cool.
The Graph.cool team seem to be really motivated to help everyone learn to use
GraphQL, not just their service. This is also evident if you get in touch with
the founders of Graph.cool - they are just nice people to talk to.

Any feature distinction that Scaphold may have over Graph.cool is quickly
disappearing. I can only think of one, subscriptions, and Graph.cool has that
on their roadmap to be released very shortly. On the other hand, Graph.cool
has plenty of features that Scaphold does not, such as Auth0 integration,
Relay AND Apollo support (from the same schema), a much better permission
model.

Oh, and it's free (for now) :)

~~~
bmpafa
This is incorrect on several points. Scaphold supports relay and Apollo out of
the box and integrates with auth0 (per their docs; I've used neither feature).

Subjectively, having played with both, I chose scaphold (over graph.cool and
reindex) for a few reasons:

\- pricing model makes a lot more sense to me. Graph.cool tiers their pricing
on user counts, which makes very little sense to me for a product the cost
drivers of which are storage and throughput. They also apparently count a user
once they register, with no clear way of handling inactive users (can't be
good for your LTV calcs). Reindex was also suboptimal imo, with steep jumps
from free tier to paid. They also charge based on 'operations,' which, while
less so, also seems strangely divorced from what I imagine their cost drivers
are. Scaphold seems to have taken firebase's pricing model, which was a smart
move

\- storage. Graph.cool has really low storage per tier. Reindex bills storage
separately from 'operations' and only charges in $50 5GB chunks (5.1 GB last
month? Sorry!). Scaphold again copies firebase's pricing with small,
inexpensive increments.

\- ui. I didn't use graph.cool's ui too much, but I'm very happy with
scaphold's. Afaik reminded didn't have any ui to speak of--someone correct me
here if I'm wrong. You can build your entire schema in scaphold's ui (with
very helpful tool tips most of the time) , manage integrations (which,
generally, just make certain queries/mutations available), and view some
pretty thorough analytics on your app. Coming from firebase, which has been
really neglecting web app users in favor of mobile lately (imo), this was
really nice.

Lastly, I'm new to graphql, but as I understand it, scaphold has added some
nice features on top of the API. It seems to mirror PostgraphQL (a postgres
<-> graphql utility), and adds pretty robust support for relationships
(1:1,1:many,many:many). My schema is highly relational and, so far, it's a
breeze.

I will note that graph.cool seems to have much more newbie-friendly docs, and
maybe more comprehensive docs over all. Scaphold's docs are okay: they're
wider than they are deep (maybe a paragraph for every feature w/ an
uncommented snippet), there are some obvious mistakes, and some parts of the
docs are scattered between the docs page and the UI's tool tips. When I had
problems, though, their team got back to me w/in minutes (on email and slack).

To be clear, I'm not affiliated w/ any company discussed here--I'm just a user
shopping for a firebase replacement.

That said, if you're considering the product, here's a ref link--$10 for you &
$25 for me
[https://scaphold.io/referral?ref=99XXP3](https://scaphold.io/referral?ref=99XXP3)

~~~
sorenbs
Thank you for going so much into detail.

Our pricing structure has been like that since we started a year ago. We have
learned a lot since then and you touch on some important points. We have put
of updating the pricing model because we have been busy improving docs and
working on the product, but expect a complete revamp early next year.

If you want to talk more you can always reach me on soren@graph.cool :-)

------
sorenbs
Hey :-) we just announced this. Happy to answer any questions. Here's the
accompanying blog post [https://dev-blog.apollodata.com/learn-apollo-build-
graphql-a...](https://dev-blog.apollodata.com/learn-apollo-build-graphql-apps-
with-react-react-native-or-exponent-4787269a4747)

~~~
iyn
Can you give a comparison between Apollo Client and Relay? And if you know
about upcoming Relay 2 features, I'd like to hear about it too in the context
of Apollo Client.

If you have time, I would love to hear about your (and everybody else)
opinion/prediction where we're going with client data management/server
communication in the future. What's your take on client databases?

Thanks!

~~~
djmashko2
(I work on Apollo)

It's hard to know exactly what will be included in Relay 2, so we'll have to
wait to make a comparison. Apollo came after Relay 1, and so has been designed
with a few key differentiators: (1) flexibility, since it's built in a modular
way and has a lot of hooks into internals, (2) less opinions, because it works
with any GraphQL server and doesn't require a particular type of schema, and
(3) optimized for devtools, since it doesn't generate dynamic queries on the
fly and is built on top of Redux. You can see the new dev tools we launched
yesterday here: [https://dev-blog.apollodata.com/apollo-client-developer-
tool...](https://dev-blog.apollodata.com/apollo-client-developer-tools-
ff89181ebcf)

As for client/server communication in the future, it seems there are two main
camps right now:

1\. Lossy APIs - this is if you use a REST API or GraphQL to send data to the
client. The server knows a lot more than the client does, and the API returns
only what the client needs to know at that moment. This has the advantage that
it doesn't impose any limitations on your backend schema or storage, so you
can put a REST or GraphQL API on top of literally any backend.

2\. Database replication, like Meteor or Realm. In this case, the client asks
for objects and they are replicated to the server via some kind of push
mechanism. In this case, the client has a much easier time predicting server
operations and achieving consistency. On the other hand, the server has to be
much smarter and this places a lot of restrictions on what kind of database
you can use. For example, Meteor essentially requires MongoDB, Realm has its
own database.

With Apollo we're trying to build towards the best implementation of approach
(1) because our main goal is to enable decoupling between the client and
server.

------
wwalser
I came to the comments to point out that I didn't know what Apollo was. Most
of your long term traffic will come from Google searches but early on while
it's being shared around places like Hacker News, it's probably a good idea to
add a link to [http://dev.apollodata.com/](http://dev.apollodata.com/) to the
intro.

------
WhitneyLand
Because they don't tell you on the site:

Apollo Client is a Javascript library that can be used in any front end where
you want to use data from a GraphQL server.

It's incrementally adoptable, so that you can drop it into an existing
JavaScript app and start using GraphQL for just part of your UI.

It uses TypeScript.

------
sergiotapia
From the creator's of Meteor. What kind of long-term commitment plan do you
have for Apollo?

~~~
hobofan
Thanks, I didn't know that. That certainly explains the high polished look of
Apollo combined with the seemingly non-existent business model.

I tried Apollo Optics - horrible brand name BTW, everyone I mention it to here
in Germany thinks of the eyeware retailer - and while it was easy to integrate
and nice to look at, it provided little actual value compared to existing
tools in the same space of performance monitoring.

~~~
debergalis
Would you mind sharing what metrics and analysis are the most important for
your GraphQL API? (Or what you would find most valuable if you could get it?)
What tools do you use today?

[I work on Optics.]

~~~
hobofan
The most important metrics are the traditional ones that Optics focuses on
like latency percentiles and throughput. We are currently using NewRelic and
Loggly. Since both the NewRelic agent and our logging system allow us to tag
requests, the grouping by query structure that Optics provides, doesn't really
add value. (EDIT: Further, both NewRelic and Loggly provide a better interface
for zooming in on interesting areas in time.) From a operations perspective a
GraphQL and a REST API aren't that different from each other that they warrant
the usage of another tool.

When I tried it, the query execution view also wasn't aware of DataLoader
usage. That meant, that once we started optimizing our queries, it looked like
many slow parallel queries, which meant that you had to guess what was already
optimized, and what wasn't.

------
ericclemmons
If you want a pretty terse way of defining a GraphQL API, Apollo works very
well (with mocking, too).

~~~
djmashko2
Here's the documentation for graphql-tools, Apollo's API definition package:
[http://dev.apollodata.com/tools/graphql-
tools/index.html](http://dev.apollodata.com/tools/graphql-tools/index.html)

