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

51–60 of 90 posts

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

#51

Post by humbleMouse »

santialbo wrote: post #38
humbleMouse wrote: post #26

Earlier quoted context omitted.

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

GraphQL was released as an specification with a node example implementation. It wasn't "written for server side javascript".

Ok, so it was software released with it’s first implementation written in node.

And now have “Apollo”, which is a server that runs inside a v8 engine(node).

It seems to me that the javascript crowd are the ones pushing this forward and seems to me that it was written with javascript as a first class citizen.

Hard pass

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

#52

Post by hardwaresofton »

Lx1oG-AWb6h_ZG0 wrote: post #47
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…

The main advantage I’ve found with GraphQL is the normalized cache in client libraries like Apollo or Relay. It allows components to just ask for the data and not worry about how it’s fetched/stored/updated. The secondary benefit is that _some_ (not all) of the data plumbing can be moved from the frontend code to the backend, which makes for faster apps. Beyond that, GraphQL is more of a hinderance than a help... its…

> The main advantage I’ve found with GraphQL is the normalized cache in client libraries like Apollo or Relay. It allows components to just ask for the data and not worry about how it’s fetched/stored/updated. The secondary benefit is that _some_ (not all) of the data plumbing can be moved from the frontend code to the backend, which makes for faster apps.

Is this something you couldn't achieve with the idiomatic rules on HTTP request types, and serialization of HTTP requests parameters? It really depends on where you're trying to do the caching and what kind of caching you're trying to do.

A lot of work has gone into HTTP headers, method semantics, and other details in order to facilitate caching. The "backend for frontend" pattern has been very popular as of late in order to try and shift the plumbing load, exposing endpoints that are catered to certain clients to boost efficiency -- would that be good enough for a corollary in OpenAPI land?

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

#53

Post by hardwaresofton »

rand_r wrote: post #16
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.

I can't say that it should have that feature -- I'd say that is outside the purview of OpenAPI itself, but it could definitely be built in in a repeatable and scalable way pretty simply. I can tell you that tools like PostgREST have had this for a long time[0].

[0]: https://postgrest.org/en/v7.0.0/api.html#vertical-filtering-...

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

#54

Post by serverholic »

santialbo wrote: post #42

I see a lot of hatred in the comments towards GraphQL. Is someone forcing you to use it against your will? I've been using it for more than a year with TypeScript types generation and couldn't be happier. All of my interactions with the server are properly typed and haven't had a single bug related to server/client missmatches.

There are a bunch of elitists on here who get off on hating popular things.

I find it amusing that some of the comments are basically "Why use graphql when I can combine these 5 other technologies to do the same thing?"

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

#55

Post by hardwaresofton »

erikpukinskis wrote: post #28
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.

AFAIK there is not a standardized way to do this but there's no reason it can't -- you are free to define your own Content-Type or use framed binary, or whatever else. If you already have schemas on either side (or code to do dynamic discovery), and a way to pack/unpack you can send different kinds of data across.

This is less ideal than GraphQL in this case, since GraphQL has done this hard work and standardized it/created the conforming reference clients/servers already.

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

#56

Post by shoelessone »

hardwaresofton wrote: post #50
criddell wrote: post #32

Earlier quoted context omitted.

To what extent are you just pushing complexity to the back-end developers? > Tools like GraphiQL make exploring APIs a pleasure. No argument there. Is there something similar for traditional REST? For some reason, I thought the point of HATEOS was to make that kind of exploration possible.

GraphQL cannot ever be explored in the same way HATEOAS can because it is missing the linking part (and other related technology like JSON-LD). That said, GraphQL does offer introspection[0] which is not a bad start but lacks the breadth an depth of the hyperlink based approaches. [0]: https://graphql.org/learn/introspection/

I 100% agree with your statement. I also realize you are not championing HATEOAS here necessarily.

That said, I am curious if you have found this "linking" aspect of HATEOAS useful for actual implementations? I have been doing integration work with a system that strictly adheres to "REST level 3" and "HATEOAS" principles for the past few years, and I myself have found the "explore-ability" of the API super handy. That said, the self-documenting nature only goes so far, and in the end I'm not sure the internal linking stuff is preferable to robust documentation.

I'm not trying to be down on this necessarily, I actually generally push back on the adoption of GraphQL as the answer to every problem.

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

#57

Post by serverholic »

hardwaresofton wrote: post #48
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 do agree that GraphQL has improved developer experience, or at the very least improved the perceived experience (which is essentially the same as actually improving the experience). I cannot deny it's popularity, and that comes from hype along with usefulness (perceived or actual). > Tools like GraphiQL make exploring APIs a pleasure. This is an innovation of the developers of GraphiQL, not of GraphQL itself. It's…

I don't want to piece together 4 different technologies to get the same thing.

And it's not even the same thing. You keep mentioning HATEOAS but that doesn't accomplish the same things as graphql at all. With HATEOAS I need to send out multiple requests to collect the data I need. With graphql I can send out one request to retrieve exactly the data I need. I can also combine multiple requests into a single request. GraphQL also only retrieves the fields you need by default. This is something you'd need to build manually with REST.

And yes, reducing the number of server requests does matter when you're trying to optimize for the largest market possible. Including people on slow mobile network connections where every request adds significant overhead.

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

#58

Post by krschultz »

hardwaresofton wrote: post #52
Lx1oG-AWb6h_ZG0 wrote: post #47

Earlier quoted context omitted.

The main advantage I’ve found with GraphQL is the normalized cache in client libraries like Apollo or Relay. It allows components to just ask for the data and not worry about how it’s fetched/stored/updated. The secondary benefit is that _some_ (not all) of the data plumbing can be moved from the frontend code to the backend, which makes for faster apps. Beyond that, GraphQL is more of a hinderance than a help... its…

> The main advantage I’ve found with GraphQL is the normalized cache in client libraries like Apollo or Relay. It allows components to just ask for the data and not worry about how it’s fetched/stored/updated. The secondary benefit is that _some_ (not all) of the data plumbing can be moved from the frontend code to the backend, which makes for faster apps. Is this something you couldn't achieve with the idiomatic rul…

The backend for frontend pattern is exactly why I got sold on GraphQL. We had a pile of relatively low value server code that could be replaced a GraphQL resolver and the client got all of the advantages of that pattern. The move to GraphQL genuinely freed up a lot of our time to work on more important problems. This was on a smallish team so that time mattered.

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

#59

Post by monadic5 »

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…

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

Why the insistence on condescending towards people who make decisions you don't understand? It's one of HN's less attractive aspects.

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

#60

Post by hardwaresofton »

serverholic wrote: post #57
hardwaresofton wrote: post #48

Earlier quoted context omitted.

I do agree that GraphQL has improved developer experience, or at the very least improved the perceived experience (which is essentially the same as actually improving the experience). I cannot deny it's popularity, and that comes from hype along with usefulness (perceived or actual). > Tools like GraphiQL make exploring APIs a pleasure. This is an innovation of the developers of GraphiQL, not of GraphQL itself. It's…

I don't want to piece together 4 different technologies to get the same thing. And it's not even the same thing. You keep mentioning HATEOAS but that doesn't accomplish the same things as graphql at all. With HATEOAS I need to send out multiple requests to collect the data I need. With graphql I can send out one request to retrieve exactly the data I need. I can also combine multiple requests into a single request. G…

> I don't want to piece together 4 different technologies to get the same thing.

> And it's not even the same thing. You keep mentioning HATEOAS but that doesn't accomplish the same things as graphql at all. With HATEOAS I need to send out multiple requests to collect the data I need. With graphql I can send out one request to retrieve exactly the data I need. I can also combine multiple requests into a single request. GraphQL also only retrieves the fields you need by default. This is something you'd need to build manually with REST.

All of this is reasonable, but my point was that we've abandoned a more flexible method, that had composable functionality and agreed-upon standards for GraphQL. You gained some pipelining, and some vertical filtering, but threw out a lot with the bathwater.

GraphQL does give you a way to do these things, and this is why it is popular (or at least a good reason why), but it is missing the wider possibilities of the other ecosystem. As people start to try and abstract over it they will be abstracting over a less robust, considered, standardized base.

> And yes, reducing the number of server requests does matter when you're trying to optimize for the largest market possible. Including people on slow mobile network connections where every request adds significant overhead.

Reducing the number of server requests does indeed matter -- I did not mean to propose it doesn't, reducing request was somewhat solved before now with the backend-for-frontend approach. There are lots of approaches to help people on slow mobile network connections, but the ultimate one is to server-render and trim as much as possible -- I'm not sure GraphQL is much better at this than REST with efficient endpoint choice.

Post reply on HN