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

31–40 of 49 posts

Re: GraphQL Query Generator

#31

Post by dgb23 »

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?

Consider implementing GraphQL over a REST-like API if you tick at least one box of:

- Your API has multiple consumers, not just one front-end.

- Your backend has a multiple, possibly heterogeneous providers, for example a set of different APIs.

- You need to decrease the frontend and backend coordination.

- You want to offload complexity or expressivity to the consumer.

---

An example of when not to use it IMO:

We ruled out GraphQL in a current/new project very early on, even though good libraries, tooling and knowledge was all there.

- The coordination is very high and unbureaucratic (small team of full-stack developers).

- single backend, single frontend

- We are very comfortable with SQL and don't need something to patch over an ORM or other scaffolding.

- We are iterating over a specification => the functionality is clear => we can choose where complexity resides. => we decided to keep the frontend simple and optimize on the backend.

Re: GraphQL Query Generator

#32

Post by hp_hovercraft »

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…

You're not alone. I recently took over an Elixir application that uses Apollo/GraphQL. To say the least, making a simple change requires traversing and updating a bunch of code in several areas. For example, if I want to add a single field in an endpoint: Update Apollo, update the GraphQL schema, update the resolvers, update types, update the schema. Makes me wonder what the advantage is. Would just love to go back to a basic REST implementation. Elixir's routing pipeline handles that so well.

Re: GraphQL Query Generator

#33

Post by claydavisss »

bpicolo wrote: post #21
DigitalSea wrote: post #6

Earlier quoted context omitted.

>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'm lukewarm on GraphQL myself, but good tooling can definitely go a long way here. https://hotchocolate.io/ , in the Dotnet ecosystem, is one of the better versions of handling some of those longer tail items out of the box. Rigging it up to EFCore is a pretty magical experience. Because projections are built into the language with LINQ, the two paradigms can be wired together in a pretty delightful way. https://dev…

This is the ultimate sales pitch for REST - no big blob of third party libraries needed, just basic development skills and an understanding of a simple serialization format.

Re: GraphQL Query Generator

#34

Post by claydavisss »

hurricaneSlider wrote: post #19
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 i…

If GraphQL isn't viable unless I use a huge third-party toolkit, then it isn't viable.

Re: GraphQL Query Generator

#35

Post by mikewhy »

hp_hovercraft wrote: post #32
DigitalSea wrote: post #6

Earlier quoted context omitted.

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

You're not alone. I recently took over an Elixir application that uses Apollo/GraphQL. To say the least, making a simple change requires traversing and updating a bunch of code in several areas. For example, if I want to add a single field in an endpoint: Update Apollo, update the GraphQL schema, update the resolvers, update types, update the schema. Makes me wonder what the advantage is. Would just love to go back t…

Interesting. We're using apollo-server on top of an existing REST api and to add a single field our process is:

- update the graphql schema

- implement any resolvers

and we're done. More things happen in the background, but a developer doesn't have to do anything. It's all auto generated when the file is saved or a build happens.

Re: GraphQL Query Generator

#36

Post by w1 »

hurricaneSlider wrote: post #19
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 i…

Hasura has been a godsend for me. I'll be using it for all my MVPs for the foreseeable future.

Re: GraphQL Query Generator

#37

Post by vyrotek »

philliphaydon wrote: post #24
kossae wrote: post #20

Earlier quoted context omitted.

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.

If you’re the only consumer of your api then why are you exposing more data than you need? I’ve never seen an internal rest api that was 100% restful. It was restLike. So if you have consumers of your api then allowing them to pull only what they need makes sense. But for an api where you are the only consumer, it makes no sense.

This! So many native/web apps have APIs which are only consumed by that app and are over architected chasing "REST". Just make an endpoint for the data you're fetching and move on!

There are so many apps that go from function to rest to function.

App.Something(5) > /api/something/5 > API.Something(5)

It's OK to just need an RPC web API! Especially really verby ones where you waste time trying to turn everything into a "resource".

Re: GraphQL Query Generator

#38

Post by cargoshipit »

hurricaneSlider wrote: post #19
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 i…

The biggest pains with hasura are managing migrations across a large development team and adding business logic.

Re: GraphQL Query Generator

#39

Post by agustif »

lowmemcpu wrote: post #27

That editor (in the gif) is really cool. Does anyone know if it's homebuilt, or if they used a library for that?

I think it's the graphqleditor.com which makes sense being their blogpost.

At the end of the post you can click the button and try (as in a trial) the graphqleditor

It's nice, but if you want a free one check altair or just use postman?

Re: GraphQL Query Generator

#40

Post by andrei_says_ »

typingmonkey wrote: post #13
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

Would you be willing to highlight the problems they were solving?
Post reply on HN