
John Resig: Introducing the GraphQL Guide - sbr464
https://blog.graphql.guide/introducing-the-graphql-guide-11a5ae48628a
======
maktouch
We deployed our GraphQL July 4th 2016. It'll almost be 2 years. Documentation
sucked back then (and apollo was non-existent), so a lot of we had to dig by
ourselves.

I hope this book will cover some topics for others that was real head
scratchers for us

\- DataLoaders

\- Authentication example

\- Unions and Interfaces are your friend. Use them early.

\- Try to define your custom Scalars early (especially DateTime format)

\- return Connections (edge/node) instead of List cause you probably want to
paginate at some point

\- Folder structure (we redid ours 4 times lol)

\- Naming convention (we redid ours 3 times lol)

\- Subscriptions

After 2 years of using it and hacking it, we're still impressed. Once you get
past the learning curves and have set conventions, writing GraphQL is a lot
faster and better. Define your types, and some custom root queries, and done.

The neatest thing is that we made a schema validator -- compile all the
graphql queries from the frontend and mobile, and validate them against the
server schema. It really help when we changed folder structure and naming
convention to see if we'd break something on the frontend.

I can't vouch for this book yet, but I'll swear my life on GQL. It's been a
real game-changer.

~~~
misschresser
I'd be curious to hear more on your schema validator. We've been using GQL for
a little over a year and have felt some serious pain when doing big shifts in
our GQL layer and even just when we're trying to clean out dead code / assess
which resources are being used in which FE apps.

~~~
maktouch
Sure!

Our implementation is a little bit naive - it doesn't "clean out" or see which
resources are being used.

On the frontend:

There's a script that globs all `.graphql` files and compiles them into a list
of {query, variables}. This probably could be made better if it was a webpack
plugin that compiles this on build time. This was a Friday project so our time
was pretty limited. This was honestly good enough since it caught a shitload
of bad queries =).

Query contains the graphql query. Variables contains test arguments.

It saves them into a gigantic file (example:
[https://gist.github.com/maktouch/074339517a8da5128d62869356b...](https://gist.github.com/maktouch/074339517a8da5128d62869356b75893))

On the GQL server:

We take that file, we parse it, and we loop it and pass it thru the validate
function ([https://graphql.org/graphql-
js/validation/#validate](https://graphql.org/graphql-js/validation/#validate))

(truncated example:
[https://gist.github.com/maktouch/e1a2955dfcca42541a41665a361...](https://gist.github.com/maktouch/e1a2955dfcca42541a41665a361be28b))

Ops:

Frontend and GraphQL are its own Docker image. We build both in parallel. When
both succeeds (in building and running their own tests), there's an extra
build step that runs this specific test. It does it by taking the gql-
queries.json file from the frontend container, adding it to the GraphQL image,
and running the validate command.

You can do this by doing multi-stage builds in Docker
([https://docs.docker.com/develop/develop-images/multistage-
bu...](https://docs.docker.com/develop/develop-images/multistage-build/#use-
multi-stage-builds)). We don't push the resulting image - it's just there for
testing.

------
wwweston
As I often do with new-ish things these days, I've been quietly weighing what
degree of investment I want to put into GraphQL for a year or so.

John's vote of confidence means _a lot_ to me. The software industry has lots
of abstractions that are different ways of arranging the chairs on the deck,
shuffling the work around while providing marginal productivity magnifiers.

jQuery's been somewhat superseded because it isn't an application-organizing
framework, but it's still one of the best conceived and fitted abstractions
for the problems it was meant to solve I've encountered in the entire time
I've worked in software. If the person who conceived it thinks GraphQL yields
productivity benefits, then I want to check it out.

~~~
wnevets
>John's vote of confidence means a lot to me.

by selling a $80 book?

~~~
tomnipotent
Considering the street cred John has earned for creating jQuery, it says a lot
for him to endorse GraphQL and to even write a book about it.

------
tfigment
Hate to complain about GraphQL in general and not specifically this guide but
I ran into to major issues with it and really wanted to like it but ultimately
gave up on it until they fix some core issues.

I don't see how I can implement complex object hierarchies that are not rigid.
Only list is supported as an unbounded data type and for some reason there is
no unbounded map/dictionary data type even with simple restrictions like
requiring string key type. There is not even good advice on what key/value
pair naming convention should be for all languages. The other is that there is
very poor support for more general include/exclude/where filters. The idea
being arbitrary complex join/filter clauses to function like sql statement
with multiple joins and where clauses. Have to rely on implementation specific
conventions like what sequelize does to get that but not for arbitrary object
graphs. Solve some of this and it might actually become as powerful as it is
frequently claimed to be.

~~~
hn_throwaway_99
I'm a huge fan of GraphQL, and when I see negative feedback that lists some of
the points you make, I can't help but think that you are using GraphQL in a
way for which it was not designed.

The most common issue I see is when folks list "what about arbitrary complex
join/filter clauses to function like sql statement with multiple joins and
where clauses" which, in my use of GraphQL, is literally never something I
would want. GraphQL is _not_ SQL or designed to be an arbitrary data access
layer.

One of the driving principles of GraphQL, taken straight from the spec, is:
"Product‐centric: GraphQL is unapologetically driven by the requirements of
views and the front‐end engineers that write them. GraphQL starts with their
way of thinking and requirements and builds the language and runtime necessary
to enable that."

IMO GraphQL is designed to start with the UI, and develop models that conform
to the needs of the UI, _not_ to start with the data and develop arbitrary
joining and fetching strategies for that data.

~~~
gldalmaso
Maybe I'm just not that well versed in GraphQL, but reading your comment left
me confused.

What would the UI data requirements have to be? Aren't they often arbitrary
data fetching driven by the user? Aren't the requirements of views what data
the user wants to see and handle? Depending on what user chooses, the fetching
of data will have to go deeper and deeper into the data store.

I seem to remember, perhaps mistakenly, that GraphQL came as a solution to
fetch arbitrary data structures that the view needed instead of having to mix
and match multiple RESTful endpoints.

~~~
andrewingram
Do your users construct their own UI? Or do they use a set of features
provided by whomever built the app/website? The arbitrary data fetching is to
allow rapid feature development, bypassing the need to explicitly code up per-
feature endpoints. Instead the responsibility is passed to front-end
developers to compose per-feature queries.

------
nek4life
I'm skeptical that this book will ever be finished. The last time I bought an
unreleased book authored by John Resig it took two and a half years before it
was published. If I remember correctly another author had to take over in
order to complete it. I'm super interested in GraphQL, but I wouldn't consider
purchasing this ebook until it is 100% complete.

------
westoncb
Anyone know what framework the book uses (if any)?

I tried doing a GraphQL project in Python/Django recently, using Graphene for
the GraphQL bits. I didn't end up getting that far because the documentation
was so lacking, as were examples generally (for graphene-python I mean; I
could find stuff on GraphQL in the abstract).

I'm thinking about giving it another shot, maybe on node.js this time, largely
because I get the impression that the supporting tech for it is more mature
there—but I'd love to hear opinions on what the _most_ mature lib for using it
is at the moment (whatever language)!

~~~
alexchamberlain
Don't give up on Python! The eco-system is young, but it is there. Saturday
just gone, I gave a presentation at PyLondinium [1] on "GraphQL in Python"
(Slides: [2], video to follow). For the purpose of the presentation, I put
together a simple server example [3].

[1]: [https://pylondinium.org/](https://pylondinium.org/) [2]:
[https://alexchamberlain.github.io/presentation-
pylondinium-g...](https://alexchamberlain.github.io/presentation-pylondinium-
graphql-in-python/#/) [3]: [https://github.com/alexchamberlain/city-
api/](https://github.com/alexchamberlain/city-api/)

~~~
miguelrochefort
The ecosystem is young?

Python is older than HTML, CSS, JavaScript, PHP, Java, C#, etc.

~~~
nicwolff
He means the Python+GraphQL ecosystem – and he's right, Graphene-Python and
graphql-core are still evolving and changing their interfaces, and there's
essentially no useful documentation beyond trivial examples.

------
simplecomplex
Why spend time building an API at all? Just point Postgrest at your PostreSQL
database and you get a REST api for free. There’s similar projects for graphql
and other DBs.

~~~
icebraining
Isn't GraphQL intended to be used directly by the frontend app (with direct
access by any potential malicious user), whereas Postgrest is more for a
backend app, that can be trusted with more control?

~~~
hucker
There's nothing in PostgREST that stops you from limiting control so that even
anonymous users can use it safely. I've used PostgREST for user-facing APIs
with success, but it requires some knowledge about the postgres access control
model.

EDIT: And "Just point Postgrest at your PostreSQL database" is rarely a good
idea in my experience, I usually have (versioned) API-schemas containing
views, so that I can change my underlying data schema at will without borking
the API.

~~~
icebraining
Anonymous seems easier, since you can treat them as a single user. But could
you do something like HN as a frontend app talking directly to a Postgrest
API?

~~~
hucker
Good point, that's true. But yes you could, using row-level security. See
[https://www.postgresql.org/docs/current/static/ddl-
rowsecuri...](https://www.postgresql.org/docs/current/static/ddl-
rowsecurity.html) and [https://postgrest.org/en/v4.4/auth.html#users-and-
groups](https://postgrest.org/en/v4.4/auth.html#users-and-groups)

------
tpetry
Call me old school but i like my books printed and with on-demand printing
services its not conplicated for a publisher. Can‘t read hundreds of pages on
a screen...

But without seeing the content the pricing looks insane. It has to be worlds
better than online resources for 289$ (!).

~~~
Hendrikto
The 39$ version would be closest to an actual book. You get every chapter once
the book is finished, and that’s that.

The more expensive versions include updates and additional features.

~~~
sakarisson
Every chapter except the extra chapters included in the more expensive
options.

------
ozten
Once you pay $39 you have to Github OAuth to receive the book. Currently,
there are no other authentication options.

Just an FYI as I didn't know that before I had paid.

------
dudus
I want to buy it but feel annoyed by these payment options.

    
    
      Tier 1: $39 - Full book when released and early access
      Tier 2: $89 - Tier 1 + updates for 2 years + extra chapters
      Tier 3: $289 - Tier 2 + free updates for life + more extra chapters
    

This is an oversimplification with only the things I care about. The actual
packages include more stuff. What really annoys me is why would you call tier
1 the full book and say tier 2/3 has "extra chapters".

I just want all the chapters + early access + updates (2 years is fine). And I
want to pay less than $100. Am I being too entitled? Buying books used to be
simpler.

~~~
blub
Yes, it's like some horrible IAP concept for books.

Normally a technical book costs around 40-60 EUR and one gets _all_ the
chapters. Updates are called "editions" and are published when there's demand
and the information has become outdated.

~~~
Yizahi
Also "free updates for life" usually means free updates for several years and
then "new product" is released with entirely new pricing and "old product" is
deprecated. New and old here being a different revisions of the same thing.

~~~
dudus
Usually yes. There are some exceptions with technologies that evolve a lot.
The free update feature of the ng-book 2 for instance really paid off for me.
But that was included in all the "Tiers" for free, it was a $39 book.

------
dmitriid
> The end result is a vastly simplified backend

GraphQL specs offer none to zero of the following:

\- caching

\- authentication, authorization and handling data access

\- protections against ad-hoc arbitrarily nested and complex queries

\- routing

How does this “vastly simplify the backend”? If anything, it makes the backend
hideously complex (IIRC Apollo’s approach to caching is parsing requests and
responses every time, do some magic, and handle caching manually).

------
rhacker
The author and his introduction definitely has a compelling story to tell. It
is making re-think our recent strategy shift in which we evaluated GRPC and
GraphQL. We chose GRPC but I'm starting to see that it's not really any better
than REST + Swagger. I think I might need to actually just go ahead and buy
this book and re-think if the GRPC route is worth it. Our investment in Grpc
at this point has been slow - mostly because I figured the Grpc-Web project
would be moving a lot faster by now. It's not and I don't see the team
doubling down, whereas it looks like Apollo and GraphQL seems... ready now.

Edit: Does anyone know if he goes over typescript?

~~~
andrewingram
When I interviewed at Improbable (authors of gRPC Web) last year, we spoke a
little about gRPC and GraphQL. The interviewer didn't really explain their
choice beyond the fact that half the company came from Google and were already
fans of gRPC.

------
codingdave
If nothing else, the conversation around this has shown that applying a
subscription-based, tiered pricing model to a book is not appreciated by the
consumers.

~~~
nkassis
I think it's against the usual expectation for a book. If they had split it
into volumes then it would have matched better people's expectations. Also the
videos and extra should be part of a course package. Messaging just make it
sound like you are getting short changed.

------
GedByrne
I think he is making a mistake selling this as a book. These prices just don’t
work for a book.

He should be selling it as a knowledge community. Members get access to the
resources, conversations, training, etc.

Add levels of membership that have to be earned through merit somehow and
membership at a higher level becomes valuable on the CV.

------
rapfaria
Why is rate limiting only part of the $289 package?

Edit: And wasn't it cheaper earlier? I was pretty sure it was $29 for the
basic version, maybe that rounding up market trick got me.

------
drcode
Good on him to be so flexible- I don't know that much about John Resig, but he
was clearly a pioneer with jquery+rest, so it's great to see him being equally
enthusiastic about a project based on graph query languages and React,
arguably replacements for this earlier tech!

~~~
thinkingkong
REST was Roy Fielding but I agree. Much like the concept of Apache Cordova,
the best jquery would be no jquery at all.

~~~
gkoberger
John didn't invent REST (nor AJAX), however jQuery made it feasible and easy
for people to use.

Yes, you're right, the best jQuery would be no jQuery. jQuery was basically a
prototype for the next generation of browser features.

~~~
benatkin
It didn't encourage REST either. It provided $.post but not $.del (since
delete is a keyword in JavaScript) so one could even say it went against REST.
I think it was orthogonal to REST, though.

Here's the docs for jQuery 1.3 from when REST was starting to take off, with
jQuery.post but no delete method:
[https://api.jquery.com/category/ajax/shorthand-
methods/](https://api.jquery.com/category/ajax/shorthand-methods/)

~~~
abritinthebay
It provided $.ajax({method: “DELETE”}) however... so...

~~~
anothergoogler
Making a DELETE XHR was never the issue, browser support was. It's an issue
that was impossible to paper over with a JS library alone, you needed backend
integration. That's why Rails and similar frameworks at the time spoofed
DELETE and PUT requests by creating a POST request with a special param set.

~~~
abritinthebay
All browsers supported the verbs for _years_. IE7 had mostly full support (not
PATCH though, annoyingly).

The problem was mostly backend related: most _servers_ didn't support them.
DELETE for example has been supported for over 12 years in all major browsers.

~~~
anothergoogler
Ah, interesting, my memory is dusty. Now that I think about it, the
limitations of <FORM> were front and center too: A Rails app wanted a "delete
$X" page that didn't rely on JS, and the only way that was going to happen was
with a <FORM>, which only supports GET and POST methods.

~~~
abritinthebay
Ah well yes. That’s quite intentional of course but yeah, an architectural
limitation of that Rails app.

Of course until ~v3 Rails didn’t fully support all verbs so...

------
pier25
> GraphQL offers a way to push all of the logic for specifying data
> requirements onto the client, and in return, the server will execute the
> (highly structured) data query against a known schema. The end result is a
> vastly simplified backend that also empowers the client to execute whichever
> queries they need.

Why is empowering the client a good thing?

Why is moving complexity from the backend to the front end a good thing?

~~~
kbutler
Because you can have one server efficiently servicing multiple clients with
different, unanticipated needs.

~~~
pier25
So, reducing server load?

OTOH if the complexity is offset to the client, and you have multiple clients,
then there is more complexity. No?

(assuming you have multiples types of clients)

~~~
sken
But the client already had to consider what data it needed.

The only difference is that in a REST world it needed to make several calls to
fetch all the data (often waiting for resource references in the nth response
before being able to build the (n+1)th query) whereas now it can fetch them
all in a single query.

So if anything it reduces the client complexity, as well as making it much
easier to extend the API to support new client requirements without having to
resort to REST-style versioning.

------
neoeldex
Why is all the GraphQL documentation so tightly coupled with either Apollo or
Relay? Apollo doesn't work nice with a non-react setup (imhe), not to start
about Relay itself. All the Relay server side stuff makes the client also
really boilerplaty. I don't think i'd buy this book, since it's also apollo
stained.

Does someone have good resources on how to use vanilla GraphQL without the
bloated Apollo/Relay stuff?

I'm currently working on a GraphQL server (using Graphene), and thankfully I'm
able to not use Relay (with which it tightly integrates). So I'm able to
implement my own pagination and filters.

~~~
andrewingram
Relay (Modern) doesn't require _any_ of the Relay-specific schema patterns.
But most of them (connections, the node interface) are useful enough to want
to use anyway.

That said, I agree that too much of the documentation/articles/tutorials about
how to use GraphQL assumes using a particular implementation. I'm far more
interested in talking about higher-level concerns like best practices and data
modelling.

------
zumu
Is Apollo the be all end all GraphQL client these days? I tried it roughly 1.5
years ago and was turned off by all the component wrapping.

Is it bad form to just fetch data via GraphQL and put it in Redux (or other
store)?

I'd like to buy in, but I'd like to keep my data fetching separate from my
view layer if possible.

~~~
maktouch
While transitioning away from Redux, we actually fetched Data via GraphQL and
put it in stores.

Honestly, it was a pain, but it's because we abused Redux.

We progressed by doing the HOC and bypassing Redux but it still was a pain,
because HOC.

We're now at a stage where we updated Apollo versions, and started converting
to the Query components. It feels and work a lot better.

When we started, we thought the same thing -- keeping data fetching separate
from the view layer if possible. We realised that it didn't make that much
sense. Keeping everything in React components is a lot more maintainable and
easier to comprehend.

------
Dowwie
Adopters of GraphQL are quick to call it game-changing, but is it a game worth
playing? It has to add value above the standards already in place. Is it
accomplishing that? How is it more valuable than whatever it is that it
replaces (REST, whatever)?

~~~
worldsayshi
I think I came to this conclusion the other day: GraphQL truly shines when the
variation of ways that you want to access data is significantly more complex
than the complexity of the stored data. In other words, if you want to look at
10 tables in a twenty or forty or more different views (counting the times
when a view is composed into another), then I believe using GraphQL will begin
to show order of magnitude efficiency rewards.

If the number of views is only slightly more than the number of tables then
the rewards are more a matter of taste. It will give you a nice typed
interface to your data and an interactive query GUI. But other tools provide
that as well.

~~~
dmitriid
> if you want to look at 10 tables in a twenty or forty or more different
> views (counting the times when a view is composed into another), then I
> believe using GraphQL will begin to show order of magnitude efficiency
> rewards.

How will it show order of magnitude efficiency?!!

It means that you will have 20-40 views towards a database that only contains
10 tables. Which will inevitably result in highly inefficient queries towards
said database. _Especially_ if a view is composed into another.

There's no magic in GraphQL that suddenly makes that go away.

~~~
Chyzwar
Imagine you have a cross-platform app with multiple teams. You have a lot of
data-driven components like different feed types. You want to avoid situations
that change in backed API needs to be synced with every team/app. You want to
give power to app developers to define efficient queries.

Unless you develop multiple apps or data-driven application there is very
little reason to use GraphQL. Personally, I am in favor of building two APIs:
public/third party REST and JSON-RPC for the frontend. Getting REST right is
difficult and after you create your resources your frontend needs to
workaround incomplete/superfluous data.

~~~
dmitriid
This doesn't answer my question :) You still have 10 tables, and you still
have 40 ineffecient ad-hoc views into that database.

Why is it that any text, and post, and comment about GraphQL focused on
client-side only and completely ignores any questions about server-side?

~~~
Chyzwar
Because your source data will be like 10 tables. But your frontend needs to
access this data in different ways (views). There no way to design your
database to support all possible queries in an efficient way. With complex
queries even caching become tricky.

    
    
      user(id = 6) -> with ('comments') -> with ('votes')
    

ORM - create a complex query that hit three tables. There is no way to
represent this as proper REST service (/userNameWithCommentsVotes - resource).
You end up with REST resources that accept a lot query params. Each endpoint
will create coupling to both data storage and consumer (front-end).

    
    
      User (id = 6) {
        name
        comments {
          votes: {
             up
             down
           }
         }
      }
    

GraphQL shift data access towards the client. It will make multiple DB queries
but it will be trivially cached using Dataloader pattern. You hit DB more with
simple queries but you don't muddle you data schema with ad-hock
views/queries.

People start with pretty REST and normalized Database, then frontend and
third-party requirements demolish this to another "Paypal API". I am not
saying that GraphQL is a silver bullet, you need to structure your frontend
application Graph as well and complex conditional queries are difficult to
express.

~~~
dmitriid
> ORM - create a complex query that hit three tables.

1\. ORM isn't a requirement for REST

2\. A REST endpoint will execute a highly specialised query that will hit all
the right database indices and will return just the dataset required in one
roundtrip to the database.

And since it's a known quantity, it will benefit from: hot db indices and
caches, intermediate caches, and even HTTP caches (because GET requests are
both idempotent and cacheable, for example).

Meanwhile with GraphQL your server will have execute what's essentially
`SELECT <all>` three times (otherwise your "dataloader" won't be able to cache
data for more complex queries) and do all the filtering and joins in-memory
in-code.

> GraphQL shift data access towards the client.

Hahahha wat? The client has no access to data. The only thing it does is send
a query request to the server. The _server_ will parse the query. The _server_
will request data from the database (multiple times). The _server_ will end up
joining, filtering out, caching, figuring out proper auth access to, etc. etc.
to data.

And only then will that data will be returned to the client in the form that
the client requested. The client has no access to data. The only thing that
the client can do is ad-hoc potentially non-perfromant queries to the server.

> You hit DB more with simple queries but you don't muddle you data schema
> with ad-hock views/queries.

Yup. You only muddle your code with those queries (the code needs to find a
way to compose/filter out/etc. etc. etc. the data for the ad-hoc queries from
the client). And you only do multiple redundant and expensive trips to the
database (what happens when the DB is sharded, and some data required for the
query lies in a different shard? What happens when connections are
slow/interrupted? etc. etc.)

> it will be trivially cached using Dataloader pattern.

No it won't. Dataloader only caches some data during one request. On the next
request you will do the same: expensive multiple roundtrips to the database.

Oh. By the way. Remember how you dismissed ORM? Well, your dataloaders and
data resolvers (and whatever other new lingo GraphQL came up with) is nothing
but a very limited and inefficient ORM.

~~~
Chyzwar
> A REST endpoint will execute a highly specialised query that will hit all
> the right database indices and will return just the dataset required in one
> roundtrip to the database.

Each time you need to have a new highly specialized query you create REST
resource. That why I prefer to be honest and just make RPC call.

> Meanwhile with GraphQL your server will have execute what's essentially
> `SELECT <all>` three times (otherwise your "dataloader" won't be able to
> cache data for more complex queries) and do all the filtering and joins in-
> memory in-code.

That fine, because easy cache invalidation is worth it. You will find that
REST complex endpoints will take cache the same data multiple times.

> Hahahha wat? The client has no access to data. The only thing it does is
> send a query request to the server. The server will parse the query. The
> server will request data from the database (multiple times). The server will
> end up joining, filtering out, caching, figuring out proper auth access to,
> etc. etc. to data.

I said data access, not data. The benefit of GraphQL materializes when you
have multiple client application that targets same backend data store. You
describe your data schema and clients can figure out what data they need.

> Yup. You only muddle your code with those queries (the code needs to find a
> way to compose/filter out/etc. etc. etc. the data for the ad-hoc queries
> from the client). And you only do multiple redundant and expensive trips to
> the database (what happens when the DB is sharded, and some data required
> for the query lies in a different shard? What happens when connections are
> slow/interrupted? etc. etc.)

You have cache. Having only one copy of user in the cache is super important.
GraphQL is not creating expensive queries. With GraphQL it is easier to shard
your DB because you will have less joins.

> No it won't. Dataloader only caches some data during one request. On the
> next request you will do the same: expensive multiple roundtrips to the
> database.

Dataloader supports any Cache backend. In production, you will use something
like Redis. Whole point dataloader is to cache between requests. Its supports
cache invalidation as well.

> Oh. By the way. Remember how you dismissed ORM? Well, your dataloaders and
> data resolvers (and whatever other new lingo GraphQL came up with) is
> nothing but a very limited and inefficient ORM.

No, they are query interface. They expose DSL for accessing data. Mapping is
something that can be done in Relay.

~~~
dmitriid
> Each time you need to have a new highly specialized query you create REST
> resource.

I love it how you meander. First you where complaining about ORM creating
complex queries. When I countered with the simple fact that you don't need
ORM, and "complex queries" are highly specialised efficient queries that take
full advantage of DB capabilities, you immediately go off on a tangent talking
about RPCs.

:-\

> That fine, because easy cache invalidation is worth it.

No it's not fine. Because instead of retrieving a simple single highly
optimised dataset in one go you do multiple inefficient roundtrips to the
database.

> I said data access, not data.

access. /ˈaksɛs/ 2\. obtain or retrieve (computer data or a file).

All data access happens on the server through inefficient database queries and
in-memory juggling of data. Clients have no access to data, they send queries.

> Whole point dataloader is to cache between requests.

Dataloader (in it's original form and specification) doesn't cache between
requests.

 _DataLoader provides a memoization cache for all loads which occur in a
single request to your application._

 _DataLoader caching does not replace Redis, Memcache, or any other shared
application-level cache. DataLoader is first and foremost a data loading
mechanism, and its cache only serves the purpose of not repeatedly loading the
same data in the context of a single request to your Application._

If any other Dataloader implementation implements caching between requests,
they are just reinvent the wheel.

> No, they are query interface. They expose DSL for accessing data.

ORM is a DSL at it's core. And that's what "dataloaders" and "resolvers" in
essence are: ORMs.

To quote from Apollo:

 _In order to respond to queries, a schema needs to have resolve functions for
all fields._

    
    
        const resolverMap = {
          Query: {
            author(obj, args, context, info) {
              return find(authors, { id: args.id });
            },
          },
          Author: {
            posts(author) {
              return filter(posts, { authorId: author.id });
            },
          },
        };
    

Oh look. A wild ORM appears! Oh look how it quickly devolves into multiple DB
roundtrips for any non-trivial query.

------
jsnk
I hope John will divide up the book later.

I am interested, but as a guy working more on backend systems, frontend and
mobile will not help me very much. I don't want to pay $40 for majority of
content I cannot make use of.

~~~
pofilat
It isn't $40 for content you don't use; it's $40 for the content you do use.

------
TeeWEE
While GraphQL has it uses, i can't seem to see how putting the query logic in
your frontend is a good thing:

How do you control scaling, and writing performant queries? When you make an
API endpoint you have control over the queries you make and how you make them.

With GraphQL you lose that control right? Maybe its good for internal
projects, where you own the client and server. But often just exposing the
internal DB directly to GraphQL is probably not a good idea. Maybe writing the
DataLoaders yourself is better. But then you are already close to the effort
of writing a simple endpoint.

For simple API's graphql seems like overkill.

~~~
sbr464
With GraphQL you have the flexibility to utilize both REST and RPC patterns,
with the added benefit of a type system and ability to choose the fields
returned on the client. You can write common CRUD queries/mutations similar to
how you would with REST (allUsers/allProjects. If you have a query that you
know ahead of time will be inefficient, you can add in a more RPC or dedicated
endpoint style query that you can optimize how you see fit on backend
(getAllCrazyThings(filters) etc).

For the performance aspect, check out Apollo Engine, which allows you to track
the latency and implications of using different fields within your queries and
mutations over time:

[https://www.apollographql.com/docs/engine/performance.html](https://www.apollographql.com/docs/engine/performance.html)

------
nsstring96
One of the problems I've noticed while using GraphQL (late last year) was that
although there are 'officially supported' libraries in a number of languages,
there isn't really feature parity between them. In particular, I remember that
the Ruby implementation we were using required manually parsing the AST to do
fairly basic operations described in the spec. I wonder if this situation has
improved in the last few months.

------
ilaksh
Looks nice but why would I use GraphQL over JSON queries to a simple document
database directly?

I guess it comes down to how important schemas are to you. Which I know
suggesting they might not be important sometimes is for some people a sin
punishible by death. But for me that's a belief system that doesn't hold up
for everyones application.

------
snarfy
Why should I use Facebook's GraphQL over OData which is an ISO standard? I've
found a few comparisons but I'm curious what the HN crowd has to say.

~~~
nkassis
Feels like GraphQL has more momentum behind it now than OData. OData seems to
have suffered from the fact that it originated in the .Net world which is
pretty much ignored by those outside of it.

------
sakarisson
So let me get this straight.

For the low price of $39 I will get the full book in ebook and HTML formats
when it is done.

But for the price of $89 I will get extra chapters on Server-side rendering,
Offline data and mutations, Serverless and Stripe integration.

So I am clearly not getting the full book for $39.

I just recently refused to buy a game for employing the same dishonest sales
tactics, so this is an easy no thanks from me.

~~~
dlisboa
Honestly, I think people will disagree with me on this (due to some vague "you
don't have to buy it" argument), but it's just too dishonest to me. This is
possibly the biggest rip-off in pricing of any technical book I've ever seen.

If you pay $39 you get 8 fewer chapters than the _actual_ full book. And it's
online only, so no paper printing or publisher overhead. For $89 you get a
video and some extra chapters (that really should be in the book you paid for
in the first place). If you pay $289 (which is an absolute _absurd_ price for
any book) you get exactly what you used to get with books 10 years ago: a book
with all its intended chapters, a mailing list, a glorified IRC channel and a
code repo. Except, again, it's still not even a physical book (so why so
expensive?).

If you pay the "Training" package ($749) you supposedly get superior in-person
mentoring. Except it's not really done by the authors. It all sounds like some
Tai Lopez scam.

I don't want to diminish the amount of work it took to make this book, or the
quality of the authors. I'm sure it's incredible and it seems a pretty massive
book. But I just don't understand these sort of things when it comes to
professional programmers who write books. Supposedly they want to spread this
technology they care about and want people to use it. We as programmers get
paid very well, we're not in need of money. Book revenue is probably not their
main source of income. So why price it out of everyone's range? You're not
gonna reach nearly as many people as just selling it at a reasonable price.

~~~
epicide
I'll preface this with the fact that I completely agree with your sentiment.

> it's still not even a physical book (so why so expensive?)

I have never written or published a book, but my understanding is that the
cost of writing the book far outweighs the cost of actually printing it. Human
time and knowledge is way more costly than some paper and the effort of a
machine that spits out books by the second.

> If you pay $289 (which is an absolute absurd price for any book)

This offer and especially the in-person one seem like they are targeting
businesses. A lot of places will pay orders of magnitude more to have someone
work directly with their employees.

Honestly, about $93/hour is on the cheap side for in-person training. (I'm not
saying it's _good_ training or even close to worth it, just what the landscape
looks like)

Edit: actually, it would be cheaper than $93/hour since I'm not taking the
other things into account. Let's say the book and all the other stuff
realistically make up about $150 of the price (I am guessing the $289 is just
trying to get you to buy one of the surrounding tiers). That's actually
$75/hour for the training.

~~~
dlisboa
> I have never written or published a book, but my understanding is that the
> cost of writing the book far outweighs the cost of actually printing it.
> Human time and knowledge is way more costly than some paper and the effort
> of a machine that spits out books by the second.

Usually physical books are said to be expensive because publishers are the
ones holding the rights to them. They pay the authors in advance and try to
recoup the cost later, with prices as high as the market will bear. The
publishers have some fixed overhead in payroll (for editing, typography, art),
printing, marketing, etc. Add to that the risk of the book not being finished
by the author and the publisher's profit margin and it goes some ways to
justify their pricing (or at least it makes it understandable). The authors
then get only a slim percentage of the sales (if at all).

In this case the book isn't even finished, the full proceeds go to the authors
(or so it seems) and the readers are expected to advance the money themselves
to offset the costs of writing it. The overhead is vastly diminished, there's
no publisher, the authors incur no risk, and yet the price is much higher.
Makes no sense.

