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

81–90 of 90 posts

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

#81

Post by RussianCow »

dmitriid wrote: post #78
andrewingram wrote: post #45

Earlier quoted context omitted.

The n+1 problem has solutions though. The most well-known solutions may not suit your architecture, but please can we stop pretending they don't exist? GraphQL has been public since June 2015, and there's been at least one solution to the n+1 problem (Dataloader) since September 2015. If you were using pure REST endpoints (just resources, no nesting/traversal) this is the exact problem you'd be punting over to the cl…

> The n+1 problem has solutions though. It does. But it also means that the problem exists . It's there, you run into it by default , and you have to take special care to make sure it doesn't happen. And data-loaders are just a first step. Some systems try to actually calculate query complexities and nesting depth. > this is the exact problem you'd be punting over to the client to solve -- all that GraphQL is doing h…

> It does. But it also means that the problem exists.

The exact same problem exists on the client side with REST. I get what you're saying, but it's a lot easier to fix N+1 issues at the GraphQL resolver level, because once you've fixed it, you don't have to touch it again. With REST, you end up either creating ad hoc endpoints or changes to solve each individual problem in isolation, or you end up building a lot more flexibility into your REST API to solve it in a general way, in which case you've badly reinvented GraphQL without benefiting from the existing ecosystem.

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

#82

Post by ehutch79 »

serverholic wrote: post #54
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?"

It's not graphql that's the issue. it's another tool.

It's the fanboys, and more the people selling tooling. There's a guy who (was?) over at graphqleditor.com that was posting a whole bunch of articles, at least one of one said it was a mistake not to convert all your shit to graphql immediately.

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

#83

Post by andrewingram »

RussianCow wrote: post #81
dmitriid wrote: post #78

Earlier quoted context omitted.

> The n+1 problem has solutions though. It does. But it also means that the problem exists . It's there, you run into it by default , and you have to take special care to make sure it doesn't happen. And data-loaders are just a first step. Some systems try to actually calculate query complexities and nesting depth. > this is the exact problem you'd be punting over to the client to solve -- all that GraphQL is doing h…

> It does. But it also means that the problem exists . The exact same problem exists on the client side with REST. I get what you're saying, but it's a lot easier to fix N+1 issues at the GraphQL resolver level, because once you've fixed it, you don't have to touch it again. With REST, you end up either creating ad hoc endpoints or changes to solve each individual problem in isolation, or you end up building a lot mo…

Right. Regardless of how you go about doing things, if a UI is going to compose more than one kind of resource (which in reality is pretty much every UI), there's going to be some kind of n+1 problem hidden in there somewhere -- unless you go down the route of building a bespoke endpoint per screen or operation, which isn't the worst thing in the world, but it's not the work I want to spend my time doing when building products.

What GraphQL essentially gives you is a mechanism for providing a specification and getting back an endpoint, either fully dynamically at runtime, or at build-time if using persisted queries.

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

#84

Post by andrewingram »

dmitriid wrote: post #78
andrewingram wrote: post #45

Earlier quoted context omitted.

The n+1 problem has solutions though. The most well-known solutions may not suit your architecture, but please can we stop pretending they don't exist? GraphQL has been public since June 2015, and there's been at least one solution to the n+1 problem (Dataloader) since September 2015. If you were using pure REST endpoints (just resources, no nesting/traversal) this is the exact problem you'd be punting over to the cl…

> The n+1 problem has solutions though. It does. But it also means that the problem exists . It's there, you run into it by default , and you have to take special care to make sure it doesn't happen. And data-loaders are just a first step. Some systems try to actually calculate query complexities and nesting depth. > this is the exact problem you'd be punting over to the client to solve -- all that GraphQL is doing h…

The complexity goes to where the round-trips are shorter, and where the benefits can be shared between all clients regards of language; how is this not a good thing?

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

#85

Post by hardwaresofton »

RussianCow wrote: post #77
hardwaresofton wrote: post #68

Earlier quoted context omitted.

> Part of the value is in standardization. Yes, you can get most of the benefits of GraphQL by creating your own layer over REST, but then you've just written a badly specified, bug-ridden version of GraphQL. The latter has enough momentum that there now exist tons of tools for working with it, which obviously wouldn't be true for anything you build yourself. Right, and you could have done this standardization somewh…

> Right, and you could have done this standardization somewhere else right -- GraphQL is a NIH version of what could have existed on top of well-considered existing standards. Maybe, but I think building GraphQL on top of REST would have produced something much more convoluted and verbose. As an example, see the OData standard[0], which, at least from the client's perspective, is unnecessarily complex compared to Gra…

> Maybe, but I think building GraphQL on top of REST would have produced something much more convoluted and verbose. As an example, see the OData standard[0], which, at least from the client's perspective, is unnecessarily complex compared to GraphQL. There may be cleaner ways to structure this, but I'm not aware of any such attempts, and I doubt you'd get a result as easy to use and understand as GraphQL.

I'd never heard of OData, thank you very much for the link! I've been meaning to give it a shot (try to put together a GraphQL using the other REST tools/standards), if I do I will definitely post it to HN. I agree that it would likely look more complex in the naive case but that could be ironed out -- the foundations feel identical. GraphQL's productivity and ergonomics are definitely something to strive for on the REST side.

> That's fair, but as you pointed out earlier, you're just shifting complexity around in any case. REST is simple because it's so granular, which is great when all of your data needs are met by that granularity. As soon as you have more complex data requirements, you end up either making ad hoc endpoints or evolving your API into a giant monstrosity so that you can handle the more general cases. GraphQL significantly simplifies this implementation on both the client side and the API side. Yes, the tradeoff is that now you need to optimize your data access manually, but as others have said, there are now tools for dealing with this issue—and it's not like you don't gain anything from it.

True -- growth of REST API endpoints is somewhat unbounded and it gets harder and harder to differentiate/name endpoints and separate functionality in a satisfying way. There was another comment[0] that showed the gains that a small team got from GraphQL, I can't argue with that. It does work extremely well for some teams.

> For a simple but concrete example, if I need to fetch data from ten different entity types in order to render a page in my web app, I can do so in a single GraphQL query and handle caching, etc in one pass, as opposed to needing ten different REST calls and having to consolidate them by hand. On top of the maintainability benefits of this approach, the productivity gains are huge.

This has been an oft-cited benefit of GraphQL, and it looks like a legitimate clear benefit -- not having to think about that is indeed very nice.

[EDIT] - Yeah after poking around OData for a bit, I don't think I'll be touching that but it's nice to know it exists.

[0]: https://news.ycombinator.com/item?id=26226642

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

#86

Post by hardwaresofton »

serverholic wrote: post #67
hardwaresofton wrote: post #60

Earlier quoted context omitted.

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

> You gained some pipelining, and some vertical filtering, but threw out a lot with the bathwater. What are we missing that actually matters in practice? And yes, if you minimize the problems that graphql was built to solve it seems like a worse solution. > As people start to try and abstract over it they will be abstracting over a less robust, considered, standardized base. Facebook, a company who's apps serve billi…

> What are we missing that actually matters in practice? And yes, if you minimize the problems that graphql was built to solve it seems like a worse solution. > Again, what problems are you talking about that graphql doesn't solve? I mean actual, practical problems.

If you're using GraphQL and feel that it solves all your problems and isn't painting you into a corner, you are free to continue to use it and reap the efficiency rewards. I'm not here to convert you to REST or any other RPC methodology. One of the things that was lost with adopting GraphQL is partial responses -- being able to send part of the answer back before the entire request is complete. I'm not sure exactly what streaming looks like in GraphQL but do they have anything as simple and useful as SSE?

> Facebook, a company who's apps serve billions of people came up with graphql to solve real problems. Saying it isn't well considered is asinine. As for standardization, last time I checked GraphQL has a spec and the GraphQL Foundation is a member of the Linux Foundation.

I did not mean to imply that GraphQL was not considered -- just that it is less considered than the alternatives that existed, and certainly was less battle tested. Just because something has a spec does not mean the spec is good and well reviewed (though again, I'm sure GraphQL's has been looked at by smart people for large periods of time). I don't know what to make of the GraphQL Foundation being a member of the Linux Foundation,

> So now I need to write a backend for each use-case. That sounds better. Or I need to make my endpoints extra configurable which starts to approach graphql territory.

It's not that writing robust endpoints is approaching GraphQL territory, it's that GraphQL territory is bootstrapping robust endpoints for you, but it also locks you in to it's way of viewing the world. I prefer to use interoperable smaller tools rather than doing this, and maybe I'm losing out because of that, but I'd take the complexity of one or two or five robust endpoints over adoption of the entire GraphQL spec & ecosystem for what I'd consider minimal gain. To each their own.

> Again, we're now entering the "why graphql was invented" territory. Sure I could add these to my REST endpoints.. OR I could write one graphql endpoint and get all of these.

No, that was me pointing out that if you're trying to help low bandwidth clients, that's how you definitively do it, GraphQL is not the right solution in that case -- you try your best not to make any calls on the frontend at all, so it seems the point is moot there.

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

#87

Post by RussianCow »

hardwaresofton wrote: post #85
RussianCow wrote: post #77

Earlier quoted context omitted.

> Right, and you could have done this standardization somewhere else right -- GraphQL is a NIH version of what could have existed on top of well-considered existing standards. Maybe, but I think building GraphQL on top of REST would have produced something much more convoluted and verbose. As an example, see the OData standard[0], which, at least from the client's perspective, is unnecessarily complex compared to Gra…

> Maybe, but I think building GraphQL on top of REST would have produced something much more convoluted and verbose. As an example, see the OData standard[0], which, at least from the client's perspective, is unnecessarily complex compared to GraphQL. There may be cleaner ways to structure this, but I'm not aware of any such attempts, and I doubt you'd get a result as easy to use and understand as GraphQL. I'd never…

> I've been meaning to give it a shot (try to put together a GraphQL using the other REST tools/standards), if I do I will definitely post it to HN.

Please do! I'd love to see what you come up with.

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

#88

Post by krschultz »

hardwaresofton wrote: post #65
krschultz wrote: post #58

Earlier quoted context omitted.

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.

It looks like you've picked the right tool for the job in that case, and I can't argue with that -- but the submission is for tooling that people have created in Swift for a problem that was already relatively solved by OpenAPI bindings for Swift. Would you mind going into what that low value server code was doing? Was it simply aggregating results of multiple requests? It's quite possible it wasn't that hard to solv…

FWIW this was ~2015ish, I'm not sure what the state of OpenAPI was at the time.

> Was it simply aggregating results of multiple requests?

Pretty much. The company I was at was an early proponent of microservices so we had to have a service that operated as our entry point to all of it. Thats easy enough, but layering on versioning of the APIs for native apps on different platforms added complexity that definitely didn't seem worth dealing with in our at the time REST paradigm. We did have frameworks that generated clients for different platforms against that API so I'm not even talking about the boilerplate of sending and parsing JSON.

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

#89

Post by hardwaresofton »

krschultz wrote: post #88
hardwaresofton wrote: post #65

Earlier quoted context omitted.

It looks like you've picked the right tool for the job in that case, and I can't argue with that -- but the submission is for tooling that people have created in Swift for a problem that was already relatively solved by OpenAPI bindings for Swift. Would you mind going into what that low value server code was doing? Was it simply aggregating results of multiple requests? It's quite possible it wasn't that hard to solv…

FWIW this was ~2015ish, I'm not sure what the state of OpenAPI was at the time. > Was it simply aggregating results of multiple requests? Pretty much. The company I was at was an early proponent of microservices so we had to have a service that operated as our entry point to all of it. Thats easy enough, but layering on versioning of the APIs for native apps on different platforms added complexity that definitely did…

Cool thanks for sharing this -- it's come up multiple times in this thread and it seems I didn't weigh this point enough.

Maybe this is enough to really make GraphQL or a similar system worth it -- GraphQL and Falcor both existing as similar but separate technologies probably says something about just how problematic non-GrapQL-like patterns are at scale, and if your had a good experience at smaller scale as well then it's worth reconsidering.

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

#90

Post by dmitriid »

RussianCow wrote: post #81
dmitriid wrote: post #78

Earlier quoted context omitted.

> The n+1 problem has solutions though. It does. But it also means that the problem exists . It's there, you run into it by default , and you have to take special care to make sure it doesn't happen. And data-loaders are just a first step. Some systems try to actually calculate query complexities and nesting depth. > this is the exact problem you'd be punting over to the client to solve -- all that GraphQL is doing h…

> It does. But it also means that the problem exists . The exact same problem exists on the client side with REST. I get what you're saying, but it's a lot easier to fix N+1 issues at the GraphQL resolver level, because once you've fixed it, you don't have to touch it again. With REST, you end up either creating ad hoc endpoints or changes to solve each individual problem in isolation, or you end up building a lot mo…

> but it's a lot easier to fix N+1 issues at the GraphQL resolver level,

It definitely isn't. And, once again, dataloaders are just the first step.

> With REST, you end up either creating ad hoc endpoints or changes to solve each individual problem in isolation, or you end up building a lot more flexibility into your REST API to solve it in a general way

Even with a "general way" your REST endpoint knows what actual request or a type of request it's solving. So, instead of doing several requests to the database where each request is essentially "SELECT *", you'll be doing queries optimised for the specific request type.

And there are many-many other things. Like caching. For which Apollo has to unpack and look into every single request and response, for example (and libraries in other languages don't solve at all).

Post reply on HN