Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Astronomer is Betting on GraphQL

astronomer.io

Post reply on HN
Print view View original

11–20 of 38 posts

Re: Why Astronomer is Betting on GraphQL

#11

Post by martijnwalraven »

maxdo wrote: post #5

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!

Re: Why Astronomer is Betting on GraphQL

#13

Post by arvinsim »

NicoJuicy wrote: post #6

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)

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

Re: Why Astronomer is Betting on GraphQL

#15

Post by threatofrain »

chlee wrote: post #12

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.

Re: Why Astronomer is Betting on GraphQL

#16

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

Re: Why Astronomer is Betting on GraphQL

#17

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

Re: Why Astronomer is Betting on GraphQL

#18

Post by tgasson »

mosselman wrote: post #16

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 ha…

> 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

Re: Why Astronomer is Betting on GraphQL

#19

Post by chmike »

watwut wrote: post #10
NicoJuicy wrote: post #6

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)

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.

Re: Why Astronomer is Betting on GraphQL

#20

Post by maxdo »

martijnwalraven wrote: post #11
maxdo wrote: post #5

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 issu…

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.
Post reply on HN