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

21–30 of 38 posts

Re: Why Astronomer is Betting on GraphQL

#21

Post by martijnwalraven »

maxdo wrote: post #20
martijnwalraven wrote: post #11

Earlier quoted context omitted.

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

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!

Re: Why Astronomer is Betting on GraphQL

#22

Post by Cthulhu_ »

chmike wrote: post #17

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.

Re: Why Astronomer is Betting on GraphQL

#23

Post by rywalker »

nippples wrote: post #2

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.

Re: Why Astronomer is Betting on GraphQL

#24

Post by antonvs »

chmike wrote: post #19
watwut wrote: post #10

Earlier quoted context omitted.

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.

Re: Why Astronomer is Betting on GraphQL

#25

Post by watwut »

chmike wrote: post #19
watwut wrote: post #10

Earlier quoted context omitted.

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.

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

Re: Why Astronomer is Betting on GraphQL

#26

Post by djmashko2 »

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.

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.

Re: Why Astronomer is Betting on GraphQL

#27

Post by maxdo »

martijnwalraven wrote: post #21
maxdo wrote: post #20

Earlier quoted context omitted.

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

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

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

Re: Why Astronomer is Betting on GraphQL

#29

Post by omegavesko »

maxdo wrote: post #20
martijnwalraven wrote: post #11

Earlier quoted context omitted.

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

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

Re: Why Astronomer is Betting on GraphQL

#30

Post by raarts »

maxdo wrote: post #20
martijnwalraven wrote: post #11

Earlier quoted context omitted.

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

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