
Why Astronomer is Betting on GraphQL - brunklb
https://www.astronomer.io/blog/3-reasons-why-astronomer-is-betting-on-graphql
======
nippples
I hope one of them is "I like the legal risk that comes with exposing myself
to patent trolling": [https://medium.com/@dwalsh.sdlr/using-graphql-why-
facebook-n...](https://medium.com/@dwalsh.sdlr/using-graphql-why-facebook-now-
owns-you-3182751028c9)

~~~
rywalker
They are working to resolve [https://medium.com/@dwalsh.sdlr/hi-
ezequiel-6855beab08cb](https://medium.com/@dwalsh.sdlr/hi-
ezequiel-6855beab08cb)

Understand the pause, and if we were a social networking company I'd be more
concerned - but already our decision to use GraphQL/React is paying off, as it
differentiates for customers looking to integrate our product into their
product due to the richness of the API that we are inherently providing.

------
mosselman
GraphQL so far to me just seems like a way to facilitate freedom to front-end
engineering in terms of not begin dependent on the back-end when query-ing; I
image that when back- and front-end teams are separate that it can be
frustrating to front-enders to wait for the api developers to have made
something available to them.

At the same time I can see that it works in the other way around; back-end
engineers don't have to keep up with changing query requirements from the
front-end team.

The same is suggested in the article and confirmed in the response to the only
comment:

"The point is that most APIs end up having to support lots of different client
requirements all at the same time... and then those requirements change... and
then they change again. You don't want to have "fix" your API every time this
happens. GraphQL would support a lot of these differing requirements with no
changes to the server code at all."

"You don't want to have "fix" your API every time this happens." I don't see
why not. Requirements change thus code changes, its not a big deal.

The sacrifice you make with this 'not having to change the server side code'
is that you are never able to change the server side code again without
risking that you take away functionality that is somehow used by some client
somewhere. I say 'somehow' because with REST there is usually an endpoint that
is either used or not, but with GraphQL there are relations that get used
through each other which is less straightforward to determine when pruning or
updating your API.

It all depends who you are though. For Github it is probably a good idea to
provide a GraphQL API as this freedom in the front-end will make adoption of
their API and thus their service more likely. If you are a normal company and
you are the only consumer of your API I highly question the added benefit.

I might be wrong though, so if anyone could point me at some high quality
resources on the benefit of GraphQL I am very interested. This article wasn't
really that.

~~~
tgasson
> with GraphQL there are relations that get used through each other which is
> less straightforward to determine when pruning or updating your API

That can be easier since you can add metrics to each individual field rather
than url, allowing you to deprecate rarely used fields knowing what you'll
break and alert only those who are using it of the change

~~~
le-mark
Is this "adding of metrics" to fields part of graphql api, or something the
data store would provide? Apologies but I've only just started exploring
graphql.

~~~
tgasson
No, not part of graphql. Apollo Optics (no relation) is an option, or you can
instrument the fields yourself just like you would implement any other
instrumentation.

------
maxdo
I'm the one suffering right now from graphql hype. The idea is great, but it's
very immature. Android client is just not ready for something bigger then few
simple queries. iOS client is also years behind JS client. If your platform is
not limited to JS, It doesn't worth migration. We fighting with custom mutex
and other painful tricks to make it working.

~~~
martijnwalraven
I'm one of the developers of the Apollo iOS client, so I'm definitely
interested in hearing your feedback. I know we're missing some features
compared to the JavaScript client, but both the Android and iOS clients seem
fairly stable and are used in production. I'm especially intrigued by the need
for a 'custom mutex and other painful tricks'. Maybe this isn't the venue for
detailed discussion, but please open an issue on one of the repos or post a
message on #android or #ios on the Apollo Slack so we can dive into this
further!

~~~
maxdo
I want to reproduce simple use case : header authorization , parallel requests
, if token stoped , I want stop all requests that are behind in the queue,
refresh my token, do requests again. Unfortunately your architecture limits us
to JS style of development when failed request is ok, user will refresh the
page. On mobile it's not the case. You close all the related tickets on
github. So we build our own solution with mutex and other crap to make it
somehow working in that way just because we already invested on backend in
graphql. If not , I'd better avoid apollo and graphql.

~~~
martijnwalraven
I wouldn't call that an architectural limitation, but you're right the default
network transport in Apollo iOS doesn't currently support your use case. You
can plug in your own network transport implementation however, or integrate
with something like AlamoFire for example. I'd definitely like to make this
easier and document it better, but I don't think it's a good reason to avoid
Apollo or GraphQL altogether. I'm not sure which issue I closed before, but
please reopen it if you want to discuss this further and make the client work
for you!

~~~
maxdo
You simply can't do it on android and it's huge degradation for any project
that cares about quality

------
chmike
I find that GraphQL has a very complex syntax. While it has the benefit to
avoid multiple requests and the time penalty that comes with it, I think it
should be possible to define a simpler and more orthogonal query language.

~~~
Cthulhu_
Writing the same logic (querying + filtering) out in regular REST API calls
and JS, or SQL queries, probably ends up with a similar complexity (if not
more). It might be possible to create a simpler query language though, maybe
with some middleware that converts it to a full GraphQL query. I guess it's
comparable to SQL, and there's a number of alternatives / front-ends to SQL
that will translate down to SQL.

------
chlee
Does anyone have experiences using GraphQL in production? Trying to understand
if GraphQL will be a good alternative to REST for new projects or is GraphQL
being hyped up like mongoDB was 7-8 years ago.

~~~
djmashko2
Here's a page we put together with case studies of companies using GraphQL in
production: [https://www.graphql.com/case-
studies/](https://www.graphql.com/case-studies/)

There are articles from GitHub, Shopify, Artsy, Walmart, Coursera, New York
Times, and more! And these are just companies that have bothered to write an
entire article about their experience.

------
AznHisoka
Facebook keeps coming up as the evangelist for GraphQL but didnt they move
AWAY from FQL in 2015?

~~~
foota
FQL is completely different from GraphQL.

------
stuartaxelowen
So, why not just use StructuredQL?

Seriously, we have DB user roles for access control, and most database traffic
from web or app dashboard clients is read based anyway.

~~~
anentropic
GraphQL is a way of exposing an API

It is not a direct interface to the database backend

DB user roles for access control won't help much if you had the credentials to
your db stored in javascript source so that the web front end can query your
postrges db directly

~~~
stuartaxelowen
Passwords in your javascript app is a crazy idea - the user goes through auth
anyway, why not store their credentials there?

------
anonyfox
Same as React: do not use if you plan to do anything that Facebook might
dislike or steal, or want to sell your startup, or work in a bigger corp (ask
the legal guys before).

~~~
denisw
This advice makes no sense for GraphQL, which is a _protocol_ rather than a
piece of software. In fact, the perhaps most-used GraphQL implementation these
days (Apollo) is not written by Facebook and is purely MIT-licensed.

Of course, you do need to ask yourself these legal questions if you use Relay.

~~~
hobofan
The major Apollo libraries depend on Graphql.js, which is affected by the
patent grant.

Apart from that GraphQL is the only one library with a known patent by
Facebook, so you would actually want to get the patent grant there.

[0]: [https://github.com/apollographql/react-
apollo/blob/master/pa...](https://github.com/apollographql/react-
apollo/blob/master/package.json#L108)

[1]: [https://github.com/apollographql/apollo-
server/blob/master/p...](https://github.com/apollographql/apollo-
server/blob/master/package.json#L30)

[2]: [https://github.com/apollographql/apollo-
client/blob/master/p...](https://github.com/apollographql/apollo-
client/blob/master/package.json#L76)

------
NicoJuicy
Betting on ... Great for blog posts, but not great for productivity.

You should blog in a year about: why we migrated from GraphQL to Postgress (
if it's that immature as i see in the comments)

~~~
watwut
You cant migrate from GraphQL to Postgress. The two technologies cant possibly
replace each other - either way.

~~~
chmike
Well, we could use SQL instead of GraphQL and would get much more freedom on
the requests we could make. I supose that this was the idea of nicoJuicy.

~~~
antonvs
The problem with that is it assumes that there's no logic on the back end,
outside the database, that transforms data before sending it to the client.

If all you want is a way to submit SQL queries from a front end to a SQL
database, you could just have the front end talk directly to the database.
There's no need for a back end app in that case. But APIs are for talking to
applications.

~~~
tedmiston
It also assumes all of the data is in one database. A common use case for
GraphQL is to wrap multiple REST APIs and proxy calls to them as a "master
API".

