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

21–30 of 90 posts

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

#21

Post by jamil7 »

mikecaulley wrote: post #18
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 t…

I don't have especially strong feelings either way, but the majority of this is possible with OpenAPI as well.

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

#22

Post by jkcxn »

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…

> replace the dynamic properties of the more advanced REST-ful techniques (API discovery, link following, etc) in GraphQL

Isn't this exactly what GraphQL does? I may be missing something

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

#23

Post by kristaps »

mikecaulley wrote: post #18
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 t…

I would like a backend developer perspective on the same.

I haven't done any GraphQL stuff myself, but the "I can get whatever data I need" aspect feels like a huge potential headache for backend devs. Won't be a problem at prototype scale, but once you have a significant client count, how do you deal with unpredictable data access patterns that can't be optimized ahead of time?

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

#24

Post by codenesium »

erikpukinskis wrote: post #20
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…

When your backend is sql how can you even do this efficiently? Databases require indexes. If you can query anything then there are performance bombs all over the place. It's different if you're querying elastic I guess.

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

#25

Post by jaegerpicker »

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.

As a Mobile Dev/Frontend Dev GraphQL is a massive win to work with. No more requesting/building end points to satisfy the screen you are building. Adding fields is non-destructive. Controlling the shape of the data returned (to an extent, you still have to return it in the nested layers the schema is designed towards). I know a ton of backend or full stack devs that don't think that GraphQL is worth it but very FEW UI devs that agree. It's really nice to build UI's against. I've tried SOAP, REST, HATEOAS, Swagger/OpenAPI, and protobuffers. Protobuffers are the only one with as good a developer experience IMO. GraphQL is OBJECTIVELY useful it might not be useful to you apps though and that's ok.

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

#26

Post by humbleMouse »

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…

100% agree. People also need to remember that GraphQL was originally written for server side javascript, and now it’s being ported to other languages(for what reason???).

You can create your own global json schema and build a ratchet version of GraphQL using proven orms in about 20 minutes using an unpersisted “filtering” field.

If you want automatic access to your data, bite the bullet and do something cool like implement Apache Dremio.

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

#27

Post by ericlewis »

maticzav wrote: post #13
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 easi…

Relay.swift doesn't bring type-safety to your queries but it does use the relay-compiler which will fail if anything is wrong (at least helpful!) and you still get type safety for results as well as automatic conformance to Identifiable & custom scalar type substitutions.

Haven't checked out SwiftGraphQL much, but Relay.swift is definitely the best swift based GQL I have used to date.

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

#28

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…

Does OpenAPI support multiple kinds of data in a single HTTP request? I couldn’t find anything about that in the docs.

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

#29

Post by mikecaulley »

kristaps wrote: post #23
mikecaulley wrote: post #18

Earlier quoted context omitted.

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

I would like a backend developer perspective on the same. I haven't done any GraphQL stuff myself, but the "I can get whatever data I need" aspect feels like a huge potential headache for backend devs. Won't be a problem at prototype scale, but once you have a significant client count, how do you deal with unpredictable data access patterns that can't be optimized ahead of time?

Generally speaking, it's not more difficult than creating a REST API controller. Rather than mapping your service code to a controller, you map it to a (GraphQL) resolver. It feels extremely similar.

There are different things to look out for; like handling n+1 (https://shopify.engineering/solving-the-n-1-problem-for-grap...) queries, but nothing that I can say is too difficult.

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

#30

Post by no_wizard »

kristaps wrote: post #23
mikecaulley wrote: post #18

Earlier quoted context omitted.

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

I would like a backend developer perspective on the same. I haven't done any GraphQL stuff myself, but the "I can get whatever data I need" aspect feels like a huge potential headache for backend devs. Won't be a problem at prototype scale, but once you have a significant client count, how do you deal with unpredictable data access patterns that can't be optimized ahead of time?

Inevitably you do get a map of your data flow. GraphQL can be a huge help here, because you must have resolvers for the queries. It forces you to think ahead of time about how you're going to resolve getting the data to fulfill the API "contract" if you will. You can optimize that. GraphQL is great for describing your APIs in a type safe(ish) way where you get great decoupling by design.

I also will say that since a query can use multiple resolvers, that's where I have found it really shines. The model does implicitly work best when you have async systems over synchronous ones for more complex queries (multithreaded/multiprocess)

that's my anecdote, as someone who is currently and actively building and maintaining GraphQL backend services.

Its true you can get the same with any API design pattern, really, I will say, however GraphQL has specifications for all this, and I think that's what makes it more powerful

Another nice thing, is no versioning. I can just use the `@deprecated` built in directive, and when the usage of a deprecated part of an API gets consistently (for a specified period of time) down to 0, I can just remove it entirely.

OpenAPI and the like don't have a descriptive way to notify users of an API of this, you, for better or worse, have to version your API, which often ends up in situations where you always have an old version sticking around for a very long time.

Like all technologies though, it can (and does) have its issues. It adds a certain amount of complexity to your applications (more so for the client, IMO, even though exploring APIs is a huge upside with tools like GraphiQL)

Post reply on HN