
Facebook’s GraphQL gets its own open-source foundation - bodecker
https://techcrunch.com/2018/11/06/facebooks-graphql-gets-its-own-open-source-foundation/
======
burtonator
I did a huge heads down on GraphQL vs AppSync vs Firebase for an app I'm
building around document collaboration, annotation and sync for people working
with PDFs and web content
([https://getpolarized.io/](https://getpolarized.io/)) - it's kind of like an
offline web browser.... anyway.

GraphQL is super awesome at what it does but it's definitely not designed for
rapid prototyping applications.

The thing about GraphQL is that it's middleware. It's designed to act as
really nice glue between multiple backends.

It solves a lot of nice problems like over-fetching too much data, calling too
many APIs, etc.

The problem is that you really don't need these to get an app shipped
immediately.

The REAL sweet spot for GraphQL is for a company like Netflix or Facebook
where you have 1500 APIs and tons of problems with data over-fetch and you
have the time to sit down and do things right.

I think I'm going to end up going with Firebase just because you can bang
something out FAST and get it shipped.

It's not going to be perfect but you can ship an MVP and start making revenue
and/or grow your user base while you figure things out.

~~~
013a
GraphQL to REST is a more typical comparison. In this case: designing a
GraphQL API is substantially easier to both make and consume; while REST just
tells you "here's some guidelines, now go do it however you want", GraphQL
enforces a much more consistent view of how an API should look, while allowing
clients much more freedom in how they get the data they need.

Where you start running into issues is the surrounding tooling. Integrating a
typical REST API into an APM monitoring solution is a cinch, because all of
these tools know how to read the incoming requests, HTTP methods, paths,
bodies, etc. With GraphQL, you might be left building glue for your APM tool
of choice, or just using the highly limited, but at least specialized, Apollo
Engine. Enforcing strict rate limiting is easy with REST; very difficult with
GraphQL due to how complex and free-form queries are.

Optimizing your backend to support those free-form queries is also (I dare say
_intractably_ ) difficult; I haven't seen a single backend framework which
doesn't actively encourage an N+1 problem on any query which returns multiple
objects of data. AppSync as well, my god is that an evil play from AWS; if
you've got separate lambda functions serving all the different nodes in your
graph, a single query could trigger dozens, or even hundreds, of invocations.
Combine that with their guidance to use Aurora Serverless and any casual
observer might say that they're actively exploiting the unfortunate ignorance
of an engineer trying to jump on the latest trends.

I don't believe any of these things are problems with GraphQL. I think they're
issues with ecosystem immaturity, and I hope they get better over time.
Frankly, every single backend library I've used sucks; its designed to be
awesome on the frontend, and it is.

I think you're right that, right now, its best suited to large organizations.
Large organizations can engineer around all of its issues and extract a LOT of
value from it. Medium organizations are almost immediately going to run into
ecosystem immaturity and scaling issues. Small organizations are going to get
the most value from an "all in one" solution, whether that's Firebase, or a
simple REST API on App Engine, or something like that.

But I could be wrong in my analysis that its not a core issue with GraphQL,
and there are subtle complexities with the API definition language which make
scaling it for anyone who isn't Facebook intractable. Time will tell.

~~~
ruslan_talpa
> I haven't seen a single backend framework which doesn't actively encourage
> an N+1 problem on any query which returns multiple objects of data

Well then you haven't really looked :)

[https://join-monster.readthedocs.io/en/latest/](https://join-
monster.readthedocs.io/en/latest/)

[https://github.com/graphile/postgraphile](https://github.com/graphile/postgraphile)

[https://www.prisma.io/](https://www.prisma.io/)

[https://subzero.cloud/](https://subzero.cloud/)

These are all examples of tools/libs that implement a graphql api without a
N+1 issue

~~~
013a
Those are great resources. But all of them appear to be tightly coupled with a
SQL storage backend. That's valuable, but what I believe the ecosystem needs
is a generic system which can "pre-compile" a GraphQL query into a backend
language data structure which the developer can then transpose into a database
query.

I think Facebook's Dataloader is more close to a solution.

~~~
BenjieGillam
PostGraphile is built on Graphile Engine which is completely backend-
independent (like GraphQL itself). This is what we use in PostGraphile for the
"look-ahead" functionality, allowing you to build a database/API/backend query
that represents a full GraphQL query as one action. You can read more about it
here, though it's currently not as well documented as PostGraphile itself.
[https://www.graphile.org/graphile-build/](https://www.graphile.org/graphile-
build/)

------
orta
As someone who knows a few of the folks involved in this foundation, I think
this is a real net positive for everyone who builds GraphQL APIs and is
involved in improving the ecosystem.

------
xrd
I remember when I was at RealNetworks a long time ago and Microsoft and Real
were competing over the future of multimedia languages (SMIL vs HTML+Time). I
was on some of the standardization committees and remember being surprised
when some of my colleagues suggested that standardization was used by
companies like MS to slow down the innovation process (and catch up to faster
starts like RealNetworks had made). I wonder how often open source foundations
serve the same purpose, or if these are truly embraced by companies like
Facebook? Is there a reason internally Facebook would have fought something
like this? Is it all roses?

~~~
syn0byte
Generalization of Hanlen's razor: Never attribute to malice what can be
explained by laziness/greed/stupidity.

FB has GraphQL stable and doing exactly what they want it to do. Now they can
pass it off to a foundation for maintenance and blame without having to pay
out of pocket.

~~~
krschultz
GraphQL isn't a system per-say, it's a spec and many tools around it. Putting
the spec in a foundation (with a few of those tools) gives the entire
community certainty about the direction of the project. Hopefully that spurs
more people outside of FB to commit to GraphQL.

The existence of the foundation is orthogonal to FB's internal investment and
usage of GraphQL, which was and will continue to be significant.

~~~
chrisweekly
>"per-say" -> "per se"

Right pronunciation, but it's Latin. :)

~~~
krschultz
Thanks! At least I learned something today.

~~~
tannhaeuser
per se = "in and by itself"

Having given tutoring in Latin when I was 15, I'm always dying a little inside
if I'm reading "per say".

------
mohsen1
Both Swagger (Open API Spec) and GraphQL are now part of the Linux Foundation!
That's cool!

------
jondubois
I'm not a big fan of GraphQL. Its main benefit is for serverless which I am
also not a fan of. It shifts all the control to the client and makes the
server generic which actually takes away flexibility overall.

------
LeicaLatte
Are there good alternatives to Apollo at all?

~~~
mxstbr
There's lots of alternatives, but whether they are good or not depends on your
use case:

\- Relay by Facebook, it's own GraphQL client:
[https://facebook.github.io/relay/](https://facebook.github.io/relay/)

\- Urql by FormidableLabs, an effort to build a simple React GraphQL client
that covers the 80% use case:
[https://github.com/FormidableLabs/urql](https://github.com/FormidableLabs/urql)

\- GraphQL Request by Prisma, a minimal, universal GraphQL client:
[https://github.com/prisma/graphql-request](https://github.com/prisma/graphql-
request)

Plus a variety of smaller ones like Lokka
([https://github.com/kadirahq/lokka](https://github.com/kadirahq/lokka)),
FetchQL
([https://github.com/gucheen/fetchql](https://github.com/gucheen/fetchql)) and
micro-graphql-react ([https://github.com/arackaf/micro-graphql-
react](https://github.com/arackaf/micro-graphql-react)).

It's all about the tradeoffs you want to make: if you're building a React app
your can't go wrong with Relay or Urql, if you're writing one-off (universal)
scripts graphql-request is probably your best choice, etc.

------
tw1010
Oh great, an ad that covers the entire page on mobile. Guess I'm not reading
this article then.

~~~
jmeyer2k
I don't think they care if you read the article. They just care that you saw
the ad.

~~~
ndnxhs
Sums up 90% of news websites. Content gets upvoted because of the title and
the few that do click through get attacked by ads.

------
nikhilsimha
About time.

------
beders
N+1

~~~
leddt
DataLoader

~~~
mlevental
abandoned

~~~
andrewingram
It's a pretty simple library, does it need commits every month to prove that
you should still use it?

~~~
mlevental
code rot is a thing

~~~
andrewingram
It is, but it’s not a universal rule. In the 2+ years I actively used
Dataloader (not using GraphQL-JS right now), I had one feature request which
got implemented, but other than that it was perfectly stable and fit for use.

------
degyves
Great. Another solution for an already-solved, already-standardized query API
language (SPARQL).

~~~
i_phish_cats
SPARQL demands a certain data model (triple stores). Also, everything about it
smells like ivory-tower academic snobbery + ultra-large-enterprise crap.
GraphQL does neither.

~~~
degyves
GraphQL also demands a certain data model. Just that it is not standardized.
And no, RDF/XML is not the only representation for SPARQL. It can deal also
with JSON.

~~~
nevir
GraphQL has no demands on your data model. You can do whatever you want behind
the schema you provide to client apps

~~~
degyves
I think you should read it directly from the website: "GraphQL is a query
language for your API, and a server-side runtime for executing queries by
using a type system you define for your data." You need a type system to
bypass the datamodel. Just pushing the issue around.

