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

SwiftGraphQL – A GraphQL client that lets you forget about GraphQL

github.com

Post reply on HN
Print view View original

11–20 of 90 posts

Re: SwiftGraphQL – A GraphQL client that lets you forget about GraphQL

#11

Post by hardwaresofton »

Another week, another submission that hopefully edges more people towards realizing that they've just created an under-standardized, under-powered SQL-with-braackets that forces you to bring your own query optimizer, and eschews the advancements of Swagger/OpenAPI, JSONSchema, HAL, JSON-LD and the flexibility of HATEOAS.

All for a little bit of a velocity gain from declarative syntax and horizontal/vertical filtering.

This code is probably very useful to the people who made it and those in the GraphQL+Swift ecosystem, but we were already here (and just starting to get drastically better) with OpenAPI -- it's not like all the effort is only going in one direction but GraphQL really feels like a less-than-optimal branch.

The final piece of the puzzle for me will be when someone starts to replace the dynamic properties of the more advanced REST-ful techniques (API discovery, link following, etc) in GraphQL. Then the circle will be complete -- we'll have rebuilt XML (in the "linked data" respect anyway, not so much the accidental complexity side) and it's related standards twice in under ~20 years.

Re: SwiftGraphQL – A GraphQL client that lets you forget about GraphQL

#12

Post by blacktriangle »

jtdev wrote: post #3

Can we just forget about GraphQL completely instead?

I have, but I also don't work in an organization that has separate and large front-end and back-end teams. GraphQL looks less like an objectively useful technology and more of a realization of Conway's Law in response to Facebook's organization.

Re: SwiftGraphQL – A GraphQL client that lets you forget about GraphQL

#13

Post by maticzav »

andrewingram wrote: post #4

There's also: - Relay-swift: A port of Relay to Swift - https://relay-tools.github.io/Relay.swift/docs/ - Graphaello: Inspired by Relay, but deviates a bit more from the patterns than Relay-swift - https://github.com/nerdsupremacist/Graphaello

Thank you for adding the links!

The main difference between these clients and SwiftGraphQL is that SwiftGraphQL tries to abstract away GraphQL in favour of Swift language feature.

`relay-swift`, for example, relies on query strings which doesn't bring type-safety to your code;

`graphaello` is indeed very similar and I've tried using it before creating SwiftGraphQL. One of the goals of SwiftGraphQL was to let you easily separate the model from your queries. That's why we let you do complex logic in the selection itself. Otherwise, you'd have to first create a utility struct and then translate it into a model-type. I think that's the main difference between graphaello and SwiftGraphQL

Thanks again for sharing the links!

Re: SwiftGraphQL – A GraphQL client that lets you forget about GraphQL

#14

Post by RyanShook »

blacktriangle wrote: post #12
jtdev wrote: post #3

Can we just forget about GraphQL completely instead?

I have, but I also don't work in an organization that has separate and large front-end and back-end teams. GraphQL looks less like an objectively useful technology and more of a realization of Conway's Law in response to Facebook's organization.

Great point. GraphQL looks like overkill for small projects but at the right size it probably makes perfect sense.

Re: SwiftGraphQL – A GraphQL client that lets you forget about GraphQL

#16

Post by rand_r »

hardwaresofton wrote: post #11

Another week, another submission that hopefully edges more people towards realizing that they've just created an under-standardized, under-powered SQL-with-braackets that forces you to bring your own query optimizer, and eschews the advancements of Swagger/OpenAPI, JSONSchema, HAL, JSON-LD and the flexibility of HATEOAS. All for a little bit of a velocity gain from declarative syntax and horizontal/vertical filtering…

Does OpenAPI have a way for the client to whitelist fields? I see that as a major selling point for GraphQL.

Without it, you end up having to create tailored endpoints for each use-case vs. for example a single “user” endpoint/vertex that supports the complete buffet of fields for all use-cases in one convenient place.

Re: SwiftGraphQL – A GraphQL client that lets you forget about GraphQL

#17

Post by arcturus17 »

RyanShook wrote: post #14
blacktriangle wrote: post #12

Earlier quoted context omitted.

I have, but I also don't work in an organization that has separate and large front-end and back-end teams. GraphQL looks less like an objectively useful technology and more of a realization of Conway's Law in response to Facebook's organization.

Great point. GraphQL looks like overkill for small projects but at the right size it probably makes perfect sense.

"Conway's law is an adage stating that organizations design systems which mirror their own communication structure"

So if GP is correct and we take them literally then you shouldn't only have the right size, but also a structure that's close to Facebook's...

Re: SwiftGraphQL – A GraphQL client that lets you forget about GraphQL

#18

Post by mikecaulley »

hardwaresofton wrote: post #11

Another week, another submission that hopefully edges more people towards realizing that they've just created an under-standardized, under-powered SQL-with-braackets that forces you to bring your own query optimizer, and eschews the advancements of Swagger/OpenAPI, JSONSchema, HAL, JSON-LD and the flexibility of HATEOAS. All for a little bit of a velocity gain from declarative syntax and horizontal/vertical filtering…

I've found GraphQL to greatly improve the developer experience when building web apps. As a front-end developer you can easily get a full view of the data and relationships. Tools like GraphiQL make exploring APIs a pleasure. And regardless of what you need to present to the user on screen, you can quickly build a request that perfectly matches the data you need. There is also the nice addition of strict typing and there are libraries that automatically generate TypeScript types for you from the schema and/or your operations.

Re: SwiftGraphQL – A GraphQL client that lets you forget about GraphQL

#19

Post by runawaybottle »

jtdev wrote: post #3

Can we just forget about GraphQL completely instead?

Oh come on! My company just forced me to learn it for a better part of a year. We can’t be done with it, it’s not fair.

I was told this was the new hotness, and I can’t be lied to. Plus, many job descriptions were asking for Graphql about 2 years ago, so what gives? Is life not fair? I was told it was fair this time around.

Re: SwiftGraphQL – A GraphQL client that lets you forget about GraphQL

#20

Post by erikpukinskis »

hardwaresofton wrote: post #11

Another week, another submission that hopefully edges more people towards realizing that they've just created an under-standardized, under-powered SQL-with-braackets that forces you to bring your own query optimizer, and eschews the advancements of Swagger/OpenAPI, JSONSchema, HAL, JSON-LD and the flexibility of HATEOAS. All for a little bit of a velocity gain from declarative syntax and horizontal/vertical filtering…

I don’t really think of GraphQL as a data querying language like SQL.

I think of it as a domain querying language.

SQL is meant to allow you to write queries to your data model which are:

- arbitrary, and

- efficient

I don’t think of GraphQL that way. I think of it as the place where you encode your set of valid domain actions (i.e. not arbitrary). And I don’t think the consumers of the GraphQL API should think about efficiency. They should just specify what data they need and then the backend is responsible for figuring out how to query the data model efficiently.

In other words, I don’t really see any overlap between GraphQL and SQL in terms of the role they play in a stack.

One helpful thing this distinction allows, is type inference. You can trivially write a type generator that gives you the type signature of a GraphQL query in any language. This is precisely because of its limitations. That allows you to automate the validation of your frontend and backend speaking the same language.

You can’t easily infer the return types of arbitrary SQL queries. To me, that highlights the different purposes of the languages.

Post reply on HN