
Why use GraphQL, good and bad reasons - vvoyer
https://honest.engineering/posts/why-use-graphql-good-and-bad-reasons
======
kodablah
Con: Unpredictable code paths (at least in complex use cases).

I've seen so many times GraphQL implementations or ad-hoc equivalents with
user supplied property and filter requests, that regret giving the caller so
much flexibility. IME, flexibility is a bad thing because in the API world,
often once you cross a feature bridge, there's no going back. I say be very
restrictive in your API for many reasons. And for that UI use case, I disagree
with a complete client-side/server-side dev separation. Unlike data APIs,
backend data requests for frontend use should be tightly tailored to what is
used. GraphQL is just another way to forget what you've exposed and also allow
clients to hit never before seen code paths to your backend. There are
security, bloat, and maintenance concerns...keep the UI backend thin and light
and inflexible and strict and limited yet agile and volatile and you'll be so
happy you did a couple years down the road.

~~~
dcosson
None of these problems are GraphQL-specific though. Say someone wants to build
a feature that requires some attribute or joined model we weren't exposing
before. Maybe someone else tells them no for all the
caching/performance/complexity reasons mentioned above. That's a slippery
slope leading towards a culture where nothing ever gets done because all the
senior engineers default to saying "no" to everything, which isn't a place
people want to work and probably isn't great for the longterm outlook of the
company.

So assuming the feature is going to get built, the implementation might
involve sticking the extra attributes in an existing route, or might involve
creating a new custom route just for this use. Both of these options have
pro's and cons that need to be weighed in the given situation based on usage
patterns. And both are possible with or without GraphQL. But they should
require just a few lines of configuration in GraphQL vs more lines custom
boilerplate code in your controller in a traditional MVC framework, which is a
nice win for GraphQL.

The problems can arise whenever people start thinking some tool is basically
magic where there's no wrong way to use it and it'll solve all your problems,
instead of thinking criticially about how to use the tool and what tradeoffs
involved. And this tends to happen much more easily with a hot, new tool like
GraphQL than a more established one where people have more experience with the
downsides.

~~~
kodablah
> That's a slippery slope leading towards a culture where nothing ever gets
> done because all the senior engineers default to saying "no" to everything,
> which isn't a place people want to work and probably isn't great for the
> longterm outlook of the company.

No, and thinking in absolutes like this is what green lights extreme
flexibility exposed to the public internet.

In general, all query possibilities from the public internet should be
accountable and eagerly tested/auditable. And don't let complaints about
stodgy seniors or flexibility make you do otherwise, development efficiency
and tight public internet predictability are not mutually exclusive.

Again, to put it simply, it is very rare to need extreme flexibility in
publicly accessible APIs. And articles like this one foolishly refuse to make
that clear. In the meantime, super flexible data access schemes are lauded for
their help to client side developers, scary. The org can be tightly
integrated, don't let the ridiculous idea of having some devs not allowed to
do any server side code force these loose-lipped systems on your users.

~~~
foota
There are graph ql build systems where you can generate a list of queries used
on the frontend, which should help with your concerns over total flexibility,
while still allowing easier use of new queries.

~~~
kodablah
If the frontend can use the API, can I, the guy with a curl command or
headless browser, use it too? How are you generating that list of queries from
my machine? Unless the surface is sufficiently small to get all permutations
at which point no prob, my issue is with flexible GraphQL systems.

~~~
laurencerowe
> If the frontend can use the API, can I, the guy with a curl command or
> headless browser, use it too?

No.

> How are you generating that list of queries?

I believe the queries in the device UI code are replaced with identifying
hashes as part of the build and those prebaked queries are deployed to the
GraphQL server.

> Unless the surface is sufficiently small at which point no prob, my issue is
> with flexible GraphQL systems.

This is still as flexible for UI developers since this is simply a build time
optimization / limitation.

For publicly accessible GraphQL APIs I believe the common approach is to
calculate a cost for the query and limit what users / queries can do that way.

~~~
kodablah
In the case of turning flexibility at compile time to a fixed set at runtime
and the server side only accepts that fixed set, I'd say that's definitely a
lot less of a concern than the literal GraphQL queries I've seen in use at
runtime by UIs. At that point, your only major concern is how many of those
devs use those sans review by person familiar with the storage that could
optimize it. After that, your fixed hash request hasn't improved things from a
runtime standpoint over a fixed URL request. The disappointing internal team
segregation that makes this a required path to go from actual query and
programming languages to pseudo ones is concerning.

But for that common approach for APIs you mention, that cost calculator is a
bit scary vs limiting the caller. Now if you're a big shop and you need to
essentially expose a query language, ok. But for most, the flexibility is
really not necessary and bites later with all the possible combinations of
requests.

------
hn_throwaway_99
This is kind of touched on by other comments here, but after using GraphQL
heavily on a bunch of different projects for both native apps and web UI front
ends, one of the biggest benefits I've seen is how it enables the individual
teams (front end and back end) to work faster, more efficiently, and more
independently.

Our dev process for using GraphQL:

1\. Product and design come up with screen designs and workflows.

2\. Importantly, the _front end teams_ then take a first stab at writing the
GraphQL type contracts, fully doc'ed (we use a Node backend, so it's easy for
the front end folks, even native app devs, to know enough JS to write these
type strings). They then confer with backend folks on the contract to get
agreement, and front end folks write mock endpoints for these contracts. This
allows the front end teams to get off to the races early with a working
(albeit mocked out) backend. Since the GraphQL type contracts are optimized to
closely match the front end screens, it makes the front ends _much_ simpler.
With native apps it also means there are a lot more things we can fix with
just a server change, not requiring an app store release.

3\. Backend folks then start implementing the GraphQL resolvers, which in our
architecture is mainly orchestrating microservices. The great thing about
GraphQL here is that it essentially serves as a "decoupling layer", giving the
backend folks a lot more freedom to change and switch up the microservices as
long as the GraphQL contract is still respected.

4\. Once the GraphQL resolvers are done, we switch out the mock resolvers.
Usually there are a couple of edge cases or other bugs to fix, but for the
most part we've seen very little disconnect.

~~~
toomim
How is that different than with REST?

It sounds like the advantage you're citing is a separation of code into client
and server, with a well-specified API between the two. You can write a well-
specified API with either REST or GraphQL. Is there something about GraphQL in
particular that is helping here?

~~~
tohjustin
I guess it's makes the front-end a whole lot easier to implement.

To fetch all the data that the app needs to render on a single view, the code
would only need to make a single API call to a graphql endpoint and you only
have to deal with a single, neatly formatted response.

As opposed to the traditional way of making multiple calls to different REST
endpoints, you had to write quite a bit of code to transform & merge the data
from each response before using them to render your views.

~~~
littlecranky67
> To fetch all the data that the app needs to render on a single view, the
> code would only need to make a single API call to a graphql endpoint and you
> only have to deal with a single, neatly formatted response.

If the frontend devs come up with the GraphQL schema definition, they could
also come up with a single REST request definition with very specific DTOs
needed for that particular view/workflow. You would have the same single,
neatly formatted response (caching included). There is no difference what
technology you use here, as long as your API is designed UI-first and your API
design (or the REST facade for microservice orechstration) is developed
according to the UI.

If you go API-first, you will end up doing lot of REST calls to get the data
you need for your view, but you would encounter the same problems if you were
to model your GraphQL queries API-first, before you design the UI workflow.

~~~
wereHamster
> If the frontend devs come up with the GraphQL schema definition, they could
> also come up with a single REST request definition with very specific DTOs
> needed for that particular view/workflow

The GraphQL schema is a unified, standardized language that describes these
objects, types and relations. How many different flavours of REST exist out
there? Every company interprets REST slightly differently, uses different
conventions etc. Imagine every company in the world that uses REST in any
capacity used the same documentation tools (eg. swagger), same conventions to
describe relations, where all the tools could automatically generate code and
types from the API definitions, with zero effort from the development team.
What a wonderful world.

~~~
littlecranky67
While I agree about people being very vocal about the "right" REST this will
not be an issue in this scenario. If you design UI-first and want that little
"single HTTP request" that contains all data, you will very likely just define
a single DTO entity which will be JSON data - very widely used and understood.
There is not much ambiguity in REST here to do it "wrong".

If we talk about write operations/commands, you have the same issues with
GraphQL mutations as with REST, there is more than one way to do it, semantics
might vary, people will create special fields on the DTO payloads to carry
error codes, transactional ids etc. No standards here on both sides of the
curtain. I've seen people doing multiple HTTP POSTs do something that should
be transactional and a single HTTP POST with rollback on failure; and I am
sure there are GraphQL APIs out there that do the same operation performing
multiple GraphQL mutations that should be a single, safe transaction etc.

Plus, while REST semantics is debatable and many flavours exist, some common
ground like error codes and defined cache semantics exist that integrate well
with existing solutions (caching CDN, Loadbalancer etc.) while GraphQL is very
lose on this end.

------
dustingetz
The backend scaling/complexity problems originate in the database, its kind of
cute the way they put it: "Making the graph-oriented way of getting data fit
over an SQL database can be tricky." Tricky vastly understates this: we are
talking about ORM, the "vietnam of computer science"

Clojure ecosystem has an immutable database, Datomic, which is designed for
functional programming and fully solves the impedance mismatch. Datomic "Pull
queries" is essentially GraphQL – and even predates GraphQL by a year!

Unlike GraphQL, Datomic is also a real database, competitive with SQL and can
express relational filters and joins. Datomic is designed for the read-heavy
data modeling loads that, today, SQL (and mongo, etc) is used for in anger.
[https://www.datomic.com/](https://www.datomic.com/)

~~~
SmirkingRevenge
Before clicking through, I never knew that datomic has dependancies on AWS
specific services. That's a serious downside, for many cases.

~~~
bhurlow
Datomic "on premise" version is not dependent on any AWS services and can be
run on any box using vanilla java

------
theptip
I've still not seen tooling in the Python ecosystem to make a GraphQL API
actually safe to expose to the internet -- without query complexity policing,
a malicious client can construct queries that will take an effectively
infinite amount of time to complete, and take out your DB connection.

Github handles this problem: [https://developer.github.com/v4/guides/resource-
limitations/](https://developer.github.com/v4/guides/resource-limitations/)

Is this something that's generally solved in other languages? (I've seen a few
plugins on NPM that tackle the problem). Or is this just not something that
implementors are worrying about?

------
voidr
Most GraphQL presentations I have seen tend to construct the following
strawman scenario:

\- we have a REST API that forces the client to make too many requests \- it's
impossible to fix the REST API for some reason \- the app is slow because of
the multiple REST API calls

The followup:

\- we bring in GraphQL and everything becomes super fast and efficient \- the
people who couldn't provide an efficient REST API, can all the sudden provide
a GraphQL interface \- the cost of implementing and maintaining GraphQL is
usually glossed over

The reality is that GraphQL has a lot of drawbacks that are overlooked:

\- it might be cheaper to fix the REST API than to implement GraphQL \- it's
one extra service or module(if you are lucky) on your backend to look after \-
protecting the database from bad queries becomes an order of magnitude harder
\- you will have to maintain an additional GraphQL schema \- the client side
tooling for GraphQL is far from simple

Depending on your needs, it might still be worth it, I would just wish that
GraphQL presentations would be more honest about these.

------
atom_arranger
Adding to the pros:

Self Documenting - GraphQL documents the shape of responses properly. It's
like Swagger if the spec always actually matched the implementation. This is a
big win for everyone. Backend doesn't have to think about updating separate
documentation, frontend always has an up to date and accurate spec.

------
iamleppert
If you go down the GraphQL path be aware you are trading the simplicity,
flexibility and universality of HTTP, which you can debug via cURL, to a
custom protocol and fat client owned by Facebook. It isn’t even an open
standard. The last time Facebook tried to make HTML better we got FBML,
remember that?

Be wary of tech that promises to solve all your problems that you yourself
don’t understand and haven’t solved. You’re going to end up with at best
another set of problems.

~~~
nicolasd
That's not true. "GraphQL requests" are _just_ POST requests with a JSON that
contains "query" and "variables".

So it's not the request itself that is not debuggable, but maybe the query
interpreter on your backend with the framework you're using.

~~~
iamleppert
Have you ever seen one? They are impossible to formulate with simple tools
like curl on the command line. So my original point stands.

------
iEchoic
> A GraphQL API (server) implementation, out of the box, will have better
> performance than a standard REST API - for the clients. Since resolvers are
> called in parallel, data will load faster.

What does this mean? Are these theoretical REST endpoints fetching information
serially, or something?

Almost all of our REST endpoints fetch all of their information in a single
hand-optimized SQL query. How is GraphQL going to run faster than that?

~~~
tango12
This. Exactly this!

I think anyone with experience will realise that you can get pretty much all
the benefits of GraphQL with just a more sophisticated RESTish API.

There is however, one thing that I think GraphQL backends have that REST
backends don't, and that's the idea of introspection. Every GraphQL backend
must be able to serve it's API data models and types. And I think the
community tooling that leverages this makes it an amazing experience for app
developers. No SDKs, any GraphQL client works with any GraphQL backend.
Codegen esp for Android type apps to skip boilerplate of mapping APIs to
POJOs. IDE autocomplete. I really think that the killer feature of GraphQL is
that.

We built a JSON DSL over a normal POST endpoint. Most GraphQL advantages sound
"not really true" to me because you can always achieve the same thing (almost)
yourself anyway.

~~~
sixdimensional
Just wanted to chime in, OData had basically the same idea, however, from
personal observation, somehow just didn't really become so popular, maybe
because of its original association with Microsoft, etc. and also partially
maybe its implementation. But it was pretty close, and today a lot of products
support OData.

I did note recently while reviewing the Microsoft API standard guidelines they
share on GitHub [1], that there is a non-OData standard, but OData like
recommendation for working with queries across collections, which I find to be
pretty good and pretty generic.

It seems like today you can do what you said - a sophisticated RESTish API
without the model metadata piece pretty easily - but that metadata piece adds
a lot of value.

[1] [https://github.com/Microsoft/api-
guidelines/blob/vNext/Guide...](https://github.com/Microsoft/api-
guidelines/blob/vNext/Guidelines.md#9-collections) \- see sections on sorting,
filtering etc.

~~~
dragonshed
This used to drive me crazy when GraphQL was first announced without a working
download, compared to OData and several usable implementations.

At the time there was also a compelling js library supporting OData.. [1].

    
    
      > Breeze.js: Rich Data Management for the JavaScript Client
      > Client-side querying, caching, dynamic object graphs, change tracking and notification, model validation, batch save, offline support ...
    

[1] [https://github.com/breeze/breeze.js](https://github.com/breeze/breeze.js)

Unfortunately I never had the opportunity to use it for a real project.

[Edit formatting]

~~~
sixdimensional
Yeah, I have a project recently where GraphQL is actually a good fit
conceptually, but I need a complete .NET client/server implementation and the
open source ones are _just_ about there, but I was still not confident enough
to use it yet. Ugh.

That Breeze framework was actually always super impressive. I guess there's a
company behind it too. I've implemented some stuff with Telerik Kendo UI and
OData (data grids, pivot tables) and it also is still working really quite
well.

------
pranayairan
Coming from Mobile developers experience :

\- Graphql does allow you to specify data you need and make the user
experience better but this is only true in theory. Since in graphql it is so
easy to ask any data there are high chances of your queries not optimized and
you end up doing a complex operation spanning multiple domains because you can
do it. In REST since domains are tightly defined chances of non-optimized
request are less.

\- Another major con with GraphQL on mobile is there are no alternatives than
Apollo client yet. This ties you to 1 solution for your entire application.

\- There are companies that tried to enable Querying over rest. Though it is
not as flexible as GraphQL.

~~~
sgk284
Re: specifying data - In my experience, you always want to overfetch anyway if
you want your offline experience to be any level of reasonable.

It's pretty lame when you're offline, see an item in a list, click on the
item, and then the new view has no additional information that wasn't already
in the list.

That said, I've built a fairly sizable GraphQL API at my startup
([https://banter.fm](https://banter.fm)) and am pretty happy with it, though
not 100% convinced I'd use it again.

------
Vinnl
I don't see why "rich UI/UX-based applications" is listed as "mobile-first".
Sure, GraphQL is probably great for highly dynamic client applications, but
why would that be limited to mobile?

As far as I can tell, GraphQL primarily allows you to trade client flexibility
for back-end complexity. If you're willing to take the additional complexity
on the back-end, GraphQL allows you API clients to iterate far quicker, and
removes (or at least lessens) the dependency of the client on the team
maintaining the back-end. If that's not worth it to you, don't use GraphQL.

~~~
sametmax
It appeals to big structures, because they often have many clients but much
less backend endpoints.

If you have one server side code base but targets the web, the mobile, an
customer api, a desktop client and embeded devices, it's a net win.

However, if you just have web + mobile, the complexity may not be worth it.

------
aaronblohowiak
One huge benefit is that the client controls the response shape and the same
server will power multiple different response schemes without requiring any
changes. Very nice for supporting N types of clients.

------
guiriduro
Correct me if I'm wrong, but having read around the topic of GraphQL with a
slowly-changing, largely static catalogue type appication in mind (ideal fit
for CDN in front of REST); I remember a few horror stories around GraphQL not
being CDN-friendly.

Perhaps if you have a dynamic or real-time data-lake or messaging-style app
with quickly-stale data that would need to be talking to regional server
clusters anyway, then GraphQL has benefits on top for schema independence etc.
But I wonder if its CDN caching story has improved (not just client-side as
mentioned.)

~~~
accountantbob
I'm helping to move a big 10B per year ecommerce site to graphql. This lack of
tooling support around graphql (vs REST) is a big minus currently.

Some examples: CDN is a big one that you mention. Our vendor (the biggest in
the industry) has no support for GraphQL beyond what they do for REST or html
pages. We've talked about moving the query into the path or as a parameter but
then we have to figure out how to determine what can be cached. With REST it
is easy: cache /sku, /product, etc but never /guest, /order, etc.

Tools that do performance monitoring (AppDyn, datadog, etc) don't grok GraphQL
well. Quick example is response codes. What's the http status code of a graph
response that has a partial failure? If you make it 200, then those tools
won't see any errors. We put the error codes in the response body and those
tools aren't parsing that for message failures.

~~~
filleokus
>Tools that do performance monitoring (AppDyn, datadog, etc) don't grok
GraphQL well.

If you haven't seen Apollo Engine[0], you might want to checkit out. Maybe its
too expensive or problematic in some way for your scale, but I've used it
quite successfully (on a much smaller scale). You implement their status-
format for your responses, and place a proxy between your graphql server and
client requests, which then siphons of the status data to them.

Regarding CDN, it would be interesting to see if someone tries to do some
"computing on the edge" (i.e Cloudflare workers) to calculate/modify cache
info from the graphql response.

EDIT: Apparently Apollo have a proposed standard for indicating cache status
inside of responses[1], which then Engine can use to calculate correct cache
headers for the CDN.

[0]:
[https://www.apollographql.com/engine](https://www.apollographql.com/engine)
[1]: [https://github.com/apollographql/apollo-cache-
control](https://github.com/apollographql/apollo-cache-control)

~~~
kentonv
The Apollo people have a prototype of Apollo Server running on top of
Cloudflare Workers, at the edge: [https://github.com/jbaxleyiii/apollo-server-
cloudflare](https://github.com/jbaxleyiii/apollo-server-cloudflare)

(Disclosure: I'm the tech lead for Workers at Cloudflare.)

------
dustingetz
OCFX, it appears you've been shadowbanned. Your question is very good so
reposting it here:

> Does anyone know how GraphQL manages (or if it even can) to sort and filter
> across microservices? It seems impossible to me to do from any client. If
> you have a list view that is made up of data from microservice a, b, and c
> and you try to sort on a column from microservice b, how does microservice b
> know how to sort then data when there are additional constraints applied to
> data on other microservices such as a filter applied to microservice a. Does
> that make sense? Basically I feel very frustrated when it comes to sorting
> and filtering across microservices, some people at work think that GraphQL
> will solve this and I have found absolutely nothing to support the claim
> that it would help us with this. Thoughts?

~~~
sokoloff
I "vouched" for that question (you also have enough karma to do that). Click
on the timestamp of the question and you'll get an option to vouch for it as
adding to the conversation.

------
headcanon
One thing I'd like to add, if your primary data store resides in a document-
oriented DB like Mongo or Dynamo, GraphQL provides that missing "relational"
piece, and allows you to create a strong schema without having to manually do
"joins" in application code. I realize attempting to "relationalize" a
document store isn't how you were supposed to use it, when I started at my
current company thats what they had going on. GraphQL was essential for
improving the sanity of how we grab data from dynamo, and gave us a good way
to iteratively migrate over to Postgres where appropriate.

------
chvid
Seriously they are both bad ideas (graphql and rest). Just create a remote
method doing exactly what you need with a well-defined metaprotocol. It really
doesn’t have to be so hard.

------
TheAceOfHearts
This reads like an Apollo ad.

I'll start off by noting that I haven't been keeping up as much with the
latest developments within the GraphQL ecosystem so some of my comments may be
outdated.

They ignored one of the most thorough GraphQL implementations: Sangria [0],
which provides almost everything you need out of the box to implement a fairly
sophisticated application. I guess that Scala isn't very cool. I'd reluctantly
agree that most of the community seems to be centered around the JS ecosystem,
but I don't think it's fair to so easily dismiss the dozens of GraphQL
implementations out there. Perhaps I'm wrong about this, but based on the
author's bio it sounds like they're most experienced with JS and Ruby, which
means that they're probably heavily biased towards those two languages. I
don't think they've seriously evaluated each library extensively and they
should be transparent about it if that's the case. I've used GraphQL with
Elixir, Node, and Ruby, but took a lot of inspiration from Sangria's docs when
working on my apps.

I don't know if it was meant as a criticism, but I actually think that the
declarative syntax used with Elixir and Ruby is quite nice. The examples
provided for the reduced "Developer Experience" are rather weak in my view. I
think the author might just be most comfortable with JS.

> Secondly, as said in the second point, a GraphQL API server needs
> optimisations and maintenance.

> Making the graph-oriented way of getting data fit over an SQL database can
> be tricky.

IMO, this is severely understating the complexity. Depending on the type of
application, you should probably be prepared to have at least one engineer
dedicated full-time to maintaining your GraphQL server.

It's a lot easier to write a secure REST API with good performance than it is
to achieve the same thing with GraphQL. The author doesn't even mention
anything about the huge headache involved with protecting against malicious
queries.

I immediately fell in love with the idea of GraphQL when I first heard about
it, but as I started to use it I found it wasn't some magical solution. You'll
probably end up having to figure out a lot of stuff on your own since the
technology is so young, so be prepared to invest a lot of time in it. It
depends heavily on your use-case and your team's collective experience, but
I'd probably lean towards avoiding GraphQL within a small team.

If race conditions aren't a concern, you can wrap a REST API with a small
GraphQL server. The inverse is also possible.

There's no mention of file uploads. Although many GraphQL libraries include
some form of file uploading capability, I'd suggest against using that and
just creating separate endpoints for each upload type. Having a separate
endpoint makes it way easier to place reasonable limits on input size, as well
as rate-limiting those actions adequately. You can also handle streaming
uploads, which I don't think most GraphQL libraries can handle; if I recall
correctly the Node GraphQL server parses the whole body before executing any
resolver.

[0] [https://sangria-graphql.org/](https://sangria-graphql.org/)

------
asciimo
Episode 27 of the Syntax podcast gives a good overview of GraphQL and its
ecosystem. Demystified a lot for me. [https://syntax.fm/show/027/graphql-here-
is-what-you-need-to-...](https://syntax.fm/show/027/graphql-here-is-what-you-
need-to-know)

------
danpalmer
This is a great summary of the reasons why I initially dismissed GraphQL, and
why I'm now a fan - having gone through a process of evaluating it against
REST for a production API for a mobile app.

Great post.

------
makkesk8
Has anyone used odata? Do you prefer odata over graphql?

~~~
WorldMaker
I used OData in a past life. From what I've seen GraphQL is more
capable/tunable. OData feels a bit more constrained to relational
models/particular ORMs, and GraphQL is more flexible to homogenize data from
multiple sources.

I've seen some very bad OData performance issues, and generally wouldn't
recommend its use outside of intranet/enterprise/non-public projects these
days. GraphQL seems at first glance worse, but the ability to name queries
alone provides a lot of tuning power (making profiling easier, and allowing
for the potential to performance tune individual query patterns) and most of
the good GraphQL engines provide at least some basic cost estimation systems
to quota high cost queries, whereas the cost estimation of OData operators is
trickier.

Though really a lot of it comes down to productivity needs. There's still
cases where everything is on a single SQL server and Breeze against a simple
OData endpoint on the SQL schema is, well, a breeze, for a simple client app.
But I'm growing increasingly convinced that GraphQL is better in the long run,
and I think a key need right now is much better server-side .NET GraphQL
libraries that work well with EF, and have some of the profiling and cost
estimation tools you see over in Apollo Engine and the like.

------
Justsignedup
has anyone used JSON API? How does it compare to graphql? Did you find JSON
API was better until you hit a certain size?

~~~
Vinnl
For others as confused as I was: "JSON API" is not just "an API that returns
JSON". Apparently it's a spec: [http://jsonapi.org/](http://jsonapi.org/)

~~~
wruza
Finally a graph QL that can actually return graphs. Otoh, I don’t get why it
is breaking news at all. Figuring out that in some cases you better
interchange graphs and implementing a simple json-query-walker is a task for a
day or two. You don’t need to go through The Era of REST or The Age of RPC to
do that, neither is it a stellar innovation. Where are all the hackers gone?

------
orefalo
It's pretty simple... do access the DB (assuming it's SQL) do you prefer SQL
or PLSQL.

------
ravitation
Good and bad reasons to use something are not the same thing as pros and
cons...

------
krn
Why would one choose GraphQL over gRPC for a native iOS / Android app?

~~~
masklinn
A composable and flexible RPC query format for the client and exploratory
tooling.

grpc is efficient, but it's the same rpc we've ever had with inflexible static
calls and a bunch of roundtrips to do deep querying.

~~~
viiralvx
Yeah, I will also say that you can use gRPC with GraphQL as the API Gateway:
[https://iheanyi.com/journal/2018/05/12/the-g-unit-stack-
go-g...](https://iheanyi.com/journal/2018/05/12/the-g-unit-stack-go-graphql-
and-grpc/)

Kind of gives you the benefit of both.

------
ocfx
Does anyone know how GraphQL manages (or if it even can) to sort and filter
across microservices? It seems impossible to me to do from any client. If you
have a list view that is made up of data from microservice a, b, and c and you
try to sort on a column from microservice b, how does microservice b know how
to sort then data when there are additional constraints applied to data on
other microservices such as a filter applied to microservice a. Does that make
sense?

Basically I feel very frustrated when it comes to sorting and filtering across
microservices, some people at work think that GraphQL will solve this and I
have found absolutely nothing to support the claim that it would help us with
this. Thoughts?

~~~
boromisp
Edit: I don't believe GraphQL can provide any help with this.

In cases like this you can always fall back to the naive solution: syncing the
relevant data between microservices.

Unless there is something like PostgreSQL's foreign data wrappers available.

