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

31–40 of 90 posts

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

#31

Post by jkrems »

codenesium wrote: post #24
erikpukinskis wrote: post #20

Earlier quoted context omitted.

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.

> If you can query anything [...]

The answer is simple: You can't. GraphQL _in general_ doesn't allow arbitrary queries. It allows arbitrary output field selection. But the filters are very explicit. It's more "pre-aggregation of request waterfalls and masking of outputs" than "querying a database".

Doesn't stop people from exposing their SQL databases directly from GraphQL by generating a "free-for-all" schema. And when they do - yep, that's definitely a performance bomb and not a good use of GraphQL.

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

#32

Post by criddell »

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…

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.

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

#33

Post by blacktriangle »

jaegerpicker wrote: post #25
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.

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

Objectively was probably the wrong word, maybe "generally" would be more accurate. I was looking to contrast GraphQL with something like REST which is an incredibly powerful generic mental model, where GraphQL seems more specifically tuned to solve front end developer's issues.

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

#34

Post by dmitriid »

jkrems wrote: post #31
codenesium wrote: post #24

Earlier quoted context omitted.

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.

> If you can query anything [...] The answer is simple: You can't. GraphQL _in general_ doesn't allow arbitrary queries. It allows arbitrary output field selection. But the filters are very explicit. It's more "pre-aggregation of request waterfalls and masking of outputs" than "querying a database". Doesn't stop people from exposing their SQL databases directly from GraphQL by generating a "free-for-all" schema. And…

> The answer is simple: You can't. GraphQL _in general_ doesn't allow arbitrary queries.

It really does. Surely, it somewhat limits the data that you get from it by defining a schema. But the moment you allow any nesting/connections between data in that schema, hello n+1 problem.

And then every discussion of this problem on HN or elsewhere exposes the ugly truth: almost everyone uses GraphQL as a REST endpoint in production by limiting the actual queries you can run and curbing nesting.

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

#35

Post by dmitriid »

mikecaulley wrote: post #29
kristaps wrote: post #23

Earlier quoted context omitted.

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.

It is more difficult. With REST you know ahead of time which data you need, and you can optimise it as much as you can. With GraphQL at any given point in time you have no idea what the request is. Dataloaders solve it to some extent, but not much.

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

#37

Post by erikpukinskis »

codenesium wrote: post #24
erikpukinskis wrote: post #20

Earlier quoted context omitted.

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.

I never fully solved this problem, so don’t trust me, but I can tell you what I learned...

I think for one thing you can’t really rely on joins for query efficiency, because as you say there are too many combinations so it’s impossible to optimize everything.

Instead you have to try to query each data type separately. So you get a query for users. You do an SQL call and gather up a bunch of requests for offices, and then you do a single request to your office backend.

I think the best case is something like n SQL queries per request, where n is the depth of the tree you are querying (users->office->address is depth 3).

That means you’re doing all your queries after the first one by ID (not by arbitrary columns). So you have to have some way to “pre-join” your tables. You can do this either by optimistically joining your data to everything around it (query the node plus all of its edges) or you need to store your edges in your data model (which I have to assume is what FB does).

In the end your resolvers need to be using some standardized way of grabbing objects by is (or edge), something like https://github.com/graphql/dataloader

Whether it’s possible to do this efficiently I don’t know. At my last job we messed it up, and then we started applying a strategy like I described above, but then I switched jobs.

Would love to hear from others who have dealt with the same challenges.

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

#38

Post by santialbo »

humbleMouse wrote: post #26
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 imp…

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

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

#39

Post by dmitriid »

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 one place where I've found GraphQL to be potentially useful is back office. This is usually the place where you need a lot of very different data in one place, and in ways that are completely different from customer-facing apps or sites. And back office usually doesn't get as much love.

So usually you have backoffice devs scrambling to retrieve data in weird ways from existing APIs. And things like "does this inventory item come from a provider with an active contract, and who else is on that contract" become ... weird and unwieldy. This is where GraphQL with it's ad-hoc queries definitely helps. And since the volume of queries in back office is low, you don't worry too much about the performance of some of the queries.

I wouldn't use it for anything else though.

Anecdata:

Just last month it took me about half an hour to implement an "omni search" functionality in GraphQL that takes string as input, coalesces results from three different backend APIs and return back a nice view to fuzzy-ish search for three different entities in our backend. Frontend couldn't be happier.

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

#40

Post by pcr910303 »

So a bunch of people on HN are now arguing that GraphQL should disappear?

GraphQL is a genuinely objectively useful technology in places that have a frontend-backend split (including non-web frontends). It doesn’t require building specific APIs for specific pages for speed concerns. It allows backends to add fields non-destructively (RESTful JSON does work at the cost of a bigger network payload).

GraphQL provides the right tools for the right problem, and has created an ecosystem around it. (How should I reliably compute a SQL query cost? How should I control data access policy in SQL? How should I return the SQL result in a easily-parsable format?)

Post reply on HN