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

GraphQL Query Generator

blog.graphqleditor.com

Post reply on HN
Print view View original

11–20 of 49 posts

Re: GraphQL Query Generator

#11

Post by CodesInChaos »

blahbhthrow3748 wrote: post #3

We're looking at adopting GraphQL and for writing a CRUD app it seems insane. Being able to project out individual fields seems like a niche benefit for bandwidth constrained devices. Instead of doing joins in an RDBMS you write a dataloader which merges select queries. The queries themselves seem like a lot of repetition in the client codebase, plus the complexity of the server-side implementation. Am I alone in thi…

I think it's mainly useful in a (complex) public API.

I haven't actually used it yet, but am considering it, despite the complexity it introduces, since it promises to improve some of our pain points:

1. The client requesting specific fields enables the provider to track which fields are used. This enables fine grained deprecation notices. In my experience I rarely want to replace complete endpoints, but it often turns out that specific fields are either badly named, or don't really make sense anymore.

2. The ability to get data about related objects simplifies the client, but increases complexity on the server. Since there are many different clients (in our case every customer writes their own integration), this is often a worthwhile trade-off. For example when getting an order, the same API call could return needed product or customer data.

For internal APIs with moderate team sizes, I'd define endpoints specifically for each consumer, instead of REST or GraphQL.

Re: GraphQL Query Generator

#12

Post by Areibman »

blahbhthrow3748 wrote: post #3

We're looking at adopting GraphQL and for writing a CRUD app it seems insane. Being able to project out individual fields seems like a niche benefit for bandwidth constrained devices. Instead of doing joins in an RDBMS you write a dataloader which merges select queries. The queries themselves seem like a lot of repetition in the client codebase, plus the complexity of the server-side implementation. Am I alone in thi…

It totally depends on your use case. Indeed, the best perk, as you've pointed out, is the ability to reduce the quantity of data that runs over the wire. If well-configured, then GQL certainly makes network usage heavy mobile apps much faster. This was the main impetus behind why Facebook decided to build it.

If you're willing to add massive technical overhead to solve this, then GraphQL may be worth a shot.

Re: GraphQL Query Generator

#13

Post by typingmonkey »

blahbhthrow3748 wrote: post #3

We're looking at adopting GraphQL and for writing a CRUD app it seems insane. Being able to project out individual fields seems like a niche benefit for bandwidth constrained devices. Instead of doing joins in an RDBMS you write a dataloader which merges select queries. The queries themselves seem like a lot of repetition in the client codebase, plus the complexity of the server-side implementation. Am I alone in thi…

I recommend to watch the documentation about the facebook people that invented GraphQL [1]. Listen careful to which problems they solved with graphql, then think about the problems you have to solve for your application. Most of the time GraphQL is not worth its tradeoffs.

[1] https://www.youtube.com/watch?v=783ccP__No8

Re: GraphQL Query Generator

#14

Post by philliphaydon »

Areibman wrote: post #12
blahbhthrow3748 wrote: post #3

We're looking at adopting GraphQL and for writing a CRUD app it seems insane. Being able to project out individual fields seems like a niche benefit for bandwidth constrained devices. Instead of doing joins in an RDBMS you write a dataloader which merges select queries. The queries themselves seem like a lot of repetition in the client codebase, plus the complexity of the server-side implementation. Am I alone in thi…

It totally depends on your use case. Indeed, the best perk, as you've pointed out, is the ability to reduce the quantity of data that runs over the wire. If well-configured, then GQL certainly makes network usage heavy mobile apps much faster. This was the main impetus behind why Facebook decided to build it. If you're willing to add massive technical overhead to solve this, then GraphQL may be worth a shot.

But if you’re the only consumer of the api then it doesn’t help reduce data, unless your UI is configured to show different amounts of data.

It also doesn’t make network requests faster. I would argue it’s slower when returning the same data between a rest api and graphql. The difference is you don’t do unnecessary joins when you don’t need data. (Since most graphql apis are in front of a relational database anyway)

Re: GraphQL Query Generator

#15

Post by akrymski »

blahbhthrow3748 wrote: post #3

We're looking at adopting GraphQL and for writing a CRUD app it seems insane. Being able to project out individual fields seems like a niche benefit for bandwidth constrained devices. Instead of doing joins in an RDBMS you write a dataloader which merges select queries. The queries themselves seem like a lot of repetition in the client codebase, plus the complexity of the server-side implementation. Am I alone in thi…

The benefit of selecting specific fields is easily achieved in REST, see how PostgREST does it for an example of passing a select parameter listing the fields to include or exclude.

The negative side effects of selecting specific fields include limited caching - in most cases it makes sense to return full records from the server for further filtering in the client, with the added benefit of free caching for GET requests provided by the browser. I find that gzipping JSON works so well in practice that it's rarely worth selecting specific fields. Using a binary protocol as an alternative to JSON would be more advantageous imho.

Re: GraphQL Query Generator

#16

Post by sawaruna »

I'm working on a project right now that's applying RDF metadata schemas to some pop culture data, and while it's not GraphQL, the idea of random queries being generated is really interesting. Our output is aimed as researchers in certain domains, and while we have researchers onboard developing use-cases, the idea that some new ones could be imagined by viewing randomized queries sounds possible.

Re: GraphQL Query Generator

#17

Post by staticassertion »

DigitalSea wrote: post #6
blahbhthrow3748 wrote: post #3

We're looking at adopting GraphQL and for writing a CRUD app it seems insane. Being able to project out individual fields seems like a niche benefit for bandwidth constrained devices. Instead of doing joins in an RDBMS you write a dataloader which merges select queries. The queries themselves seem like a lot of repetition in the client codebase, plus the complexity of the server-side implementation. Am I alone in thi…

>Am I alone in thinking this is a ridiculous solution to replace traditional REST endpoints? You're not alone. I went down the GraphQL path a year and a half ago. I was telling everyone it was going to be the future, then I got tired. GraphQL requires a lot of configuration and setup to get working right. The decent implementations of GraphQL are all proprietary solutions like Apollo. When you feel like you're spendi…

I set up GraphQL with express-graphql on the backend and then I just use fetch on the frontend. I didn't feel the need to use Apollo. It felt fairly simple.

I just define the schemas in Javascript, which works fine.

But we also use standard HTTP POST + path based routing for some things. Like file uploads.

Re: GraphQL Query Generator

#18

Post by sbegaudeau »

blahbhthrow3748 wrote: post #3

We're looking at adopting GraphQL and for writing a CRUD app it seems insane. Being able to project out individual fields seems like a niche benefit for bandwidth constrained devices. Instead of doing joins in an RDBMS you write a dataloader which merges select queries. The queries themselves seem like a lot of repetition in the client codebase, plus the complexity of the server-side implementation. Am I alone in thi…

I use GraphQL as my main solution to build APIs these days and I have worked with GraphQL for almost 4 years.

I agree with you that "being able to project out individual fields seems like a niche benefit" and I almost never use it to let anyone ask for anything. I rely on GraphQL mostly for its schema in order to have a coherent view of my API at all time. I can thus easily validate my frontend queries during continuous integration and I know the structure and type of the result that I will obtain from my queries.

When I refactor my API, I can evaluate the impact quite easily since my build will tell me about invalid queries in my frontend and unused fields too (since I am building my API for known clients, unused stuff has no place in my API). It brings me the same security net during changes to my API as TypeScript does.

Since I'm not building my API for unknown clients which could ask for anything but instead for specific clients that I can control, I am still doing most of my joins in my datastore. I am relying on a Java implementation of GraphQL and I don't feel any GraphQL-specific complexity on the backend, it may be different with other implementations of GraphQL. In Java, with a minimal amount of annotations, most of my schema is created automatically from my data classes.

Re: GraphQL Query Generator

#19

Post by hurricaneSlider »

blahbhthrow3748 wrote: post #3

We're looking at adopting GraphQL and for writing a CRUD app it seems insane. Being able to project out individual fields seems like a niche benefit for bandwidth constrained devices. Instead of doing joins in an RDBMS you write a dataloader which merges select queries. The queries themselves seem like a lot of repetition in the client codebase, plus the complexity of the server-side implementation. Am I alone in thi…

Have you looked at Hasura (hasura.io)? Allows you to carefully expose your database as an API, while allowing you to build serverless endpoints for validation, business logic and side effects. Bakes in authorization as a first class concern. There are some other similar alternatives that do much the same.

Think it's a mistake to consider GraphQL as a drop-in replacement for REST, writing a vanilla GraphQL server is indeed quite arduous as there is a lot of important concerns like auth that you don't get out the box.

But if you're just wanting to expose your database in a controlled and secure manner, with a smattering of business logic, think some of the technologies that have evolved around GraphQL like Hasura and PostGraphile can make it a joy to use.

Think the wonder is that the schema definition language/schema introspection wasn't just tacked on at the end (unlike REST w/ Swagger and OpenAPI) so all these tools have developed around the tech. There is also a bit less of an object relational mismatch than in REST.

Re: GraphQL Query Generator

#20

Post by kossae »

philliphaydon wrote: post #14
Areibman wrote: post #12

Earlier quoted context omitted.

It totally depends on your use case. Indeed, the best perk, as you've pointed out, is the ability to reduce the quantity of data that runs over the wire. If well-configured, then GQL certainly makes network usage heavy mobile apps much faster. This was the main impetus behind why Facebook decided to build it. If you're willing to add massive technical overhead to solve this, then GraphQL may be worth a shot.

But if you’re the only consumer of the api then it doesn’t help reduce data, unless your UI is configured to show different amounts of data. It also doesn’t make network requests faster. I would argue it’s slower when returning the same data between a rest api and graphql. The difference is you don’t do unnecessary joins when you don’t need data. (Since most graphql apis are in front of a relational database anyway)

The idea is that you can select the exact data fields you need for your UI. In a traditional REST-like response, say for a User model, you may receive all data (within authorization limits) about the user in the response when all you needed was the first_name field. With GraphQL you would just receive first_name without the rest of the unneeded fields, thus reducing the amount of data sent.
Post reply on HN