Why Astronomer is Betting on GraphQL | Hacker News Reader

Why Astronomer is Betting on GraphQL

astronomer.io

70 pointsbrunklb37 comments

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...

They are working to resolve 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.

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.

> 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

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.

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.

That could be true, but field would not be enough, at least in my limited understanding. I can imagine that I'd also want to know which information is retrieved through other pieces of information. So lets say `Post -> Comments -> Author -> Avatar`, rather than just `Avatar`. This is important because it shows that whatever I do I should at least support the relation to `Avatar` through `Post -> Comments -> Author`.

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

Add a new GraphQL version endpoint?

In an ideal world API versions would spawn feature-complete from version to version and older versions would require 0% maintenance, yes, but this is not how the world works.

As I said, it could work this way for Github, but not your relatively small SaaS. My point was that investing in these kinds of things might not be for everyone.

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.

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!

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.

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!

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

>Unfortunately your architecture limits us to JS style of development when failed request is ok, user will refresh the page.

On what planet is this "the JS style of development"? SPAs don't want to force the user to refresh the page for no good reason for the exact same reason that you don't want the user to close your app because their token has expired. The idea really isn't significantly different.

I don't understand the problem, why can't parallel graphQL queries be resent individually when the token is denied?

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.

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.

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.

This side-steps the legal question, but GraphQL is ultimately an idea on API design, and less about the corresponding libraries, such as the ones by Apollo or Facebook.

Of course the libraries are important too, but even if Facebook specifically strangled GraphQL to death, the idea of simple declarative HTTP API is too valuable to let it die on the vine.

In parallel, even if Facebook decided to strangle their React user base with patent trolling, and everyone decided to ditch React, the idea of a declarative DOM library or unidirectional flow is too good to let it die with React. And so we see it in Vue, Angular, and Preact or Inferno.

Hype may be related to many factors, one of which is mere library or ecosystem polish, often propelled by a big company with labor to spare, but I think the benefits behind a declarative HTTP API are real.

Here's a page we put together with case studies of companies using GraphQL in production: 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.

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

FQL is completely different from GraphQL.

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.

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

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

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).

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.

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...

[1]: https://github.com/apollographql/apollo-server/blob/master/p...

[2]: https://github.com/apollographql/apollo-client/blob/master/p...

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)

GraphQL isn't really comparable to Postgres. It is more of an alternative to using a REST api.

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

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.

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.

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".

Sure. And you would also had much less control over access rights and such. You would have to implement everything in the database itself.

What has GraphQL, an alternative to REST got to do with Postgres, a database?

Reply on news.ycombinator.com